코딩 기록 저장소

[딥러닝] 대규모 언어 모델(LLM)

KimNang — Tue, 26 Aug 2025 10:17:10 +0900

1. 대규모 언어 모델 (Large Language Model, LLM)

01. LLM 개념

- 방대한 데이터를 학습해 텍스트를 이해하고 생성할 수 있는 언어 모델

- 주로 트랜스포머 신경망과 딥러닝을 활용하며, 문자·단어·문장 간 관계를 학습함

- 수천~수백만 GB의 텍스트 데이터를 학습하며, 데이터 품질이 모델 성능에 큰 영향을 줌

- 초기 학습 후 추가 학습(웹 크롤링 등)과 튜닝을 통해 특정 작업(질문 답변, 번역 등)에 맞게 성능을 향상시킴

- 사람의 개입 없이도 패턴과 의미를 인식할 수 있으며, 특정 목적에 맞게 미세 조정(fine-tuning)이 가능

LLM이 중요한 이유

- 높은 유연성 : 질문 답변, 문서 요약, 번역, 문장 완성 등 다양한 작업 수행 가능

- 생성형 AI 활용 : 입력 프롬프트만으로 자연스러운 텍스트를 생성할 수 있어 콘텐츠 제작과 검색, 가상 어시스턴트 등에 혁신적 영향

- 거대한 규모 : 수십억~수천억 개의 파라미터를 활용해 방대한 정보를 처리하고, 긴 문서나 책 단위까지 이해 가능

- 다양한 모델과 기능 : GPT-3, ChatGPT, Claude 2, Jurassic-1, Cohere Command 등 다양한 모델이 존재하며, 각 모델은 여러 언어와 대화형 기능을 지원

LLM의 주요 특징

- 대규모 데이터 학습 : 수십억 개의 단어, 문장을 포함한 방대한 데이터를 학습함

- 자연어 처리(NLP) 능력 : 텍스트 분석, 번역, 감정 분석 등 다양한 자연어 작업이 가능함

- 사람과 비슷한 언어 생성 : 마치 사람이 대화하는 것처럼 자연스러운 텍스트를 만들어낼 수 있

02. LLM의 구조 및 종류

LLM의 구조

- 기본적으로 딥러닝 기반 인공신경망 구조를 따르며, 대표적으로 Transformer 아키텍처 위에 구축됨

- 구조는 크게 입력→처리→출력 단계

입력 (Input)
- 텍스트(문자열)를 토큰 단위로 분할 (Tokenization)
- 각 토큰을 임베딩 벡터로 변환 (Word Embedding)
- 순서 정보를 반영하기 위해 Positional Encoding 추가
처리 (Transformer 블록)
- 인코더(Encoder) : 입력 문맥을 이해하는 층
- 디코더(Decoder) : 다음 단어를 생성하는 층
- 각 블록은 Multi-Head Self Attention + Feed-Forward Network(FFN) + 정규화(Normalization, Residual Connection) 으로 구성됨
- Attention 메커니즘을 통해 단어 간 관계를 학습
출력 (Output)
- 마지막 벡터를 Softmax를 통해 확률 분포로 변환
- 가장 높은 확률의 토큰을 선택하거나, 샘플링을 통해 다음 단어를 생성
- 순차적으로 반복하여 문장/텍스트 생성

LLM의 종류

- 각기 다른 목적과 방식으로 개발되었으며, 대표적인 모델로는 GPT 계열, BERT 계열, LLaMA, BLOOM 등이 있음

GPT 계열 (Generative Pretrained Transformer)
- OpenAI에서 개발한 Autoregressive 모델
- 주로 텍스트 생성 작업에 뛰어난 성능을 발휘함
- GPT-3는 1750억 개의 파라미터를 가지고 있으며, 질의응답, 번역, 텍스트 요약 등 다양한 작업에서 사용됨
BERT 계열(Bidirectional Encoder Representations from Transformers)
- Google에서 개발한 모델
- 문맥을 양방향으로 이해하는 데 중점을 둔 모델
- 질의응답(QA)과 같은 작업에 특히 강하며, 문장 분류나 문맥 이해 작업에서 높은 성능을 보여줌
LLaMA (Large Language Model Meta AI)
- Meta에서 개발한 LLaMA는 상대적으로 적은 파라미터로도 높은 성능을 내는 것을 목표로 한 모델
- 최신 버전인 LLaMA 3.2는 모바일 및 엣지 디바이스에서도 구동 가능한 모델
- 온디바이스 AI 응용에 적합함
BLOOM
- BigScience 프로젝트에서 개발한 대규모 오픈소스 언어 모델, 다양한 언어를 지원하는 것이 특징
- 다국어 데이터에 특화된 NLP 작업에 적합
- GPT-3와 유사한 성능

2. LLM의 활용과 발전 방향

01. LLM의 주요 활용 분야

- 콘텐츠 생성 : 기사, 블로그 게시물, 마케팅 문구, 시나리오 등 다양한 텍스트 콘텐츠를 생성하거나 초안을 작성하는 데 사용함

- 번역 및 요약 : 여러 언어를 이해하고 번역하거나, 긴 문서의 핵심 내용을 빠르게 요약하는 데 좋은 성능을 보임

- 고객 서비스 및 챗봇 : 대화형 인터페이스를 제공하여 고객 문의에 응대하거나, 정보 제공 역할을 수행하는 챗봇으로 활용됨

- 코딩 및 개발 : 코드 생성, 디버깅, 주석 작성, 코드 개선 등 개발자 업무를 지원함

- 교육 및 연구 : 맞춤형 학습 자료 제작, 질의응답 시스템, 논문 요약 등 교육과 연구 활동을 도움

- 개인 비서 : 일정 관리, 이메일 초안 작성, 회의록 요약 등 개인의 생산성 향상을 도움

02. LLM의 주요 한계

- 정확성 문제 : 사실과 다른 허위 정보를 마치 사실인 것처럼 생성하는 환각(Hallucination) 현상. 이는 학습 데이터의 오류나 불완전성, 모델의 추론 과정 오류로 인해 발생함

- 최신 정보 부족 : 학습에 사용된 데이터가 특정 시점까지의 정보로 한정되어 있어, 그 이후의 최신 정보를 반영하지 못하는 경우가 많음

- 편향성 문제 : 학습 데이터에 포함된 사회적, 문화적 편견이 모델에 반영되어 편향된 답변을 생성할 수 있음

- 비용 및 자원: 거대 모델을 훈련하고 운영하는 데 막대한 컴퓨팅 자원과 비용이 필요함

- 윤리·보안 문제 : 개인정보 유출, 저작권 침해, 허위정보 생성 등으로 인한 사회적·법적 위험

[쿠버플로우] 파이프라인 스터디

KimNang — Tue, 12 Aug 2025 10:47:43 +0900

1. 파이프라인 개요

- 공식 문서를 참고함!

01. 파이프라인 (Pipelines)

- 쿠브플로우 파이프라인은 재사용 가능하고 확장성이 좋은 머신러닝 워크플로우를 정의하는 방법

- 컨테이너 기반으로 작동하며, 전체 워크플로우를 구성하는 여러 단계(steps)와 입력 파라미터로 이루어져 있음

02. 파이프라인 컴포넌트

- 파이프라인 컴포넌트는 파이프라인의 한 단계를 수행하는 컨테이너화된 애플리케이션

- 각 컴포넌트는 다음의 내용이 정의된 컴포넌트 명세(specifications)를 가짐

인터페이스 : 입력(input) 및 출력(outputs)
구현 : 사용할 컨테이너 이미지와 실행할 명령어
메타데이터 : 컴포넌트의 이름 및 설명 등

- 컴포넌트는 직접 명세를 정의하거나, 쿠브플로우 파이프라인 SDK를 사용해 파이썬 함수 기반으로 생성하거나, 이미 만들어진 컴포넌트를 재사용할 수 있음

03. 파이프라인 그래프

- 파이프라인의 각 단계는 컴포넌트의 인스턴스

- 각 단계의 입력은 파이프라인의 입력 인자, 상수, 또는 다른 단계의 출력으로부터 올 수 있음

- 쿠브플로우는 이러한 데이터 의존성을 기반으로 파이프라인의 워크플로우를 그래프 형태로 구성함

- '통계 생성'과 '데이터 전처리' 모두 '데이터 수집'에만 의존하므로, 두 단계는 병렬로 실행될 수 있음

데이터 수집 : 외부 소스에서 데이터를 불러와 데이터셋을 출력함. 의존성이 없으므로 가장 먼저 실행될 수 있음
통계 생성 : '데이터 수집' 단계의 출력인 데이터셋을 사용함. 따라서 이 단계는 '데이터 수집' 이후에 실행되어야 함
데이터 전처리 : 이 단계도 '데이터 수집' 단계의 출력을 모두 사용함.
모델 학습 : '통계 생성'과 '데이터 전처리' 단계의 출력을 모두 사용함.

04. 파이프라인 설계

- 파이프라인을 설계할 때는 ML 워크플로우를 여러 컴포넌트로 어떻게 나눌지 고민해야 함

- 이는 모놀리식 스크립트를 재사용 가능한 함수로 나누는 과정과 유사함

단일 책임 원칙 : 컴포턴트는 하나의 기능만 담당해야 재사용성과 테스트 용이성이 높아짐
재사용 : 가능하다면 쿠브플로우에서 제공하는 기존 컴포넌트를 재사용하는 것이 좋음
디버깅 및 추적 : 파이프라인은 각 단계의 입력과 출력을 저장함. 이를 통해 모델 품질의 변화 원인을 파악하거나 워크플로우의 버그를 추적하기 쉬워짐

05. 파이프라인 컴포넌트 구축

컨테이너 명세 : 컨테이너화된 애플리케이션이 있다면, 컴포넌트 명세를 만들어 파이프라인 텀포넌트로 정의할 수 있음. 어떤 언어로 작성되었든 컨테이너 이미지로 만들 수 있다면 사용 가능함
파이썬 함수 기반 컴포넌트 : 컴포넌트 코드가 파이썬 함수로 표현될 수 있다면, 쿠브플로우 파이프라인 SDK를 사용해 쉽게 컴포넌트를 생성할 수 있음
사전 구축 컴포넌트 재사용 : 직접 컴포넌트를 만드는 대신, 이미 제공되는 컴포넌트를 재사용하여 개발 노력을 줄일 수 있음

06. 컴포넌트 간 데이터 전달

- 쿠브플로우 파이프라인은 컴포넌트를 실행할 때, 쿠버네티스 파드(Pod)에서 컨테이너 이미지를 시작하고, 입력값을 명령줄 인자로 전달함

- 컴포넌트가 작업을 마치면, 출력값은 파일로 반환됨

작은 데이터 : 숫자나 짧은 문자열 등 작은 입력값은 값(by value)으로 직접 전달할 수 있음
큰 데이터 : 데이터셋과 같은 큰 입력값은 파일 경로(file paths)로 전달해야 함. 출력 역시 쿠브플로우가 제공하는 경로에 파일로 작성됨

- 파이썬 함수 기반 컴포넌트는 이러한 입력 및 출력 전달 과정을 자동으로 처리해줘서 편리하게 컴포넌트를 만들 수 있음

2. 파이프라인 패키지

01. Python SDK (kfp)

- kfp는 kubeflow pipelines을 개발할 수 있도록 해주는 Python SDK

- 이를 통해 파이프라인 구성, 각 step 마다 실행되는 이미지 등을 설정 할 수 있음

kfp 설치

- 설치는 간단한 pip 커맨드로 설치가 가능함

$ pip install kfp

- kfp에는 총 4가지의 라이브러리 패키지가 있는데 그 중 세가지를 소개함

kfp.Client
kfp.compiler
kfp.dsl

kfp.Client

- kubernetes에 설치된 kubeflow pipelines api와 통신하기 위한 클라이언트 라이브러리

- 파이프라인 업로드, 실험 생성, run 생성 등의 기능이 있음

kfp.Client() : kubeflow pipelines api와 통신하기 위한 클라이언트 선언
.get_pipeline_id() : 파이프라인 이름으로 파이프라인 ID 검색
.upload_pipeline() : 변환된 파이썬 DSL 코드를 파이프라인으로 업로드
.upload_pipeline_version() : 위 .upload_pipeline()과 동일한 기능. 단 버전을 지정해서 업로드
.create_experiment() : 실험 생성
.run_pipeline() : 변환된 파이썬 DSL 코드를 해당 실험에서 RUN

kfp.compiler

- 파이프라인을 빌드하는 라이브러리

kfp.compiler.Compiler().compile() : 파이썬 DSL 코드를 파이프라인 업로드를 위한 YAML 파일로 변환

kfp.dsl

- 파이프라인의 각 step을 구성할때 사용되는 클래스, 모듈 등의 라이브러리

.ContainerOp() : 컨테이너 이미지로 구성된 pipeline task
.ResourceOp() : kubernetes resource를 생성하거나 다루는 pipeline task
.VolumeOp() : kubernetes PVC를 생성하는 pipeline task

02. ContainerOp

ContainerOp 개념

- 컨테이너 이미지로 구성된 파이프라인 한 step을 의미함

주요 파라미터
- name : str 값으로 컴포넌트의 이름
- image : 사용할 컨테이너 이미지 이름
- command : 컨테이너 이미지 실행 명령어
- arguments : 컨테이너 이미지 실행 인자값
- file_outputs : 컨테이너 결과를 외부로 노출시킬 때 사용
- pvolumes : volume을 컨테이너 경로에 마운트
주요 메소드
- .set_display_name() : 파이프라인 시각화 할 때 표시될 이름
- .after() : 특정 파이프라인 step이 완료된 후에 실행 함을 지정
- .add_volume() : 컨테이너에 volume을 생성
- .add_volume_mount() : 컨테이너에 volume을 마운트
- .add_env_variable() : 컨테이너 속 환경변수를 설정

volume을 사용하는 세가지 방법

- onprem 사용하여 volume을 mount 하는 경우 pvc가 미리 생성 되어야 함

- ContainerOp의 전체 파라미터 및 사용법은 Docs에서 확인 가능함

https://kubeflow-pipelines.readthedocs.io/en/sdk-2.14.2/

from kfp import dsl
from kfp import onprem
from kubernetes import client as k8s_client

@dsl.pipeline(
    name="pipeline example",
    description="example for volume"
)
def pipeline():
	"""..생략.."""
	
    # VolumeOp 사용 예제
	data_vop = dsl.VolumeOp(
		name="data-volume",
    	resource_name="data-pvc",
    	modes=dsl.VOLUME_MODE_RWO,
    	size="100Mi"
    )
    
    data_op = dsl.ContainerOp(
    	name="data preprocess",
        image="byeongjokim/data-preprocess",
        pvolumes={"/data": data_vop.volume}
    )
    
    
    # add_volume, add_volume_mount 사용
    data_op = dsl.ContainerOp(
    	name="data preprocess",
        image="byeongjokim/data-preprocess"
    ).add_volume(
    	k8s_client.V1Volume(
        	name='data-pvc'
        )
    )\
    .add_volume_mount(
    	k8s_client.V1VolumeMount(
        	mount_path="/data",
            name="data-pvc"
        )
    )
    
    # onperm 사용
    data_op = dsl.ContainerOp(
    	name="data preprocess",
        image="byeongjokim/data-preprocess"
    ).apply(onprem.mount_pvc("data-pvc", volume_name="data", volume_mount_path="/data"))

03. kfp Example

kfp Example

- 위 코드와 같이 여러 ContainerOp와 .after()을 이용해 step과 순서를 지정해줌

- 추가적으로 dsl.Condition()을 사용하여 특정 accuracy 이상일 경우에만 다음 step으로 이어지게 할 수 있음

https://github.com/byeongjokim/MLOps-Example

GitHub - byeongjokim/MLOps-Example

Contribute to byeongjokim/MLOps-Example development by creating an account on GitHub.

github.com

(1) 공통 환경변수 정의

- 모든 단계에서 사용할 관리 URL을 환경변수로 설정

- 각 컨테이너에서 REST API 호출 등 모니터링·로그 수집에 활용

ENV_MANAGE_URL = V1EnvVar(name='MANAGE_URL', value='http://220.116.228.93:8088/send')

(2) 데이터 수집 및 전처리

- 전처리 전용 컨테이너 이미지 실행

- PVC(data-pvc)를 /data에 마운트하여 이후 단계와 공유

data_0 = dsl.ContainerOp(
    name="load & preprocess data pipeline",
    image="byeongjokim/mnist-pre-data:latest",
)

(3) 데이터 검증

- 전처리 완료 데이터를 검증

- after(data_0)로 선행 의존성 보장

data_1 = dsl.ContainerOp(
    name="validate data pipeline",
    image="byeongjokim/mnist-val-data:latest",
).after(data_0)

(4) 임베딩 모델 학습

- 임베딩 모델 학습 수행

- 학습 결과는 train-model-pvc의 /model에 저장

train_model = dsl.ContainerOp(
    name="train embedding model",
    image="byeongjokim/mnist-train-model:latest",
).after(data_1)

(5) 임베딩 생성

- 학습된 임베딩 모델을 활용하여 벡터 표현 생성

embedding = dsl.ContainerOp(
    name="embedding data using embedding model",
    image="byeongjokim/mnist-embedding:latest",
).after(train_model)

(6) FAISS 학습

- 생성된 임베딩을 기반으로 FAISS 인덱스 학습

- 이후 검색 및 분석 단계에서 사용

train_faiss = dsl.ContainerOp(
    name="train faiss",
    image="byeongjokim/mnist-train-faiss:latest",
).after(embedding)

(7) 분석 단계

- 모델 성능 분석 및 평가

산출물
- 혼동행렬 : /confusion_matrix.csv
- 정확도 값 : /accuracy.json
- UI 메타데이터 : /mlpipeline-ui-metadata.json
- 대시보드 메트릭 : /mlpipeline-metrics.json

analysis = dsl.ContainerOp(
    name="analysis total",
    image="byeongjokim/mnist-analysis:latest",
    file_outputs={
        "confusion_matrix": "/confusion_matrix.csv",
        "mlpipeline-ui-metadata": "/mlpipeline-ui-metadata.json",
        "accuracy": "/accuracy.json",
        "mlpipeline_metrics": "/mlpipeline-metrics.json"
    }
).after(train_faiss)

(8) 조건부 배포

- 정확도(accuracy) > 0.8일 경우에만 배포 수행

- 학습 모델을 deploy-model-pvc에 복사하여 서빙 환경에서 사용 가능

baseline = 0.8
with dsl.Condition(analysis.outputs["accuracy"] > baseline):
    deploy = dsl.ContainerOp(
        name="deploy mar",
        image="byeongjokim/mnist-deploy:latest",
    ).after(analysis)

Upload Pipelines

- 완성된 함수(mnist_pipeline)를 compile 한 후, 파이프라인에 올리고, run을

kfp.Clinet() : kubeflow pipelines API 접근
kfp.compiler.Compiler().compile() : 해당 파이프라인 함수 compile
client.get_pipeline_id() : 현재 파이프라인 이름을 가진 파이프라인이 존재하는지 확인
client.upload_pipeline_version(), client.upload_pipeline() : 파이프라인 신규/버전 업로드
client.create_experiment() : experiment 생성 및 기존 experiment 접근
client.run_pipeline() : 파이프라인 run

3. 파이프라인 구축

01. 간단한 실습

kfp SDK 설치 및 호출

kfp SDK를 설치함
- 터미널에 다음과 같이 입력함
```
pip install kfp
```
모듈을 호출함
- 설치된 kfp SDK에서 파이프라인 컴포넌트와 파이프라인을 정의하는 데 사용되는 dsl 모듈과 파이프라인을 컴파일하는 compiler 모듈을 불러옴
```
from kfp import dsl
from kfp import compiler
```

파이프라인 구성요소 구축

- 인사말을 출력하는 간단한 파이프라인을 구축함

컴포넌트 정의
- 컴포넌트가 실행될 컨테이너 이미지 지정
```
@dsl.component(base_image="python:3.9")
def say_hello(name: str) -> str:
    hello_text = f'Hello, {name}!'
    print(hello_text)
    return hello_text
```
- @dsl.component(base_image="python:3.9)
  - @dsl.comonent는 이 함수가 파이프라인의 컴포넌트임을 kubeflow에게 알려주는 데코레이터
  - base_image="python:3.9"는 이 컴포넌트가 실행될 컨테이너 이미지를 지정함. 모든 파이프라인 컴포넌트는 격리된 환경에서 실행되어야 하므로, Python 3.9가 설치된 기본 이미지를 사용하도록 설정함
파이프라인 정의
- 컴포넌트들을 연결하여 전체 작업의 흐름을 설계하는 과정
```
@dsl.pipeline
def hello_pipeline(recipient: str) -> str:
    hello_task = say_hello(name=recipient)
    return hello_task.output
```
- @dsl.pipeline
  - 이 함수가 파이프라인임을 나타내는 데코레이터
파이프라인 컴파일
- 정의한 파이프라인을 YAML 파일로 컴파일하여 Kubeflow Pipelines에 업로드할 수 있는 형태로 저장
```
compiler.Compiler().compile(hello_pipeline, 'pipeline.yaml')
```

파이프라인 실행

- 이 파이프라인을 'Kubeflow Pipelines' 서비스에 업로드함. 이때 두가지 방법이 있음

pipeline을 yaml 파일로 만들어 Kubeflow UI에 업로드하는 방식
다른 하나는 Kubeflow Pipelines SDK 클라이언트를 사용해 직접 서버와 통신해 파이프라인을 실행하는 방식

- 둘 중 1번 방법으로 진행함

- 쿠버플로우 Pipelines의 'Upload pipeline' 클릭하여 진행함

이름 및 파일 설정
- 아래의 사진과 같이 이름과 파일을 설정하고 'Create' 버튼을 클릭하여 생성함
생성 확인
- 이렇게 생성이 된걸 확인할 수 있음
run 생성
- 오른쪽 상단의 'Create run' 버튼 클릭하여 생성함
- Experiment가 없다면 그것부터 생성한 후에 선택함
'Run parameters' 에 아무거나 입력
- Kubeflow Pipeline Test를 입력하여 테스트 해볼 예정
'Start' 클릭 후 결과 확인!
- 체크 표시를 확인한 후 클릭해보면 Output을 확인할 수 있음!

02. 학습 프로젝트 실행

- 케라스 데이터셋으로부터 로이터 뉴스 기사 데이터를 로드하고, 학습 및 평가를 수행하는 파이프라인을 구축함

데이터 로드 및 전처리

1. 데코레이터 : @dsl.component( . . . )

@dsl.component(
    base_image="tensorflow/tensorflow:2.15.0",
    packages_to_install=["matplotlib","joblib"]
)

base_image
- 해당 컴포넌트가 실행될 기본 도커 이미지
packages_to_install
- 추가로 설치할 Python 패키지 ( matplotlib, joblib )

2. 함수 정의

def preprocess_data(
    reuters_data_path : dsl.OutputPath("Dataset"),
    num_words: int = 1000
) -> NamedTuple("Outputs",[("num_classes", int)]):

reuters_data_path
- 전처리된 데이터를 저장할 출력 파일 경로 (Output Artifact)
- 파이프라인에서 다음 단계 컴포넌트가 이 파일을 입력으로 받을 수 있음

3. 데이터 로드

(x_train, y_train), (x_test, y_test) = keras.datasets.reuters.load_data(num_words=num_words)

- Keras에서 제공하는 Reuters 뉴스 데이터셋을 불러옴

- 뉴스 기사(텍스트)는 숫자 인덱스로 변환되어 있으며, num_words보다 작은 단어 인덱스만 사용함

4. 시퀀스 벡터화

def vectorize_sequences(sequences, dimension=num_words):
    results = np.zeros((len(sequences), dimension))
    for i, seq in enumerate(sequences):
        results[i, seq] = 1.0
    return results

- 문장을 단어 인덱스 리스트 → 원-핫 인코딩 벡터로 변환

- dimension : num_words차원 벡터

5. 학습/테스트 데이터 변환

x_train = vectorize_sequences(x_train)
x_test = vectorize_sequences(x_test)

y_train = keras.utils.to_categorical(y_train)
y_test = keras.utils.to_categorical(y_test)

- 입력 데이터(x) : 원-핫 벡터화

- 출력 데이터(y) : 각 뉴스 카테고리를 원-핫 라벨로 변환

6. 결과 저장 및 반환

reuters_data = {"x_train": x_train, "y_train": y_train, "x_test": x_test, "y_test": y_test }
joblib.dump(reuters_data, reuters_data_path)

return (num_classes,)

joblib.dump()
- 데이터를 파일로 저장함
- 다음 단계에서 입력으로 사용됨
return (num_classes,)
- 뉴스 카테고리의 개수를 반환
- 이 값은 MLMD(Metadata store)에 기록되어 파이프라인의 다른 컴포넌트에서 메타데이터로 참조할 수 있음

모델 학습

1. 데코레이터 : @dsl.component( . . . )

@dsl.component(
    base_image="tensorflow/tensorflow:2.15.0",
    packages_to_install=["joblib"]
)

@dsl.component
- Kubeflow Pipeline에서 사용할 "단일 컴포넌트"를 정의하는 데 사용됨
base_image
- 이 컴포넌트가 실행될 기본 Docker 이미지
packages_to_install
- 추가로 설치할 Python 패키지 목록
- joblib를 설치해서 데이터를 로드할 수 있게 함

2. 함수 정의

def train_model(
    reuters_data_path: dsl.InputPath("Dataset"),
    num_words: int,
    num_classes: int,
    model_out: dsl.OutputPath("Model"),
    history_out: dsl.OutputPath("Metrics"),
    epochs: int = 10,
    batch_size: int = 512
) -> NamedTuple("Outputs", [("model_path", str)]):

dsl.InputPath()
- 파이프라인 상에서 이전 단계의 출력(Dataset)을 "파일 경로" 형태로 받음
dsl.OutputPath("Model") / ("Metrics")
- 이 컴포넌트가 생성할 결과물을 저장할 경로
- Kubeflow가 자동으로 이 파일들을 아티팩트로 관리함
NamedTuple
- 반환값 형식을 지정함

3. 데이터 로드

reuters_data = joblib.load(reuters_data_path)

- 데이터 전처리 과정에서 딕셔너리로 저장해뒀던 reuters_data를 로드함

4. 모델 정의

model = keras.Sequential([
    layers.Dense(64, activation="relu", input_shape=(num_words,)),
    layers.Dense(64, activation="relu"),
    layers.Dense(num_classes, activation="softmax")
])

- 입력 차원 : num_words

- 은닉층 2개 (64개의 노드, ReLU)

- 출력층: 클래스 개수(num_classes), softmax로 다중 분류

5. 컴파일

model.compile(
    optimizer="rmsprop",
    loss="categorical_crossentropy",
    metrics=["accuracy"]
)

- 옵티마이저 : RMSProp

- 손실함수 : categorical_crossentropy

- 평가 지표 : accuracy

6. 학습

history = model.fit(
    reuters_data["x_train"], reuters_data["y_train"],
    epochs=epochs,
    batch_size=batch_size,
    validation_split=0.2,
    verbose=2
)

- 학습 데이터에서 20%를 검증용으로 사용함

- 학습 로그는 history 객체에 저장됨

7. 결과 저장 및 반환

model.save(model_out)

with open(history_out, "w") as f:
    json.dump(history.history, f)

return (model_out,)

model.save(model_out)
- 학습된 모델을 Kubeflow의 아티팩트 경로(model_out)에 저장
- 이 경로는 다음 컴포넌트가 dsl.InputPath("Model")로 받을 수 있음
with open(history_out, "w") as f :
- 학습 결과(손실, 정확도 등)를 JSON 파일로 저장
- Kubeflow UI에서 Metrics로 시각화 가능
return (model_out,)
- NamedTuple 형식으로 model_path 문자열을 반환
- Kubeflow 파이프라인 상에서 "이 컴포넌트의 출력"으로 인식됨

모델 평가

1. 컴포넌트 정의

@dsl.component(
    base_image="tensorflow/tensorflow:2.15.0",
    packages_to_install=["joblib"]
)

@dsl.component
- Kubeflow Pipeline에서 하나의 컴포넌트를 정의하는 부분
base_image
- 실행 환경으로 사용할 Docker 이미지
packages_to_install
- 추가로 필요한 패키지를 지정함
- joblib을 설치하여 .joblib 파일로 저장된 데이터를 읽을 수 있게 함

2. 함수 정의

def evaluate_model(
    model: dsl.InputPath("Model"),
    reuters_data_path: dsl.InputPath("Dataset")
) -> float:

model
- train_model 단계에서 저장한 모델 파일 경로
- dsl.InputPath("Model") → Kubeflow가 모델 파일을 이 경로에 자동으로 복사
reuters_data_path
평가에 사용할 데이터셋 파일 경로 (joblib 형식)
반환값(float)
- 평가 정확도(accuracy)를 float 값으로 반환
- Kubeflow의 ML Metadata(MLMD)에 자동 기록됨

3. 데이터 및 모델 불러오기

reuters_data = joblib.load(reuters_data_path)
model = keras.models.load_model(model)

- 전처리 단계에서 저장했던 Reuters 데이터셋을 로드함

- 모델은 학습 때 저장된 TensorFlow Keras 모델을 불러옴

4. 모델 평가

loss, acc = model.evaluate(reuters_data["x_test"], reuters_data["y_test"], verbose=0)
print(f"테스트 정확도: {acc:.4f}")

model.evaluate()
- 주어진 테스트셋으로 모델 성능을 평가함
- loss : 손실값 (crossentropy 등)
- acc : 정확도 (accuracy)
verbose=0
- 학습 로그를 생략하고 결과만 반환.

- print()를 통해 Kubeflow 로그창에 "테스트 정확도: 0.XXXX" 형태로 출력

5. 결과 반환

return float(acc)

- Kubeflow에서는 컴포넌트가 반환하는 단일 숫자(float, int, str 등)를 파이프라인 결과 파라미터로 저장함

결과 시각화

1. 컴포넌트 정의

@dsl.component(
    base_image="python:3.9",
    packages_to_install=["matplotlib"]
)

@dsl.component()
- Kubeflow Pipelines에서 하나의 컴포넌트를 정의함
base_image="python:3.9"
- Python 3.9 환경을 사용함
packages_to_install=["matplotlib"]
- matplotlib 패키지를 설치해 그래프를 그림

2. 함수 정의

def plot_history(
    history_path: dsl.InputPath("Metrics"),
    plot_out: dsl.OutputPath("Plot"),
    metrics_out: dsl.OutputPath("Metrics")
):

history_path
- 이전 단계에서 전달된 history JSON 파일의 경로
plot_out
- 그래프를 저장할 출력 이미지 파일 경로
metrics_out
- 최종 성능 지표를 저장할 출력 JSON 경로

이 세 인자는 Kubeflow에서 artifact(산출물) 로 관리됨

3. 학습 기록 불러오기

with open(history_path, "r") as f:
    history = json.load(f)

- 이전 단계(train_model 등)에서 저장한 history.json 파일을 불러옴

4. 그래프 시각화

plt.figure(figsize=(12, 5))

Loss 그래프
- 훈련 손실(Loss)과 검증 손실(Val_loss)을 한 그래프에 표시함

plt.subplot(1, 2, 1)
plt.plot(epochs, loss, "bo-", label="Training loss")
plt.plot(epochs, val_loss, "ro-", label="Validation loss")

Accuracy 그래프
- 훈련 정확도와 검증 정확도를 표시함

plt.subplot(1, 2, 2)
plt.plot(epochs, acc, "bo-", label="Training acc")
plt.plot(epochs, val_acc, "ro-", label="Validation acc")

https://byeongjo-kim.tistory.com/28

[쿠버플로우] 화면 커스터마이징

KimNang — Mon, 11 Aug 2025 09:14:43 +0900

1. Kubeflow 커스터마이징

01. MLflow 설치 및 대시보드 추가하기

- 두 가지 성격의 저장소가 필요함

DB (metadata 저장)
Storage (Artifact 저장)

- DB를 위해 일반적으로 PostgreSQL을 사용하고, 아티팩트를 저장하기 위해 S3를 사용함

- Kubeflow는 기본적으로 저장소로 MinIO를 사용하기에 여기에 mlflow용 버킷을 만들고 사용할 수 있음

MLflow를 위한 Minio bucket 생성

- Kubeflow를 위해 이미 설치된 minio 서비스에 접속해 버킷을 생성함

kubectl port-forward -n kubeflow svc/minio-service 9000:9000

- http://localhost:9000/ 에 접속한 뒤 아래 계정으로 로그인함

Access Key: minio
Secret Key: minio123

- 이후 mlflow라는 이름으로 버킷을 생성함

- mlflow를 위한 artifact 저장소가 준비됨

- mlflow를 설치할 Helm 차트에서 설치를 제공해서 따로 설치를 하지 않음

MLflow 설치

- 아래 명령어로 설치를 함

kubectl create ns mlflow
 
kubectl create -n mlflow secret generic mlflow-secret \
    --from-literal=AWS_ACCESS_KEY_ID=minio \
    --from-literal=AWS_SECRET_ACCESS_KEY='minio123'
 
helm repo add bitnami https://charts.bitnami.com/bitnami
helm upgrade --install mlflow bitnami/mlflow -n mlflow --version 0.10.3 \
--set minio.enabled=false \
--set externalS3.host=minio-service.kubeflow \
--set externalS3.port=9000 \
--set externalS3.existingSecret=mlflow-secret \
--set externalS3.existingSecretAccessKeyIDKey="AWS_ACCESS_KEY_ID" \
--set externalS3.existingSecretKeySecretKey="AWS_SECRET_ACCESS_KEY" \
--set externalS3.bucket="mlflow" \
--set externalS3.protocol=http

- http://localhost:32429에 접속하고 로그인하면 아래와 같은 화면이 나와야 함

username: user
password: kubectl get secret --namespace mlflow mlflow-tracking -o jsonpath="{.data.admin-password }" | base64 -d

virtual service 생성

- Kubeflow의 Central Dashboard에서 하나의 탭을 클릭할 때 다양한 엔드포인트로 라우팅 하기 위해 VirtualService를 사용 (Jupyter, Katib, pipeline 등)

- MLflow 버튼을 클릭하면 mlflow tracker UI로 라우팅 해야 하므로 추가로 Virtual Service를 생성해야 함

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: mlflow
  namespace: kubeflow
spec:
  gateways:
  - kubeflow/kubeflow-gateway
  hosts:
  - '*'
  http:
  - match:
    - uri:
        prefix: /mlflow/
    rewrite:
      uri: /
    route:
    - destination:
        host: mlflow-tracking.mlflow.svc.cluster.local
        port:
          number: 80

kubectl apply -f mlflow_virtual_service.yaml

- /mlflow/ 라는 라우터에 접근 시 mlflow-tracking.mlflow.svc.cluster.local:80로부터 요청을 받아옴

Central Dashboard 수정

- Central Dashboard에 버튼을 추가하기 위해, configmap에 정의된 것을 수정함

kubectl edit cm centraldashboard-config -n kubeflow

- 아래와 같은 내용을 추가함

{
  "type": "item",
  "link": "/mlflow/",
  "text": "mlflow",
  "icon": "device:access-alarm"
}

- 그 후 Central Dashboard를 재시작함

kubectl rollout restart deploy centraldashboard -n kubeflow

- 다시 대시보드에 접근하여 확인함!

02. Kubeflow 대시보드 탭 삭제하기

현재 탭 확인

- 이중에서 'Endpoints'부터 'Executions'까지의 탭을 전부 삭제하고 확인해볼 예정

configmap 수정

- 'Volumes'부터 이전에 추가한 'mlflow' 사이의 탭을 전부 삭제함

kubectl edit cm centraldashboard-config -n kubeflow

- 그 후 Central Dashboard를 재시작함

kubectl rollout restart deploy centraldashboard -n kubeflow

- 다시 대시보드에 접근하면 탭이 삭제된 것을 확인할 수 있음!

[쿠버플로우] 개념 및 구성 요소 정리

KimNang — Wed, 2 Jul 2025 16:52:08 +0900

1. Kubeflow 개념

- 쿠버네티스(Kubernetes)를 기반으로 하는 AI 플랫폼 구축을 위한 핵심 도구

- 컨테이너 오케스트레이션을 활용하여 머신러닝 워크플로우를 간편게 생성하며 모델을 배포, 관리할 수 있게 함

- 각 프로젝트에 필요한 도구를 독립적으로 사용하거나, 전체 AI 워크플로우를 아우르는 통합 플랫폼을 구축할 수 있음

01. 쿠버플로우 AI 플랫폼 특징

- 구성 가능하고 모듈식 : 필요한 기능만 선택해 조합할 수 있음

- 이식성과 확장성 : 쿠버네티스가 동작하는 어떤 환경(클라우드, 온프레미스)에서도 동일하게 사용할 수 있으며, 대규모 작업도 효율적으로 처리함

- AI 워크플로우 지원 : AI 수명 주기의 모든 단계(데이터 준비, 학습, 배포 등)를 지원하는 쿠버네티스 기반 프로젝트들로 구성됨

02. 쿠버플로우 프로젝트

- AI 라이프 사이클의 다양한 측면을 다루는 여러 오픈소스 프로젝트로 구성됨

- 이 프로젝트들은 독립적으로 사용하거나 쿠버플로우 AI 참조 플랫폼의 일부로 사용할 수 있음

프로젝트	설명
Kubeflow KServe	머신러닝 모델 서빙을 위함
Kubeflow Katib	하이퍼파라미터 튜닝 및 뉴럴 아키텍처 탐색
Kubeflow Model Registry	모델 관리 및 버전 관리를 위한 도구
Kubeflow Notebooks	주피터 노트북을 쿠버네티스 환경에서 운영
Kubeflow Pipelines	AI 워크플로우를 자동화하고 관리
Kubeflow Spark Operator	스파크(Spark) 워크로드를 쿠버네티스에서 운영
Kubeflow Trainer	모델 학습을 위한 도구

2. Kubeflow 구조

01. Central Dashboard

역할 및 기능

- 사용자가 Kubeflow 환경에 접근하는 시작점

- 다양한 머신러닝 워크플로우를 구성하는 각 컴포넌트(Jupyter, Pipelines, Katib 등)로 이동할 수 있는 네비게이터 역할을 수행

주요 기능
- 컴포넌트 접근
  - Central Dashboard는 Kubeflow의 모든 컴포넌트로 연결되는 중앙 허브
  - 사용자는 대시보드를 통해 필요한 컴포넌트의 전용 UI로 즉시 이동
- 사용자 및 네임스페이스 관리
  - 로그인한 사용자의 정보를 보여줌
  - 사용자별 네임스페이스(Profile)를 선택하여 작업 환경을 분리하고 관리 가능
- 빠른 시작
  - 처음 접속했을 때 Kubeflow에 대한 소개나 빠른 시작 가이드 등을 제공하여 사용자가 쉽게 시작할 수 있도록 도움

구성 요소

- Header: 현재 로그인한 사용자의 이름, 로그아웃 버튼, 그리고 때로는 현재 선택된 네임스페이스 정보 등 표시

- Sidebar Navigation: Notebooks, Pipelines, Katib, Volumes 등 Kubeflow의 주요 컴포넌트들로 연결되는 메뉴 링크를 제공, 사용자는 이 메뉴를 통해 각 컴포넌트의 전용 웹 UI로 손쉽게 이동

- Main View: 대시보드에 처음 접속했을 때 보이는 초기 화면, 일반적으로 Kubeflow에 대한 소개, 빠른 시작 가이드, 최근 활동 내역 등이 표시됨

02. Jupyter Notebooks

역할 및 기능

- Kubernetes 클러스터에 Jupyter Notebook Pod를 생성하고 관리하기 위한 사용자 인터페이스를 제공

- 주로 데이터 과학자나 모델 개발자가 직접 개발 환경을 구축할 때 사용됨

기능
- Notebook 서버 관리
  - 사용자는 UI를 통해 Jupyter Notebook 서버를 생성, 중지, 삭제
- 리소스 및 환경 설정
  - Notebook 서버에 필요한 CPU, 메모리, GPU와 같은 하드웨어 자원과 사용할 Docker 이미지, 환경 변수, 그리고 PVC(Persistent Volume Claim)와 같은 스토리지 설정까지 모두 지정할 수 있음
- 커스텀 이미지 활용
  - 원하는 개발 환경이 미리 구성된 커스텀 Docker 이미지를 사용해 Notebook 서버를 만들 수 있어, 개발 환경의 일관성과 재현성을 보장

구성 요소

- Notebook List: 사용자가 생성한 Notebook 목록을 보여줌

- Create Notebook: Notebook 서버의 사양과 설정을 지정하는 UI

- Server Status: 현재 실행 중인 Notebook Pod의 상태(예: Running, Stopped)를 확인

03. Pipelines

역할 및 기능

- 머신러닝 파이프라인을 설계하고 실행할 수 있는 워크플로우 실행 및 관리 UI

- 주로 AutoML, 모델 학습/추론/평가 등의 과정을 순차적으로 자동화하는 데 사용

기능
- 워크플로우 설계 및 실행
  - YAML 형식으로 정의된 파이프라인을 업로드하여 실행하고 관리
- 시각화 및 모니터링
  - DAG (방향성 비순환 그래프) 형태로 파이프라인의 전체 구조와 각 단계의 실행 상태를 시각적으로 보여줌
- 반복 실험
  - 다양한 파라미터를 설정하여 여러 번의 실험을 손쉽게 수행
  - 그 결과를 비교하며 최적의 모델을 찾을 수 있음
- 결과 분석
  - 각 실행의 상세 로그, 출력 아티팩트, 그리고 모델 성능 지표를 시각화하여 분석

구성 요소

- Experiments: 파이프라인 실행을 그룹화하여 관리하는 단위, 여러 번의 파이프라인 실행 결과를 한데 모아 실험 단위로 비교하고 분석할 수 있음

- Runs: 개별 파이프라인 실행 인스턴스 목록, 각 실행에 대한 상세 정보(로그, 결과 등)를 확인할 수 있음

- Artifacts/Output View: 실행 결과 아티팩트 시각화, 학습된 모델의 성능 지표나 시각화된 그래프 등을 확인할 수 있음

- Upload Pipeline: YAML 형식으로 작성된 파이프라인 정의 파일을 업로드하여 실행할 수 있도록 하는 기능

04. Katib

역할

- AutoML의 핵심 기능인 하이퍼파라미터 최적화를 제공

- 하이퍼파라미터 튜닝 과정을 시각적으로 관리하고 모니터링

- 사용자는 UI를 통해 실험을 정의하고, 진행 상황을 확인하며, 최종 결과를 분석

기능
- 실험 정의
  - UI에서 모델 이름, 파라미터 범위, 최적화 목표(maximize/minimize) 등을 설정하여 하이퍼파라미터 튜닝 실험을 정의
- 다양한 검색 알고리즘
  - Random Search, Grid Search, Bayesian Optimization 등 다양한 최적화 알고리즘을 선택함
  - 효율적으로 최적의 파라미터 조합을 찾을 수 있음
- 실험 모니터링 및 분석
  - 각 파라미터 조합에 대한 성능 지표를 시각화하여 확인하고, 여러 실험의 결과를 쉽게 비교할 수 있음

구성 요소

- Experiment 생성 UI: 모델 이름, 파라미터 범위, 메트릭 조건 등 입력
- Experiment 목록 및 상태: 튜닝 결과와 Trial 상태 시각화
- Trial 상세보기: 각 파라미터 조합에 대한 성능 확인

05. Volumes (Persistent Volume 관리 UI)

역할 및 기능

- Jupyter Notebook이나 Pipeline에서 사용할 수 있는 Persistent Volume Claim(PVC)을 생성하고 관리하는 UI

- 데이터 저장 공간인 Persistent Volume(PV)을 사용자들이 쉽게 할당받고 관리할 수 있도록 함

기능
- PVC 생성 및 관리
  - 사용자는 UI를 통해 필요한 크기, 접근 모드(Access Mode) 등을 지정하여 새로운 PVC를 만들거나 기존 PVC의 상태를 확인
- Jupyter Notebook 및 파이프라인 연동
  - 생성된 PVC는 데이터가 필요한 워크로드(Jupyter Notebook, 파이프라인 등)에 자동으로 마운트되어, 사용자가 데이터를 읽고 쓸 수 있는 영구적인 저장 공간을 제공
- 삭제/변경 기능
  - 생성된 PVC는 UI나 kubectl 명령어를 통해 삭제하거나 변경할 수 있음

구성 요소

- Volume 목록 : PVC 이름, 사이즈, 상태, 네임스페이스

- 생성 UI : 이름, 크기, Access Mode 설정

06. Tensorboards

역할 및 기능

- 모델 학습 중 생성된 TensorBoard 로그 파일을 시각화하는 도구

- 머신러닝 모델의 학습 과정을 실시간으로 시각화하고 분석하는 데 사용

- PVC(Persistent Volume Claim)를 연결하여, 모델의 성능 지표, 손실 곡선, 그래프 구조 등을 웹 인터페이스에서 직관적으로 확인

기능
- 로그 시각화
  - 모델 학습 중 생성되는 로그 데이터를 활용하여, 손실(loss) 및 정확도(accuracy)와 같은 메트릭을 시각화
- 학습 상태 모니터링
  - 실시간으로 업데이트되는 그래프를 보면서 모델의 학습 진행 상황을 파악하고, 문제 발생 시 즉각적으로 대응
- PVC 연결
  - 사용자가 지정한 PVC에 저장된 로그 파일을 자동으로 마운트하여 TensorBoard 서버에 연결

구성 요소

- Tensorboard 목록

- Tensorboard 생성 UI

- 로그 디렉토리 설정 입력창

07. Profiles UI

역할 및 기능

- 하나의 Kubeflow 클러스터를 다수의 사용자 또는 팀이 함께 사용할 수 있도록 격리된 환경 제공

- 각 사용자에게 독립된 Kubernetes 네임스페이스 할당하여, 서로의 작업에 영향을 주지 않고 리소스를 관리

기능
- 사용자 및 팀 격리
  - 각 사용자는 자신만의 Profile을 할당받음
  - 다른 사용자의 작업과 충돌 없이 독립된 환경에서 머신러닝 워크플로우를 실행함
- 리소스 관리
  - 사용자는 자신에게 할당된 네임스페이스에만 리소스(예: Notebook, Pipeline)를 생성하고 관리함
- 접근 제어
  - Istio Gateway와 연계하여 네임스페이스 기반의 접근 제한을 설정함으로써, 보안을 강화함

08. Metadata 및 Artifacts UI

역할

- 머신러닝 파이프라인 실행 중에 생성된 모든 결과물과 메타데이터를 추적하고 관리

- 모델의 학습 과정, 사용된 데이터셋, 생성된 모델 파일 등 모든 아티팩트의 계보(lineage)를 시각적으로 분석

기능
- 아티팩트 트래킹
  - 파이프라인의 각 단계에서 생성된 데이터셋, 모델, 메트릭 등의 모든 아티팩트를 자동으로 기록하고 추적
- 메타데이터 관리
  - 각 아티팩트와 관련된 모델 버전, 실험 일자, 하이퍼파라미터 등 핵심적인 정보를 관리
- 시각적 계보 분석
  - 데이터가 전처리 과정을 거쳐 모델 학습에 사용되고, 최종적으로 모델이 생성되기까지의 모든 과정을 그래프 형태로 시각화하여 보여줌

[쿠버네티스] 권한이 제한된 사용자 계정 발급

KimNang — Tue, 24 Jun 2025 16:39:28 +0900

1. context

01. 쿠버네티스 context

- 쿠버네티스 계정을 발급하고 권한을 제한하는 방법이 serviceaccount와 role

- pod 생성 등의 쿠버네티스 요청은 쿠버네티스 API 서버가 처리하고, API 서버는 사용자 요청을 처리하기 전 올바를 사용자가 맞는지 검사하고 사용할 수 있는지 확인함

- API 서버의 인증, 인가를 확인하는 기준이 쿠버네티스 context 정보!

- context 정보에는 쿠버네티스 클러스터 정보와 사용자 정보가 존재함

- 사용자가 요청할 때 별도로 인증, 인가 정보를 명시하지 않으면 context 정보가 자동으로 요청정보와 같이 전송됨

※ context는 사용자 홈 디렉터리 /.kube/config에 위치함

02. context 구조

- 쿠버네티스 클러스터 정보와 사용자 정보로 구성됨

클러스터 정보 : API 서버의 인증서와 주소 필요.
사용자 정보 : ssh키 쌍, 토큰, 사용자 이름과 비밀번호 등 여러가지 유형으로 유저를 설정함

- 쿠버네티스 설치시 default로 쿠버네티스 admin 유저와 localhost 또는 host ip로 쿠버네티스 클러스터 정보가 설정되어 있음

- 자동 설정된 값이 있었기에 kubectl 명령어를 사용할 수 있었던 것

현재 사용중인 context 확인

- 아래 명령어 사용하면 현재 사용중인 context 정보가 출력됨

kubectl config current-context

context에 대한 자세한 정보 출력
- context는 cluster와 user(authinfo)로 구성됨
- 현재 사용중인 kubernetes-admin context는 cluster.local클러스터와 kubernetes-admin user를 사용하고 있음
```
kubectl config get-contexts
```

2. 쿠버네티스 context에 등록

01. serviceaccount 생성

- 계정 이름과 namespace를 지정해주면 됨

- default namespace에 developer라는 serviceaccount을 생성함

kubectl create sa developer -n test

serviceaccount가 생성되었는지 확인하는 방법
```
kubectl get sa -n test
```
serviceaccount의 토큰을 발급함
- Kubernetes v1.24 이상부터는 Secret 기반 토큰이 사라지고, TokenRequest API를 통해 토큰을 발급함
```
kubectl create token developer -n test
```

02. context 생성

- serviceaccount를 이용해 쿠버네티스 인증을 하려면 context 등록이 필요함

serviceaccount 토큰을 환경변수로 저장
- context를 생성할 때 serviceaccount 토큰을 이용함
- 토큰 길이가 길어서 환경변수로 저장하여 사용함
```
export DEV_TOKEN=$(kubectl create token developer -n test)
```
유저 등록
- kubectl config set-credentials 명령어로 context 유저를 쉽게 등록할 수 있음
```
kubectl config set-credentials dev --token=$DEV_TOKEN
```
클러스터 이름 확인
- context를 생성하기 위해 쿠버네티스 클러스터가 필요함
- 기존에 등록되어 있는 로컬 쿠버네티스 클러스터를 사용함
- 로컬 클러스터란 127.0.0.1 주소로 시작하는 클러스터 주소
- 클러스터가 설치되어 있는 서버에만 접근이 가능함
```
kubectl config get-clusters
```
context 등록
- devloper으로 등록한 유저와 로컬 클러스터를 이용해 context를 등록함
```
kubectl config set-context dev \
  --cluster=kubernetes \
  --user=dev \
  --namespace=test
```
context 확인
- 생성한 context는 다음 명령어로 확인 가능함
- 현재 사용중인 context는 CURRENT필드에 별표로 표시됨
```
kubectl config get-contexts
```

3. context 사용 및 권한 제한

01. context 전환

- context 이름은 current-context로 확인해야 함

kubectl config use-context dev

pod 생성 시도

- context를 전환하면 context에 해당하는 계정 권한을 가짐

- developer 계정은 어떠한 권한도 설정하지 않았으므로 모든 요청이 쿠버네티스 API서버에서 거부함

- pod를 test namespace에서 생성을 시도하면 permission denied 오류 메시지가 뜸

02. 권한 설정

- RBAC 방법으로 계정에 권한을 설정하는 방법이 있음

- role이라는 쿠버네티스 리소스로 관리됨

- kubeflow 일부 권한을 developer 계정에 설정함

apigroup: 쿠버네티스 리소스가 속해 있는 api group이름
resources: 권한 설정할 쿠버네티스 리소스
verbs: 권한

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: test
  name: pods-role
rules:
- apiGroups: [""] # "" indicates the core API group
  resources: ["pods"]
  verbs: ["create", "delete"]

- role 설정

03. 권한 부여

- 생성한 role을 serviceaccount에 설정을 수동으로 해줘야 함

- rolebinding을 사용해 권한을 부여함

- kubectl --dry-run을 이용해서 rolebinding yaml파일을 생성한 후, yaml 파일을 쿠버네티스에 적용함

kubectl create rolebinding pod-rolebinding \
  --serviceaccount=test:developer \
  --role=pods-role \
  --namespace=test \
  --dry-run=client -o yaml > pod-rolebinding.yaml

kubectl apply -f pod-rolebinding.yaml

- kubectl create 명령어로 방금 생성한 rolebinding을 실행함

kubectl create -f pod-rolebinding.yaml

04. pod 생성 테스트

- 아래 명령어를 이용해 실행이 되는지 확인해봄

kubectl auth can-i create pods --as=system:serviceaccount:test:developer -n test

- serviceaccount에 rolebinding이 적용됨

- 아까 실패했던 pod 생성이 성공하는 모습을 볼 수 있음

https://malwareanalysis.tistory.com/133

쿠버네티스에서 권한이 제한된 개발자 계정 발급 1편

1편: https://malwareanalysis.tistory.com/133 2편: https://malwareanalysis.tistory.com/135 이 챕터는 권한이 제한된 쿠버네티스 계정(serviceaccount)을 생성하는 방법을 다룹니다. https://youtu.be/qt4fMcvG564 1. 1편에서 다루

malwareanalysis.tistory.com

[쿠버네티스] VMware를 이용한 쿠버네티스 구축&배포 프로젝트 - ③

KimNang — Thu, 5 Jun 2025 11:19:26 +0900

※ 컴퓨터의 메모리 부족으로 인해 서버컴퓨터에서 학습을 진행하게 됨

1. 게시판 프로젝트 구성

01. React 설치

Node.js 를 설치함
- React.js를 사용하기 위해서는 먼저 Node.js를 설치해야함
- Node.js는 자바스크립트 런타임으로 서버 측 자바스크립트를 실행할 수 있도록 해줌
https://nodejs.org/ko
React 프로젝트 생성
- Visual Studio Code에서 원하는 경로에 접근한 후 터미널을 엶(Ctrl + J)
- 설치가 완료되면 해당 이름으로 프로젝트가 생성됨
```
npx create-react-app <프로젝트 이름>
```
프로젝트 실행하기
- 프로젝트 경로로 이동후 명령어를 입력함
```
cd <프로젝트 이름>
npm start
```

2. React 앱 Dockerize(도커라이즈) 하기

디플로이먼트 정의 파일에 태그 작성함

- 도커 새로 푸시할 때 ArgoCD에서 자동으로 배포를 돕기위해 태그를 수정함!

docker에 로그인하고 build&push 과정을 거침

docker login

docker build -t <Docker ID>/<Image Name>:<Tag> .
docker tag <Docker ID>/<Image Name>:<Tag> <Docker ID>/<Image Name>:<New Tag> .

docker push <Docker ID>/<Image Name>:<New Tag>

3. React 앱 배포 확인

ArgoCD로 확인해보기

- SYNC 버튼을 통해 적용이 됐는지 확인함

- 무사히 적용된것을 확인했음!

[쿠버플로우] 설치 및 세팅하기

KimNang — Thu, 5 Jun 2025 10:13:09 +0900

Master노드 버전 정리

- kubernetes : v1.28.15

- kustomize : v5.6.0

- kubeflow : v1.8.0

1. Kubeflow 설치 및 접속

01. Kubeflow 설치하기

kustomize를 설치함

curl -s "https://raw.githubusercontent.com/kubernetes-sigs/kustomize/master/hack/install_kustomize.sh"  | bash
install kustomize /usr/bin/kustomize

manifest git을 clone 함

git clone https://github.com/kubeflow/manifests.git
cd manifests
git checkout v1.8.0

http로 접속할 수 있도록 설정함

- 아래 3개 파일의 secure_cookies를 false로 설정함

apps/jupyter/jupyter-web-app/upstream/base/params.env
apps/tensorboard/tensorboards-web-app/upstream/base/params.env
apps/volumes-web-app/upstream/base/params.env

deployment.yaml 수정

common/oidc-client/oauth2-proxy/base/deployment.yaml

- ndots를 4로 설정

apiVersion: apps/v1
kind: Deployment
metadata:
  name: oauth2-proxy
  labels:
    app: oauth2-proxy
spec:
  replicas: 2
  selector:
    matchLabels:
      app.kubernetes.io/name: oauth2-proxy
  template:
    metadata:
      labels:
        app.kubernetes.io/name: oauth2-proxy
    spec:
      dnsConfig:
        options:
          - name: ndots
            value: "4"

kustomize를 사용해 kubeflow 설치하기

- 5분에서 10분 정도 소요됨

- 모든 pod가 running이 될 때까지 기다림

while ! kustomize build example | kubectl apply -f -; do echo "Retrying to apply resources"; sleep 20; done

02. Kubeflow 접속하기

istio-ingressgateway 수정

- 기본적으로 ClusterIP 타입으로 생성되기 때문에, 호스트 환경에서 접속하기 위해 NodePort로 변경

kubectl edit -n istio-system svc istio-ingressgateway

Kubeflow 접속 해결

- http://{Node IP + 포트번호}로 접속

- 이때 Access to {IP주소} was denied You don't hava authorization to view this page. HTTP ERROR 403 이런 오류가 뜸

PVC 정보 확인함
- authservice-pvc가 Pending 상태로 뜸
- 요청한 PersistentVolumeClaim(PVC)에 연결할 수 있는 PersistentVolume(PV)이 없음
- 이로 인해 oidc-authservice Pod도 실행되지 않고, 결국 403 인증 오류가 생김
```
kubectl get pvc -n istio-system
```
local-path-provisioner 설치함
- 로컬 테스트 환경이라 local-path StorageClass를 사용함
```
kubectl apply -f https://raw.githubusercontent.com/rancher/local-path-provisioner/master/deploy/local-path-storage.yaml
```
- 설치 후 StorageClass 목록에 local-path가 나타나야 함
```
kubectl get storageclass
```

PVC에 local-path 지정
- oidc-authservice에서 사용하는 PVC 리소스를 수정함

nano authservice-pvc.yaml

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: authservice-pvc
  namespace: istio-system
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
  storageClassName: local-path

- PVC yaml 파일 수정 후 적용함

kubectl delete pvc authservice-pvc -n auth
kubectl apply -f authservice-pvc.yaml

PVC 바인딩 상태 확인
```
kubectl get pvc -n istio-system
```

Kubeflow 접속

- http://{Node IP + 포트번호}로 접속

- 아래 사진과 같은 사이트가 뜨는데 기본 계정으로 로그인

기본 계정 : user@example.com
패스워드 : 12341234

- 이렇게 뜨면 접속 성공!

too many open files 문제 해결

- 네임스페이스 관련하여 자꾸 error가 뜨길래 로그 파악을 했더니 too many open files라는 로그가 출력됨

- 이를 해결하기 위해 마스터 노드, 워커 노드 각각에 설정 파일을 적용함

설정 파일 열기
- 설정은 /etc/sysctl.conf 파일을 수정함
```
sudo nano /etc/sysctl.conf
```
- 파일에 아래 두 줄을 추가함
```
fs.inotify.max_user_instances=2280
fs.inotify.max_user_watches=1255360
```
저장 후 적용하기
```
sudo sysctl -p
```

적용 확인하기

sysctl fs.inotify.max_user_instances
sysctl fs.inotify.max_user_watches

03. Kubeflow 삭제

- 단일 명령어로 Kubeflow 삭제가 가능함

cd /home/$USER/manifests
kustomize build example | kubectl delete -f -

2. kubeflow 사용자 세팅

01. 유저 프로필 생성하기

profile.yaml을 활용해 유저 프로필 생성하기
- kubeflow > manifests > common > dex > base 경로에 yaml 파일 생성
- nang-profile.yaml로 생성함

apiVersion: kubeflow.org/v1
kind: Profile
metadata:
    name: nang # 생성하고 싶은 프로필의 이름(네임스페이스로 지정할 이름)
spec:
    owner:
        kind: User
        name: nang@example.com # 생성하고 싶은 프로필의 이메일(Kubeflow로그인ID)

- apply 명령어를 이용해 profile을 적용함

kubectl apply -f nang-profile.yaml

※ 프로필 생성 시 spec 하위에 resourceQuotaSpec 추가할 수 있음
- 유저를 추가할 때 프로필 별 사용할 수 있는 리소스 양 지정 가능

apiVersion: kubeflow.org/v1beta1
kind: Profile
metadata:
    name: nang
spec:
    owner:
        kind: User
        name: nang@example.com
 	resourceQuotaSpec:
        hard:
            cpu: "2"
            memory: 1Gi
            persistentvolumeclaims: "1"
            requests.storage: "10Gi"

config-map.yaml을 활용해 유저 등록
- kubeflow > manifests > common > dex > base >config-map.yaml 파일을 수정하면 위에서 생성한 유저의 네임스페이스와 Kubeflow의 정보를 매핑함
- username: 네임스페이스명 / email: Kubeflow 로그인 ID / hash: 암호화된 비밀번호

- config-map.yaml 적용함
```
kubectl apply -f config-map.yaml -n auth
```
적용 후 확인하기
- 네임스페이스 및 config 설정을 적용하기 위해서는 dex를 재실행해야 함
```
kubectl rollout restart deployment dex -n auth
```
- 적용이 잘 되었음!!

02. kubeflow 권한 제한하기

kim 프로필 생성

- 이 Profile을 만들면 kim 네임스페이스와 kim@example.com 사용자에게 edit 권한이 부여됨

Role 생성

- kim 사용자가 nang 네임스페이스에 접속했을 때 오직 Notebook만 생성/조회/삭제할 수 있도록 Role을 정의함

Rolebinding 부여

참고한 링크

1. Kubeflow 설치 및 접속

https://kyeongseo.tistory.com/entry/kubeflow-190-%EC%84%A4%EC%B9%98%ED%95%98%EA%B8%B0

kubeflow 1.9.0 설치하기

kubernetes versionv1.29.8kubeflow version1.9.0kustomize versionv5.4.31. kustomize를 설치한다.curl -s "https://raw.githubusercontent.com/kubernetes-sigs/kustomize/master/hack/install_kustomize.sh" | bash install kustomize /usr/bin/kustomize 2. manifes

kyeongseo.tistory.com

https://dolphincoding.tistory.com/entry/Kubeflow-18%EC%9D%84-%EC%84%A4%EC%B9%98%ED%95%98%EA%B8%B0-%EC%9C%84%ED%95%9C-Kubernetes-%EC%84%B8%ED%8C%85%ED%95%98%EA%B8%B0

Minikube (k8s 1.28.2) + Kubeflow 1.8 설치하기

[1단계] Minikube 로 K8S 세팅하기이번 글에서는 Minikube로 Kubernetes 버전 1.28.2버전을 설치하고, 현재 기준 최신 버전인 kubeflow 1.8을 설치할 거에요먼저 k3s, kubespray, kubeadm등 다양한 방식으로 설치해볼

dolphincoding.tistory.com

2. Kubeflow 세팅

https://semizero.tistory.com/47

[Kubeflow] Kubeflow 유저 추가하기(유저 분기처리하기)

Kubeflow를 활용하다보면 user@example.com/12341234 라는 샘플 계정을 활용하여, 테스트하는 경우가 많다. 그러나 서비스 관점에서는 사용자별 Kubeflow 기능을 분기하여 관리해야할 필요가 있다. 그렇기에

semizero.tistory.com

[쿠버네티스] VMware를 이용한 쿠버네티스 구축&배포 프로젝트 - ②

KimNang — Wed, 21 May 2025 13:47:10 +0900

※ 컴퓨터의 메모리 부족으로 인해 서버컴퓨터에서 학습을 진행하게 됨

1. 젠킨스 설치 및 구성

01. 젠킨스 설치하기

리눅스 패키지를 최신 상태로 업데이트함
- 최신 상태로 업데이트하면 설치할 패키지(소프트웨어)를 최신 버전으로 가져올 수 있음
```
sudo apt update
```
JDK를 설치함
- openjdk 17버전으로 설치함
```
sudo apt install -y openjdk-17-jre-headless
```
- 설치가 잘 된것을 확인할 수 있음
```
java -version
```

젠킨스를 설치하기 위해 필요한 패키지에 접근하기 위해 GPG 키를 추가함

wget -q -O - https://pkg.jenkins.io/debian/jenkins.io-2023.key |sudo gpg --dearmor -o /usr/share/keyrings/jenkins.gpg

젠킨스 패키지 저장소 주소를 sources.list에 추가함

sudo sh -c 'echo deb [signed-by=/usr/share/keyrings/jenkins.gpg] http://pkg.jenkins.io/debian-stable binary/ > /etc/apt/sources.list.d/jenkins.list'
sudo apt update

젠킨스를 설치함
```
sudo apt install jenkins
```
젠킨스의 상태를 확인함
- Inactive 상태라면 sudo systemctl start jenkins.service 명령어로 젠킨스를 시작할 수 있음
- 상태값이 active 혹은 8080 포트가 활성화되었다면 실행이 성공적으로 이루어진것
```
systemctl status jenkins

netstat -tnlp
```

02. 젠킨스 구성하기

젠킨스 실행 및 설정하기

- 젠킨스 설치를 완료했고 이제 젠킨스를 구성해야 함

브라우저에서 마스터 노드의 IP에 접근함 (2가지 방법중 하나로 하면 됨)
- Hyper-V 관리자에서 master에 접속해 브라우저에서 localhost:8080에 접근
- Hyper-V가 설치된 컴퓨터의 브라우저에서 마스터노드의 IP:8080으로 접근
administrator password 묻는 화면이 나오면 패스워드를 입력한 후 Continue를 클릭함
- 패스워드는 다음 명령어로 확인할 수 있음
```
sudo cat /var/lib/jenkins/secrets/initialAdminPassword
```
기본 플러그인 설치를 진행함
- Administrator password를 입력하면 플러그인 설치와 관련된 옵션들이 나타남
- Install suggested plugins를 클릭해 설치 진행
설치 진행
사용자와 패스워드를 설정
접속할 수 있는 URL을 보여줌
- Save and Finish를 클릭함
젠킨스 사용 준비가 완료되었다는 화면을 보여줌
- Start using Jenkins를 클릭
젠킨스 접속 화면

젠킨스 사용하기

깃허브와 연동하기

- 젠킨스는 빌드를 자동화하는 툴이므로 소스 코드가 저장된 저장소와 연계해야 함

- 깃허브를 저장소로 사용함

깃허브에 연동하기 위해 먼저 깃허브에 접속해 로그인함
젠킨스에서 깃허브에 접속할 수 있는 토큰을 생성해야 함
- 오른쪽 상단의 프로필 → Settings
왼쪽 메뉴 하단의 Developer settings를 선택
Personal access tokens에서 Tokens을 클릭 후 Generate new token(classic) 클릭함
Note에 토큰 이름을 지정하고 Expiration 부분은 No expiration을 선택함
scopes에서는 다음과 같은 항목을 선택한 후 Generate token을 클릭함
- scopes는 젠킨스에서 깃허브에 접속해 사용할 수 있는 권한에 관한 것, 리포지터리와 자동 빌드를 위한 권한만 체크
생성된 토큰을 저장해둠
젠킨스로 이동해 깃허브와 연결함
- 젠킨스 화면의 왼쪽 메뉴에서 Manage Jenkins를 클릭함
System Configuration 에서 System을 클릭
화면을 하단으로 이동하면 GitHub라는 메뉴가 있음 Add GitHub Server > GitHub Server를 선택함
깃허브 접속을 위한 Credential 설정
- Name : access_github
- API URL : https://api.github.com
- Credentials : Add > Jenkins를 선택
깃허브에 연결하기 위한 권한을 설정할 수 있는 화면이 나타남. 다음과 같이 설정함
- Domain은 그대로 두고, Kind는 Secret text를 선택함
- Secret에서는 앞에서 저장했던 토큰을 입력하고, ID는 토큰 이름을 지정함
- 이후 Add를 클릭함
이후 Credentials 아래 리스트 박스를 클릭하면 생성했던 jenkins_token1이 보임. 이것을 선택함
Test connection 버튼을 클릭해 정상적으로 연결되는 것을 확인한 후 Save 버튼을 클릭함
- 테스트 결과 'Credentials verified for user [user ID], rate limit: 4999'가 나타나면 연결에 성공한 것

프로젝트 생성하기

- 이제 젠킨스에서 소스 코드를 자동 빌드하는 프로젝트 생성함

젠킨스 메인 화면의 왼쪽 메뉴에서 New Item을 클릭함
다음 메뉴에서 item name을 입력한 후 Freestyle project를 선택하고 OK 버튼을 클릭
빌드 방법을 지정하기 위해 Triggers를 선택함
- 'Github hook trigger for GITScm polling'을 체크하면 왼쪽 하단에 save와 apply가 나타나는데, save를 클릭
그러면 다음과 같은 메뉴가 나타나는데 Configure를 클릭함
깃허브에 접속할 수 있는 권한을 생성함
- '소스 코드 관리'로 이동해 Credentials에서 Add > Jenkins를 클릭함
그러면 다음과 같은 창이 뜨는데 Kind에 Username with password를 선택함
다음과 같은 항목만 채운 상태에서 Add를 클릭함
- 이때 Username에는 깃허브 계정을 입력하고 Password에는 계정의 비밀번호를 입력함
이제 다음과 같이 -none-이 위치한 리스트 박스를 클릭하면 생성했던 credential이 나타나는데 본인의 깃허브 계정을 선택
권한 설정이 완료되었으므로 이제 깃허브 주소가 필요함
- URL을 확인하기 위해 깃허브에 다시 접속해 깃허브 아이콘을 클릭한 후 New를 클릭함
Repository name을 입력한 후 하단의 Create repository를 클릭함
이후 다음과 같은 주소를 보여줌. 이 주소를 복사함
다시 젠킨스로 이동해 Source Code Management로 이동하고 Repository URL 항목에 앞에서 복사해 둔 주소를 입력함
- 입력후 Advanced...를 클릭
Branches to build에는 */main을 입력한 후 Save를 클릭함
- 기본은 master이지만 깃허브의 branch 이름을 입력함

빌드 도구 설정하기

- 젠킨스는 지속적 통합, 프로젝트 빌드, 테스트 실행, 배포 등의 작업을 자동화함

- 이것이 가능하도록 메이븐(Maven), 앤트(Ant), 그래들(Gradle) 같은 빌드 도구를 이용하고, 깃허브, SVN(SubVersion) 같은 형상 관리 툴을 지원함

- 젠킨스에서 실행될 빌드 도구를 설정해야함

앤트 빌드 도구의 특징	메이븐 빌드 도구의 특징	그래들 빌드 도구의 특징
- XML 기반으로 빌드 스크립트를 작성함 - 간단하고 사용이 쉬움 - 프로젝트 규모가 클 경우 스크립트 관리나 빌드 과정이 복잡함	- XML 기반으로 작성함 - 생명 주기(Lifecycle)와 프로젝트 객체 모델(POM, Project Object Model)이란 개념이 도입됨 - 상대적으로 학습 장벽이 높음 - 라이브러리가 서로 의존적이면 사용이 복잡함	- 라이브러리 의존성 관리를 위한 다양한 방법을 제공함 - 빌드 스크립트를 XML이 아닌 JVM에서 동작하는 스크립트 언어 '그루비' 기반의 DSL을 사용함 - 사용이 쉽고 빌드 과정이 간단함

wget 명령어를 이용해 /tmp 디렉터리에 그래들 설치 파일(zip 파일)을 내려받음
- 이때 -P는 파일을 저장할 디렉터리를 지정할 때 사용하는 옵션
```
wget https://services.gradle.org/distributions/gradle-7.4.2-bin.zip -P /tmp
```
모두 내려받았으면 /opt/gradle 디렉터리에 압축을 해제함
```
sudo unzip -d /opt/gradle /tmp/gradle-*.zip
```
/opt/gradle/gradle-7.4.2 디렉터리에 그래들 파일이 있는지 확인함
```
ls /opt/gradle/gradle-7.4.2
```
그래들에 대한 환경 변수를 설정함
- gradle.sh 파일에 GRADLE_HOME 경로를 설정함
- 그다음에는 ctrl+x 입력 후 y를 누르고 enter를 누름
```
sudo nano /etc/profile.d/gradle.sh
```
```
export GRADLE_HOME=/opt/gradle/gradle-7.4.2
export PATH=${GRADLE_HOME}/bin:${PATH}
```
chmod + x 명령어를 실행해 스크립트를 실행할 수 있도록 권한을 부여함
```
sudo chmod +x /etc/profile.d/gradle.sh
```
source 명령어를 사용해 환경 변수를 가져옴
- source 명령어는 스크립트 파일을 수정한 뒤 바로 수정된 값을 적용할 때 사용
```
 source /etc/profile.d/gradle.sh
```
그래들이 제대로 설치되었는지 그래들 버전을 표시하는 명령어로 확인함
```
gradle -v
```
이제 그래들을 사용하기 위해 젠킨스로 이동해 Jenkins 관리 - Tools를 클릭함
화면을 아래로 내려 Gradle을 찾은 후 Add Gradle을 클릭함
다음과 같이 입력한 후 맨 밑에 있는 Save를 클릭함
- Install automatically : 선택 해제
- name : 젠킨스 내에서 사용할 이름 설정
- GRADLE_HOME : 앞에서 PATH로 등록한 경로
초기 화면으로 돌아오면 다시 New Item을 클릭함
All이라는 메뉴가 생기는데 All 메뉴 옆의 화살표를 클릭하고 앞에서 생성해둔 Jenkins_test를 클릭함
구성 - Build Steps으로 이동해 Add build step에서 Invoke Gradle script를 선택함
이제 그래들에 대해 다음과 같이 설정함
- Gradle Version : 앞에서 설정한 이름을 선택함
- Task : clean을 입력함(clean은 디스크 초기화 명령어)
웹훅(webhook)을 설정하기 위해 다시 깃허브로 이동해서 Settings를 클릭함
- 웹훅 : 특정 이벤트가 발생하고 나서 특정 스크립트를 실행시킬 때 사용. 따라서 다른 서비스와의 통합이나 특정 API를 호출할 때 사용함
Webhooks 메뉴로 이동한 후 Add webhook 버튼을 클릭함
- URL(젠킨스가 실행되고 있는 노드의 IP와 포트)과 Content Type(application/json)을 선택
- Add webhook 버튼 클릭
- 입력한 IP가 공인 IP가 아니라면 생성 후 오류가 발생할 수 있음
이후 젠킨스로 돌아와서 다음과 같이 'Build Now'를 클릭함
- 자동으로 빌드가 진행됨
- 깃허브에 소스 코드를 저장한 후 수정하면 자동으로 빌드가 됨
- 혹은 ' Build Now'를 클릭해 강제로 빌드를 할 수도 있음

2. ArgoCD 설치 및 구성

01. ArgoCD 설치하기

ArgoCD 설치를 위해 argocd라는 네임스페이스를 먼저 생성함
```
kubectl create namespace argocd
```
클러스터에 ArgoCD를 설치함
- 설치를 위해 다음 명령어를 이용하며, -f 옵션은 yaml 파일과 함께 사용할 때 사용
```
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml
```
ArgoCD를 외부에서 접속할 수 있도록 서비스의 타입을 로드밸런서(LoadBalancer)로 설정함
```
kubectl patch svc argocd-server -n argocd -p '{"spec": {"type" : "LoadBalancer"}}'
```

API 서버와의 상호작용을 위해 ArgoCD CLI를 설치함

VERSION=$(curl --silent "https://api.github.com/repos/argoproj/argo-cd/releases/latest" \
  | grep '"tag_name"' \
  | sed -E 's/.*"([^"]+)".*/\1/')

sudo curl -sSL -o /usr/local/bin/argocd https://github.com/argoproj/argo-cd/releases/download/$VERSION/argocd-linux-amd64

sudo chmod +x /usr/local/bin/argocd

설치가 끝나면 ArgoCD 접속을 위해 필요한 admin 사용자의 패스워드를 확인함
- admin으로 비밀번호를 변경하는 과정을 거침

htpasswd -bnBC 12 "" admin | tr -d ':\n'

- 위 명령어로 나온 결과의 값을 복사 후 아래의 코드에 붙여넣음

kubectl -n argocd patch secret argocd-secret \
  -p '{"stringData": {
    "admin.password": "(위의 해시 비밀번호)",
    "admin.passwordMtime": "'$(date +%FT%T%Z)'"}}'

- ArgoCD 서버 Pod 재시작

kubectl -n argocd delete pod -l app.kubernetes.io/name=argocd-server # Argo CD 서버 Pod 재시작

ArgoCD에 접속할 포트 번호 확인
- http는 30456를 사용하고, https는 32490을 사용함
```
kubectl get svc -n argocd argocd-server
```
브라우저에서 마스터 노드의 IP에 접근함 (2가지 방법중 하나로 하면 됨)
- Hyper-V 관리자에서 master에 접속해 브라우저에서 localhost:32490에 접근
- Hyper-V가 설치된 컴퓨터의 브라우저에서 마스터노드의 IP:32490으로 접근
- URL : https://localhost:32490
- 사용자 : admin / 패스워드 : (앞에서 설정한 패스워드)

02. ArgoCD 구성하기

- 리포지터리 연결 및 애플리케이션 배포 설정 확인

설정을 클릭 후 Repositories를 클릭함
리포지터리에 연결할 수 있는 방법들을 보여주는데, +CONNECT REPO를 클릭함
연결 방법은 HTTP/HTTPS, Repository URL에는 젠킨스에서 사용했던 깃허브 주소, username에는 깃허브에서 사용하는 사용자, password에는 깃허브 토큰을 입력한 후 상단의 connect를 클릭함
다음와 같이 정상적으로 연결된 화면이 나옴
애플리케이션을 배포하기 위해 왼쪽 메뉴의 두 번째 아이콘을 클릭한 후 New App을 클릭함
General 항목은 다음과 같이 설정
- Application Name은 임의로 지정
Source 지정을 위해 먼저 깃허브에 접속해 Creating a new file을 클릭함
- 입력 후에는 반드시 /를 추가해야 함
- 입력할 이름 역시 임의로 지정
이후 다시 argoCD로 돌아와서 Source 부분의 Path에 앞에서 지정한 Resources/App를 지정함
Destination은 다음과 같이 설정한 후 상단의 Create를 클릭
다음과 같이 정상적으로 설정된 것을 확인할 수 있음
- argocd-test를 클릭함
Resources/App에 위치한 Readme.md 파일이 자동으로 동기화되어 다음 그림과 같이 현재 동기화 상태임을 확인

[쿠버네티스] VMware를 이용한 쿠버네티스 구축&배포 프로젝트 - ①

KimNang — Tue, 20 May 2025 11:02:26 +0900

※ 컴퓨터의 메모리 부족으로 인해 서버컴퓨터에서 학습을 진행하게 됨

1. Ubuntu 환경에 VMware 설치

서버컴퓨터 환경

- 우분투 : 24.04.2 LTS

- 커널 : 6.11.0-21-generic

01. VMware 파일 설치

broadcom 사이트에 접속한 후 오른쪽 위 'Support Portal - Go To Portal'을 통해 로그인을 함
https://www.broadcom.com/
Software - VMware Cloud Foundation - My Downloads를 통해 이동함
다운로드 하는 링크로 이동하여 환경에 맞는 버전을 설치함
이 파일을 서버컴퓨터의 디렉터리에 이동한 후 다음 코드를 통해 설치를 진행함
- 관리자 권한으로 쉘을 이용해 VMware 설치 파일을 실행함
```
sudo sh VMware-Workstation-Full-17.6.3-24583834.x86_64.bundle
```
설치되면 아래의 명령어를 통해 vmware를 실행함
- 이때 -E 옵션을 이용해 환경 변수를 유지해서 실행을 함
- 입력하지 않으면 GUI가 실행될 때 X11 디스플레이를 열 수 없는 문제가 발생했음
```
sudo -E vmware
```
동의해야하는 것들은 선택 후 Next를 누르고, CEIP와 관련된 것은 No를 선택한 후 Finish를 누름
- 완료되면 이런 창이 뜨게됨!

2. VM 생성 및 노드 구성

01. VM 생성

VM 생성하기

우측에서 new virtual machine클릭함
os 이미지를 선택함
- 우분투 사이트(https://releases.ubuntu.com/focal/)에 접속해 설치 파일을 내려받으면 됨
VM을 설정함
- 이름은 기본 이름인 'Ubuntu 64-bit'로 설정
- 'Customize Hardware...' 버튼을 클릭하고 아래처럼 설정함
- 네트워크 어댑터는 VMnet8번 NAT으로 설정함
- USB컨트롤러랑 Sound Card는 필요없으니 삭제 후 'Close' 버튼을 클릭함
- Disk Size : 20GB
- Processors : 2개, 2개 총 4개
- Memory : 4GB (4096MB)

Ubuntu 설치하기

- 이제 vm은 만들어졌고 다운받은 ubuntu iso 파일로 서버를 설치함

- 언어는 영어를 선택하고 그 다음 나오는 창도 쭉쭉 넘기면 됨

ens32에서 엔터 누르고 IPv4설정으로 넘어감
Manual 선택
주소를 맞게 입력함
이후 다 기본 설정되어있는대로 진행함
SSH 설정에서 'Install OpenSSH server' 체크하고 진행함
설치가 다 되면 reboot now가 뜸
- 클릭하여 재부팅 하면 됨

02. 노드 구성

가상환경 clone 후 노드 구성하기

우클릭 후 'Manage - Clone'을 클릭함
이름과 Type을 아래와 같이 설정 후 완료함
- Clone Type은 full로 설정
- 마스터 노드 1대와 워커 노드 2대로 구성할 예정이라 3개를 클론 후 각각 이름을 설정함!
각각 VM에 접속해 호스트 이름과 고정 IP를 변경함
- 마스터노드 : master
- 워커노드 : worker1, worker2
- 호스트 이름 수정
  - /etc/hostname 파일과 /etc/hosts 파일 수정
```
sudo nano /etc/hostname
```
```
sudo nano /etc/hosts
```
- 노드들의 고정 IP를 변경함
  - 설정 파일 /etc/netplan/ 디렉토리에 있는, 설정 파일에 접근하여 고정 IP를 다른 VM과 겹치지 않게 다 바꿔줌
  - 마스터 노드 : 11 / 워커 노드 1 : 12 / 워커 노드 2 : 13 으로 설정함
```
cd /etc/netplan/
ls -l
```

3. 쿠버네티스 설치 및 연결

01. 쿠버네티스 설치

sudo su - # root 사용자로 변경
sudo apt-get update && sudo apt-get upgrade # 리눅스를 최신 상태로 업데이트
sudo apt install apt-transport-https curl

br_netfilter 모듈 활성화하기

# br_netfilter 모듈 로드
sudo modprobe br_netfilter

# 부팅 시 br_netfilter 모듈 자동 로드 설정
cat <<EOF | sudo tee /etc/modules-load.d/k8s.conf
br_netfilter
EOF

# iptables 필터링 활성화 설정
cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1
EOF

# sysctl 설정 적용
sudo sysctl --system

스왑 메모리 비활성화 하기

- kubelet이 제대로 작동하려면 스왑 메모리를 비활성화 해야함
- 두 번째로 실행한 명령어는 시스템이 재부팅되어도 스왑 메모리가 비활성화되도록 유지시킴
스왑 메모리 : 물리 메모리가 부족할 경우를 대비해서 만들어 놓은 공간

sudo swapoff -a
sudo sed -i '/ swap / s/^\(.*\)$/#\1/g' /etc/fstab

도커(엔진 및 런타임) 설치하기

sudo apt install docker.io
sudo systemctl start docker
sudo systemctl enable docker # 재부팅 후에도 서비스가 자동으로 시작되도록 설정
sudo systemctl status docker # 도커 서비스 상태 확인

- 일반 사용자 계정의 경우 권한 문제로 작업에 제약이 있을 수 있으므로 권한을 설정함

sudo usermod -aG docker $USER

- 도커가 정상적으로 설치되었는지 hello-world를 이용해 확인함

docker run hello-world

cgroup 드라이버 설정
- 쿠버네티스에서는 도커의 cgroup 관리를 위해 systemd를 사용하도록 변경해야 함
- 변경하지 않으면 클러스터 설치 과정에서 오류가 발생할 수 있음
1. docker info 명령어로 도커 설치 정보를 확인함

2. 다음 명령어는 cgroup driver가 systemd가 아닌 경우에만 실행
- 코드를 입력한 후에는 차례대로 esc, :wq!, enter를 입력하고 빠져나옴
vi /etc/docker/daemon.json

{
	"exec-opts" : ["native.cgroupdriver=systemd"],
    "log-driver" : "json-file",
    "log-opts" : {
    	"max-size" : "100m"
    },
    "storage-driver" : "overlay2"
}

3. 도커 서비스를 다시 실행함

sudo mkdir -p /etc/systemd/system/docker.service.d
sudo systemctl daemon-reload # .service 파일을 변경하면 데몬을 다시 로드해야 함
sudo systemctl restart docker # 도커 서비스 재시작

쿠버네티스 설치하기

# 구글 클라우드의 공개 사이닝 키를 다운로드 한다.
curl -fsSL https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-archive-keyring.gpg

# 쿠버네티스 apt 리포지터리를 추가한다.
echo "deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.28/deb/ /" | sudo tee /etc/apt/sources.list.d/kubernetes.list

curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.28/deb/Release.key | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg

# 저장소 추가되었기 때문에 apt 업데이트
sudo apt-get update

# 쿠버네티스 패키지 설치
sudo apt-get install -y kubelet kubeadm kubectl

# 쿠버네티스 패키지 버전 고정
sudo apt-mark hold kubelet kubeadm kubectl

# 쿠버네티스 설치 버전 조회
kubelet --version
kubeadm version
kubectl version

# kubelet service 확인
sudo systemctl status kubelet.service

02. 쿠버네티스 연결

마스터 노드 설정하기
- 마스터 노드는 클러스터를 생성하는 것이 중요함
- 클러스터는 마스터와 워커 노드를 하나의 관리 단위로 묶는 역할을 함
- kubeadm init : 쿠버네티스 클러스터 생성
- pod-network-cidr : 파드 네트워크의 IP 주소 범위
- apiserver-advertise-address : 수신 대기 중임을 알릴 IP 주소 (API 서버의 IP 주소)로 마스터 노드의 IP를 설정
```
# Kubernetes 클러스터 초기화 (특정 Pod 네트워크 CIDR 및 API 서버 광고 주소 지정)
sudo kubeadm init --pod-network-cidr=10.244.0.0/16 --apiserver-advertise-address=192.168.0.2

# 이후 kubeadm join과 관련된 내용이 나온다면 따로 메모해두기!

# kubectl이 Kubernetes 클러스터와 상호작용할 수 있도록 .kube 디렉토리 생성
mkdir -p $HOME/.kube

# 관리자 인증 파일을 kubectl에 필요한 config 파일로 복사
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config

# 사용자 권한으로 config 파일의 소유자 변경 (현재 사용자에게 읽기/쓰기 권한 부여)
sudo chown $(id -u):$(id -g) $HOME/.kube/config

# 설치 확인
kubectl get nodes
```
- 네트워크 설정하기
  - 서로 다른 노드에 떠 있는 파드 간의 통신 혹은 외부와의 통신을 위해서는 CNI 플러그인이 필요함
  - 여기서는 플라넬 CNI 플러그인을 사용함
```
kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml
```
  - 플라넬 CNI 플러그인이 정상적으로 설치되면 다음 명령어를 입력해 CoreDNS 파드가 실행 중(running)인지 확인함. CoreDNS 파드가 실행 중이어야 파드들의 네트워크 통신이 가능함
```
kubectl get pods --all-namespaces
```

※ 마스터 노드 NotReady 상태 해결했던 방법

- 나의 문제 : 노드 확인 명령어 치면 아래와 같은 오류 뜨면서 안되는 문제 발생

The connection to the server <host>:6443 was refused - did you specify the right host or port?

- 해결 방법 : ens32를 사용중이라 Flannel에서 인터페이스를 지정함

Flannel 설치 파일 다운로드

wget https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml

파일 수정

        containers:
        - name: kube-flannel
          image: quay.io/coreos/flannel:v0.22.0-amd64
          command:
            - /opt/bin/flanneld
            - --ip-masq
            - --kube-subnet-mgr
          # # # 여기 사이에 추가했음! # # #
          env:
            - name: FLANNEL_NETWORK
              value: "10.244.0.0/16"
            - name: FLANNEL_IFACE
              value: "ens32"
          # # # # # # # # # # # # # # # # #
          resources:
            {}

Flannel 네트워크 플러그인 적용
```
kubectl apply -f kube-flannel.yml
```
coredns 재생성함

워커 노드 설정하기
- 워커 노드는 마스터 노드에 생성된 클러스터에 조인하기 위해 kubeadm join 명령어를 실행함
- 마스터 노드에서 클러스터 설치 결과로 보여 준 명령어를 수정없이 그대로 사용하면 됨
- 실행 결과 마지막에 'Run kubectl get nodes' on the control-plane to see this node join the cluster' 라는 문구가 나타나면 정상적으로 설치된 것
```
kubeadm join 192.168.0.3:6443 --token i1zobz.lvw2yxvxjyv3tk7y \
        --discovery-token-ca-cert-hash sha256:8da5a66297c72b90e6e809ca76a5bcfedbad121821496b2d6357bbf6f319764a
```
+ 마스터 노드에서 쿠버네티 클러스터에 등록된 노드들의 상태를 보여주는 명령으로 확인해봄
```
kubectl get nodes
```
잘 연결된 것을 확인할 수 있음!!

[쿠버네티스] PART3. 한 걸음 더 나아가기

KimNang — Wed, 7 May 2025 17:16:21 +0900

1. 쿠버네티스의 CI/CD

01. CI/CD란?

- CI/CD가 등장하기 전, 개발할 때는 개발자들이 소스 코드가 저장된 저장소에 접근해서 커밋을 통해 사용 권한을 얻고, 이후 수정한 내용을 빌드하고 테스트하는 과정을 거침

- 개발 중에는 별도의 품질 관리를 수행하지 않기 때문에 테스트 과정 중에 오류가 발생하는 경우가 많았음

- 그래서 CI/CD가 등장하게 됨

CI/CD 개념

- Continuous Integration의 약자로 지속적 통합을 의미함

- 오류 수정 혹은 새로운 기능을 테스트하고 깃허브 같은 저장소에 배포하는 과정을 의미함

- Travis CI, Bamboo, 젠킨스(Jenkins) 등 같은 도구를 사용하는데, 그중 젠킨스를 가장 많이 사용함

CI의 핵심
- 빠른 개발과 배포
  - 애플리케이션을 운영하다 보면 새로운 기능을 추가하거나 기존의 기능을 수정하고 배포해야 하는 상황이 많이 발생함
  - 빈번한 수정과 테스트를 빠르면서도 효율적으로 진행하도록 도와줌
- 자동화
  - 소스 코드를 수정한 후 빌드하고 테스트하는 과정을 자동화 시켜줌
CI의 목적
- 소스 코드 파일, 라이브러리, 구성 파일 및 스크립트를 포함해 전체 코드를 포함하는 프로그램 또는 버전 관리
- 프로그램 빌드의 자동화
- 자동화된 테스트

- Continuous Delivery 또는 Continuous Deployment의 약자로 지속적 배포를 의미함

- 테스트까지 완료된 소스 코드를 개발 환경과 운영 환경에 배포하는 것을 의미함

- 개발 환경과 운영 환경을 분리하는 이유는 안정성 때문

- 개발 환경에 배포해 오류가 발생하는지 확인하고 문제가 없다면 운영 환경에 배포하게 됨

- Continuous Delivery는 사람의 손이 필요한 수동 배포, Continuous Deployment 모든 과정이 자동화로 처리됨

- 빠르고 정확하게 배포를 도와주는 자동화 도구를 사용하는데, 대표적으로 ArgoCD를 많이 사용함

깃허브, 깃옵스 및 깃옵스 리포지터리 역할
- 깃허브(GitHub) : 소프트웨어를 개발할때 소스 코드 버전을 관리하기 위한 원격 저장소
- 깃옵스(GitOps) : 깃허브에 있는 소스 코드를 쿠버네티스 클러스터에 그대로 반영함
- 깃옵스 리포지터리(GitOps Repository) : 매니페스트 파일들이 모여 있는 저장소. 깃옵스는 매니페스틀를 이용해 쿠버네티스 클러스터에 자동으로 배포(반영)하므로 이를 저장하기 위한 저장소

02. 지속적 통합 자동화 도구, 젠킨스

젠킨스

- 소프트웨어 개발 시 지속적으로 통합 서비스를 제공하는 CI 툴

- 다수의 개발자가 개발한 소스 코드를 커밋/빌드하고 개발 환경에 배포하는 일 등을 자동화함

장점
- 프로젝트 환경에서 컴파일 오류 검출
- 테스트를 자동으로 수행
- 코딩 규약 준수 여부 체크(문법 체크)
- 소스 변경에 따른 성능 변화 감시
- 개발자의 소스 통합 및 배포

젠킨스 설치하기

리눅스 패키지를 최신 상태로 업데이트함
- 최신 상태로 업데이트하면 설치할 패키지(소프트웨어)를 최신 버전으로 가져올 수 있음
```
sudo apt update
```
JDK를 설치함
- openjdk 17버전으로 설치함
```
sudo apt install -y openjdk-17-jre-headless
```
- 설치가 잘 된것을 확인할 수 있음
```
java -version
```
젠킨스를 설치하기 위해 필요한 패키지에 접근하기 위해 GPG 키를 추가함
- 리눅스에서 설치하려는 패키지가 기본 리포지터리에 포함되지 않을 수 있음
- 이때 add-apt-repository 명령어를 사용하면 설치하려는 소프트웨어에 대한 접근 권한을 부여함
- 이와 유사한 역할을 하는 것이 GPG(GNU Privacy Guard, GnuPG)
- GPG는 디지털 암호화 및 서명 서비스를 제공하는 OpenPGP
```
wget -q -O - https://pkg.jenkins.io/debian/jenkins.io-2023.key |sudo gpg --dearmor -o /usr/share/keyrings/jenkins.gpg
```
- 명령어의 옵션
  - wget : Web Get의 약어로 웹에서 파일을 내려받을 때 사용하는 명령어
  - -q : quit의 약어로 명령어 실행이 완료되면 별다른 출력 없이 종료함
  - -o : wget을 통해 내려받을 때 저장되는 파일명은 URL의 마지막 / 뒤에 오는 단어로 함. 따라서 jenkins.io.key라는 이름으로 저장됨
  - | : 앞의 명령어의 실행 결과를 뒤의 명령어의 입력으로 넘김
  - gpg - dearmor : gpg 키를 apt가 인식할 수 있는 형식으로 변환함
  - /usr/share/keyrings/jenkins.gpg : jenkins.gpg 키를 추가함
젠킨스 패키지 저장소 주소를 sources.list에 추가해야 함
```
sudo sh -c 'echo deb [signed-by=/usr/share/keyrings/jenkins.gpg] http://pkg.jenkins.io/debian-stable binary/ > /etc/apt/sources.list.d/jenkins.list'
```
- 명령어의 옵션
  - sudo sh : 셸 스크립트로 작성된 파일을 실행하는 명령어
  - -c : 파일이 존재하면 덮어쓰기를 하지 않는 옵션
  - echo : 문자열을 컴퓨터 터미널에 출력하는 명령어
  - deb : deb은 모든 Debian 기반 배포에서 사용하는 설치 패키지 형식. 우분투 리포지터리에는 우분투 소프트웨어 센터, apt 및 app-get 유틸리티를 사용해 설치할 수 있는 수천 개의 deb 패키지가 포함되어 있음
  - [signed-by=/usr/share/keyrings/jenkins.gpg] : GPG 키를 사용해 apt가 내려받은 저장소의 파일을 확인(접근할 수 있는지, 안전한지 등)함
  - http://pkg.jenkins.io/debian-stable binary/ > /etc/apt/sources.list.d/jenkins.list : /etc/apt/sources.list.d 파일에 젠킨스 저장소 주소(http://pkg.jenkins.io/debian-stable binary/)를 추가함
젠킨스를 설치함
```
sudo apt install jenkins
```
젠킨스의 상태를 확인함
- Active로 Running 상태를 보여줌
- Inactive 상태라면 sudo systemctl start jenkins.service 명령어로 젠킨스를 시작할 수 있음
```
sudo systemctl status jenkins
```

젠킨스 설정하기

- 젠킨스 설치를 완료했고 이제 젠킨스를 구성해야 함

브라우저에서 마스터 노드의 IP에 접근함 (2가지 방법중 하나로 하면 됨)
- Hyper-V 관리자에서 master에 접속해 파이어폭스(Firefox) 브라우저에서 localhost:8080에 접근
- Hyper-V가 설치된 컴퓨터의 브라우저에서 마스터노드의 IP:8080으로 접근
아래 화면같이 administrator password 묻는 화면이 나오면 패스워드를 입력한 후 Continue를 클릭함
- 패스워드는 다음 명령어로 확인할 수 있음
```
sudo cat /var/lib/jenkins/secrets/initialAdminPassword
```
기본 플러그인 설치를 진행함
- Administrator password를 입력하면 플러그인 설치와 관련된 옵션들이 나타남
- Install suggested plugins를 클릭해 설치 진행
설치 진행
사용자와 패스워드를 설정
접속할 수 있는 URL을 보여줌
- Save and Finish를 클릭함
젠킨스 사용 준비가 완료되었다는 화면을 보여줌
- Start using Jenkins를 클릭
젠킨스 접속 화면

젠킨스 사용하기

깃허브와 연동하기

- 젠킨스는 빌드를 자동화하는 툴이므로 소스 코드가 저장된 저장소와 연계해야 함

- 깃허브를 저장소로 사용함

깃허브에 연동하기 위해 먼저 깃허브에 접속해 로그인함
젠킨스에서 깃허브에 접속할 수 있는 토큰을 생성해야 함
- 오른쪽 상단의 프로필 → Settings
왼쪽 메뉴 하단의 Developer settings를 선택
Personal access tokens에서 Tokens을 클릭 후 Generate new token(classic) 클릭함
Note에 토큰 이름을 지정하고 Expiration 부분은 No expiration을 선택함
scopes에서는 다음과 같은 항목을 선택한 후 Generate token을 클릭함
- scopes는 젠킨스에서 깃허브에 접속해 사용할 수 있는 권한에 관한 것, 리포지터리와 자동 빌드를 위한 권한만 체크
생성된 토큰을 저장해둠
젠킨스로 이동해 깃허브와 연결함
- 젠킨스 화면의 왼쪽 메뉴에서 Manage Jenkins를 클릭함
System Configuration 에서 System을 클릭
화면을 하단으로 이동하면 GitHub라는 메뉴가 있음 Add GitHub Server > GitHub Server를 선택함
깃허브 접속을 위한 Credential 설정
- Name : access_github
- API URL : https://api.github.com
- Credentials : Add > Jenkins를 선택
깃허브에 연결하기 위한 권한을 설정할 수 있는 화면이 나타남. 다음과 같이 설정함
- Domain은 그대로 두고, Kind는 Secret text를 선택함
- Secret에서는 앞에서 저장했던 토큰을 입력하고, ID는 토큰 이름을 지정함
- 이후 Add를 클릭함
이후 Credentials 아래 리스트 박스를 클릭하면 생성했던 jenkins_token1이 보임. 이것을 선택함
Test connection 버튼을 클릭해 정상적으로 연결되는 것을 확인한 후 Save 버튼을 클릭함
- 테스트 결과 'Credentials verified for user [user ID], rate limit: 4999'가 나타나면 연결에 성공한 것

프로젝트 생성하기

- 이제 젠킨스에서 소스 코드를 자동 빌드하는 프로젝트 생성함

젠킨스 메인 화면의 왼쪽 메뉴에서 New Item을 클릭함
다음 메뉴에서 item name을 입력한 후 Freestyle project를 선택하고 OK 버튼을 클릭
빌드 방법을 지정하기 위해 Triggers를 선택함
- 'Github hook trigger for GITScm polling'을 체크하면 왼쪽 하단에 save와 apply가 나타나는데, save를 클릭
그러면 다음과 같은 메뉴가 나타나는데 Configure를 클릭함
깃허브에 접속할 수 있는 권한을 생성함
- '소스 코드 관리'로 이동해 Credentials에서 Add > Jenkins를 클릭함
그러면 다음과 같은 창이 뜨는데 Kind에 Username with password를 선택함
다음과 같은 항목만 채운 상태에서 Add를 클릭함
- 이때 Username에는 깃허브 계정을 입력하고 Password에는 토큰을 입력함
이제 다음과 같이 -none-이 위치한 리스트 박스를 클릭하면 생성했던 credential이 나타나는데 본인의 깃허브 계정을 선택
권한 설정이 완료되었으므로 이제 깃허브 주소가 필요함
- URL을 확인하기 위해 깃허브에 다시 접속해 깃허브 아이콘을 클릭한 후 New를 클릭함
Repository name을 입력한 후 하단의 Create repository를 클릭함
이후 다음과 같은 주소를 보여줌. 이 주소를 복사함
다시 젠킨스로 이동해 Source Code Management로 이동하고 Repository URL 항목에 앞에서 복사해 둔 주소를 입력함
- 입력후 Advanced...를 클릭
Branches to build에는 */main을 입력한 후 Save를 클릭함
- 기본은 master이지만 깃허브의 branch 이름을 입력함

빌드 도구 설정하기

- 젠킨스는 지속적 통합, 프로젝트 빌드, 테스트 실행, 배포 등의 작업을 자동화함

- 이것이 가능하도록 메이븐(Maven), 앤트(Ant), 그래들(Gradle) 같은 빌드 도구를 이용하고, 깃허브, SVN(SubVersion) 같은 형상 관리 툴을 지원함

- 젠킨스에서 실행될 빌드 도구를 설정해야함

앤트 빌드 도구의 특징	메이븐 빌드 도구의 특징	그래들 빌드 도구의 특징
- XML 기반으로 빌드 스크립트를 작성함 - 간단하고 사용이 쉬움 - 프로젝트 규모가 클 경우 스크립트 관리나 빌드 과정이 복잡함	- XML 기반으로 작성함 - 생명 주기(Lifecycle)와 프로젝트 객체 모델(POM, Project Object Model)이란 개념이 도입됨 - 상대적으로 학습 장벽이 높음 - 라이브러리가 서로 의존적이면 사용이 복잡함	- 라이브러리 의존성 관리를 위한 다양한 방법을 제공함 - 빌드 스크립트를 XML이 아닌 JVM에서 동작하는 스크립트 언어 '그루비' 기반의 DSL을 사용함 - 사용이 쉽고 빌드 과정이 간단함

wget 명령어를 이용해 /tmp 디렉터리에 그래들 설치 파일(zip 파일)을 내려받음
- 이때 -P는 파일을 저장할 디렉터리를 지정할 때 사용하는 옵션
```
wget https://services.gradle.org/distributions/gradle-7.4.2-bin.zip -P /tmp
```
모두 내려받았으면 /opt/gradle 디렉터리에 압축을 해제함
```
sudo unzip -d /opt/gradle /tmp/gradle-*.zip
```
/opt/gradle/gradle-7.4.2 디렉터리에 그래들 파일이 있는지 확인함
```
ls /opt/gradle/gradle-7.4.2
```
그래들에 대한 환경 변수를 설정함
- gradle.sh 파일에 GRADLE_HOME 경로를 설정함
- 그다음에는 ctrl+x 입력 후 y를 누르고 enter를 누름
```
sudo nano /etc/profile.d/gradle.sh
```
```
export GRADLE_HOME=/opt/gradle/gradle-7.4.2
export PATH=${GRADLE_HOME}/bin:${PATH}
```
chmod + x 명령어를 실행해 스크립트를 실행할 수 있도록 권한을 부여함
```
sudo chmod +x /etc/profile.d/gradle.sh
```
source 명령어를 사용해 환경 변수를 가져옴
- source 명령어는 스크립트 파일을 수정한 뒤 바로 수정된 값을 적용할 때 사용
```
 source /etc/profile.d/gradle.sh
```
그래들이 제대로 설치되었는지 그래들 버전을 표시하는 명령어로 확인함
```
gradle -v
```
이제 그래들을 사용하기 위해 젠킨스로 이동해 Jenkins 관리 - Tools를 클릭함
화면을 아래로 내려 Gradle을 찾은 후 Add Gradle을 클릭함
다음과 같이 입력한 후 맨 밑에 있는 Save를 클릭함
- Install automatically : 선택 해제
- name : 젠킨스 내에서 사용할 이름 설정
- GRADLE_HOME : 앞에서 PATH로 등록한 경로
초기 화면으로 돌아오면 다시 New Item을 클릭함
All이라는 메뉴가 생기는데 All 메뉴 옆의 화살표를 클릭하고 앞에서 생성해둔 Jenkins_test를 클릭함
구성 - Build Steps으로 이동해 Add build step에서 Invoke Gradle script를 선택함
이제 그래들에 대해 다음과 같이 설정함
- Gradle Version : 앞에서 설정한 이름을 선택함
- Task : clean을 입력함(clean은 디스크 초기화 명령어)
웹훅(webhook)을 설정하기 위해 다시 깃허브로 이동해서 Settings를 클릭함
- 웹훅 : 특정 이벤트가 발생하고 나서 특정 스크립트를 실행시킬 때 사용. 따라서 다른 서비스와의 통합이나 특정 API를 호출할 때 사용함
Webhooks 메뉴로 이동한 후 Add webhook 버튼을 클릭함
- URL(젠킨스가 실행되고 있는 노드의 IP와 포트)과 Content Type(application/json)을 선택
- Add webhook 버튼 클릭
- 입력한 IP가 공인 IP가 아니라면 생성 후 오류가 발생할 수 있음
이후 젠킨스로 돌아와서 다음과 같이 '지금 빌드'를 클릭함
- 자동으로 빌드가 진행됨
- 깃허브에 소스 코드를 저장한 후 수정하면 자동으로 빌드가 됨
- 혹은 '지금 빌드'를 클릭해 강제로 빌드를 할 수도 있음

03. 지속적 배포 자동화 도구, ArgoCD

ArgoCD

- 깃옵스 기반의 자동화 배포 도구

- 깃옵스 리포지터리에 저장된 매니페스트가 쿠버네티스 운영 환경에도 똑같이 반영되도록 하는것

- 이미지를 배포할 때 툴(ArgoCD, Flux CD 등)이 자동으로 변경된 부분을 인식해서 쿠버네티스에 배포함

ArgoCD의 특징
- 지정된 환경에 애플리케이션을 자동으로 배포하고 관리
- 다수의 클러스터를 단일의 환경에서 관리
- RBAC기반의 권한 부여
- 깃옵스 리포지터리를 사용하므로 백업 및 롤백 가능
- 애플리케이션 리소스의 상태 분석

ArgoCD 설치하기

ArgoCD 설치를 위해 argocd라는 네임스페이스를 먼저 생성함
```
kubectl create namespace argocd
```
클러스터에 ArgoCD를 설치함
- 설치를 위해 다음 명령어를 이용하며, -f 옵션은 yaml 파일과 함께 사용할 때 사용
```
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml
```
ArgoCD를 외부에서 접속할 수 있도록 서비스의 타입을 로드밸런서(LoadBalancer)로 설정함
```
kubectl patch svc argocd-server -n argocd -p '{"spec": {"type" : "LoadBalancer"}}'
```

API 서버와의 상호작용을 위해 ArgoCD CLI를 설치함

VERSION=$(curl --silent "https://api.github.com/repos/argoproj/argo-cd/releases/latest" \
  | grep '"tag_name"' \
  | sed -E 's/.*"([^"]+)".*/\1/')

sudo curl -sSL -o /usr/local/bin/argocd https://github.com/argoproj/argo-cd/releases/download/$VERSION/argocd-linux-amd64

sudo chmod +x /usr/local/bin/argocd

설치가 끝나면 ArgoCD 접속을 위해 필요한 admin 사용자의 패스워드를 확인함
- admin으로 비밀번호를 변경하는 과정을 거침

htpasswd -bnBC 12 "" admin | tr -d ':\n'

- 위 명령어로 나온 결과의 값을 복사 후 아래의 코드에 붙여넣음

kubectl -n argocd patch secret argocd-secret \
  -p '{"stringData": {
    "admin.password": "(위의 해시 비밀번호)",
    "admin.passwordMtime": "'$(date +%FT%T%Z)'"}}'

- ArgoCD 서버 Pod 재시작

kubectl -n argocd delete pod -l app.kubernetes.io/name=argocd-server # Argo CD 서버 Pod 재시작

ArgoCD에 접속할 포트 번호 확인
- http는 30456를 사용하고, https는 32490을 사용함
```
kubectl get svc -n argocd argocd-server
```
브라우저에서 마스터 노드의 IP에 접근함 (2가지 방법중 하나로 하면 됨)
- Hyper-V 관리자에서 master에 접속해 파이어폭스(Firefox) 브라우저에서 localhost:32490에 접근
- Hyper-V가 설치된 컴퓨터의 브라우저에서 마스터노드의 IP:32490으로 접근
- URL : https://localhost:32490
- 사용자 : admin / 패스워드 : (앞에서 설정한 패스워드)

ArgoCD 사용하기

- 리포지터리 연결 및 애플리케이션 배포 설정 확인

설정을 클릭 후 Repositories를 클릭함
리포지터리에 연결할 수 있는 방법들을 보여주는데, +CONNECT REPO를 클릭함
연결 방법은 HTTP/HTTPS, Repository URL에는 젠킨스에서 사용했던 깃허브 주소, username에는 깃허브에서 사용하는 사용자, password에는 깃허브 토큰을 입력한 후 상단의 connect를 클릭함
다음와 같이 정상적으로 연결된 화면이 나옴
애플리케이션을 배포하기 위해 왼쪽 메뉴의 두 번째 아이콘을 클릭한 후 New App을 클릭함
General 항목은 다음과 같이 설정
- Application Name은 임의로 지정
Source 지정을 위해 먼저 깃허브에 접속해 Creating a new file을 클릭함
- 입력 후에는 반드시 /를 추가해야 함
- 입력할 이름 역시 임의로 지정
이후 다시 argoCD로 돌아와서 Source 부분의 Path에 앞에서 지정한 Resources/App를 지정함
Destination은 다음과 같이 설정한 후 상단의 Create를 클릭
다음과 같이 정상적으로 설정된 것을 확인할 수 있음
- argocd-test를 클릭함
Resources/App에 위치한 Readme.md 파일이 자동으로 동기화되어 다음 그림과 같이 현재 동기화 상태임을 확인

2. 쿠버네티스 리소스 관리

01. 쿠버네티스 모니터링

쿠버네티스 모니터링

- 쿠버네티스 환경을 안정적으로 관리하고 운영하기 위한 모니터링 방법을 살펴봄

- 쿠버네티스를 모니터링할 때 사용하는 도구는 데이터독(Datadog)과 프로메테우스(Prometheus)

- 어떤 것을 사용하느냐는 사용하려는 환경이나 사용자마다 다를 수 있음

구분	데이터독	프로메테우스
구축 형태	SaaS (클라우드 형태로 구축)	직접 구축
설치	간편함	그라파나까지 연계할 경우 상대적으로 복잡함
그래프	상대적으로 강력한 그래프 기능 제공	그래프(시각화) 취약, 그라파나와 연계해야 데이터독 수준의 그래프 기능 제공
쿠버네티스 이벤트	쿠버네티스 클러스터에서 발생하는 이벤트를 수집함	쿠버네티스 클러스터에서 발생하는 이벤트를 수집하기 위해 또 다른 솔루션이 필요함
알람	유형별 알람 설정에 제한적(프로메티우스의 알람 매니저가 제공하는 기능보다 제한적)	알람 매니저(alertmanager)를 설치해야 함

데이터독

- 실시간 데이터 통합 플랫폼을 지향

- 클라우드 모니터링 서비스로 시작해 시스템 모니터링, 로그 관리 등의 기능을 추가하면서 종합 모니터링 플랫폼으로 성장함

- 쿠버네티스 환경뿐만 아니라 기업의 시스템에 대한 전반적인 모니터링을 제공함

- 데이터독을 쿠버네티스에 사용한다면 파드와 컨테이너 같은 쿠버네티스 클러스터의 구성 요소와 워크로드, 네트워크 트래픽 등을 모니터링할 수 있음

- 모니터링에 사용되는 메트릭 정보는 각 노드에 설치된 에이전트를 통해 수집됨

데이터독의 기능
- 대시보드 : 임계치를 설정해 성능에 관한 지표를 수집하고 수집된 내용을 한눈에 파악할 수 있도록 대시보드에 시각적으로 보여줌
- 시스템 : 데이터독에 등록된 노드를 포함해 기업에서 관리하는 시스템과 네트워크(트래픽 흐름)에 대한 전반적인 내용을 확인할 수 있음
- 로그 수집 : 시스템 및 애플리케이션에서 발생하는 로그를 수집함
모니터링에 필요한 에이전트
- 클러스터 에이전트 : 쿠버네티스 API 서버와 데이터독 에이전트(모든 워커 노드에 배포) 간의 프록시 역할을 하는 에이전트
- 데몬셋 에이전트 : 모든 워커 노드에 배포되는 데몬셋 에이전트
데이터독 설치하기
1. https://www.datadoghq.com/ 에 접속한 후 FREE TRIAL을 클릭함
  - 유료 서비스이지만 테스트 용도로 사용할 수 있는 트라이얼 버전을 제공하고 있음
2. 필요한 정보를 입력한 후 Sign up을 클릭함
3. 어떤 환경을 사용할지를 묻는 화면, Kubernetes를 선택하고 Next를 클릭함
4. 설치를 진행할 OS에 맞게 선택함
  - 오른쪽 화면에서 다음과 같이 'Install the Datadog Agent on Linux'에 나타난 명령어를 복사함
  - 복사한 명령어를 마스터노드와 워커 노드에서 실행함
5. 설치가 끝나면 데이터독 에이전트를 시작함
```
systemctl start datadog-agent
```
6. 다시 URL에 접속해 메인 페이지로 이동하면 노드들이 추가된 것을 확인할 수 있음
7. 노드에 대한 모니터링 항목들이 수집되고, 수집된 내용을 대시보드에서 확인할 수 있음

프로메테우스

- 사운드클라우드(SoundCloud)에서 최초로 개발했고 현재는 CNCF(오픈소스)에 속한 모니터링 솔루션

- 기본적인 데이터 수집은 풀(가져오는 방식) 구조로 되어 있어서 프로메테우스 서버가 수집하려는 대상에서 데이터를 가져옴

- 수집된 메트릭 값을 저장하기 위한 볼륨이 필요하며, 관리자에게 알림을 발송해야 하는 상황에서는 알람 매니저(alert-manager)를 이용함

프로메테우스 특징
- 그라파나를 통한 시각화 지원
- 많은 시스템을 모니터링할 수 있는 다양한 플러그인 지원함
- 쿠버네티스의 모니터링 시스템으로 많이 사용됨

프로메테우스와 관련해 네임스페이스를 생성하는 것
- monitoring이라는 이름으로 네임스페이스를 생성함
```
kubectl create ns monitoring
```

prometheus-cluster-role.yaml을 작성함
- 쿠버네티스의 리소스는 API를 통해 접근할 수 있지만 API를 외부에서 접근하는 것은 보안에 의해 강력히 통제됨
- 쿠버네티스 API에 접근할 수 있는 권한을 부여하기 위해 클러스터 역할을 설정하고 클러스터 역할 바인딩을 함

apiVersion: rbac.authorization.k8s.io/v1    
kind: ClusterRole
metadata:
  name: prometheus
  namespace: monitoring
rules:
- apiGroups: [""]
  resources:    
  - nodes
  - nodes/proxy
  - services
  - endpoints
  - pods
  verbs: ["get", "list", "watch"]
- apiGroups:
  - extensions
  resources:
  - ingresses
  verbs: ["get", "list", "watch"]
- nonResourceURLs: ["/metrics"]
  verbs: ["get"]
---
apiVersion: rbac.authorization.k8s.io/v1    
kind: ClusterRoleBinding
metadata:
  name: prometheus
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: prometheus
subjects:
- kind: ServiceAccount
  name: default
  namespace: monitoring

kubectl apply 명령어로 클러스터 역할 바인딩을 생성함
```
kubectl apply -f prometheus-cluster-role.yaml
```

prometheus-config-map.yaml 파일 작성
- 프로메테우스에서 수집할 지표를 정의해야 함
- 환경 설정과 관련된 것으로 컨피그맵을 이용함
- 어떤 지표를 어느 주기로 수집할 것인지, 알람은 어떨 때 받을지에 대한 환경 설정 내용

apiVersion: v1
kind: ConfigMap
metadata:
  name: prometheus-server-conf
  labels:
    name: prometheus-server-conf
  namespace: monitoring
data:
  prometheus.rules: |-    
    groups:
    - name: container memory alert
      rules:
      - alert: container memory usage rate is very high( > 55%)
        expr: sum(container_memory_working_set_bytes{pod!="", name=""})/ sum (kube_node_status_allocatable_memory_bytes) * 100 > 55
        for: 1m
        labels:
          severity: fatal
        annotations:
          summary: High Memory Usage on
          identifier: ""
          description: " Memory Usage: "
    - name: container CPU alert
      rules:
      - alert: container CPU usage rate is very high( > 10%)
        expr: sum (rate (container_cpu_usage_seconds_total{pod!=""}[1m])) / sum (machine_cpu_cores) * 100 > 10
        for: 1m
        labels:
          severity: fatal
        annotations:
          summary: High Cpu Usage
  prometheus.yml: |-    
    global:
      scrape_interval: 5s
      evaluation_interval: 5s
    rule_files:
      - /etc/prometheus/prometheus.rules
    alerting:
      alertmanagers:
      - scheme: http
        static_configs:
        - targets:
          - "alertmanager.monitoring.svc:9093"
    scrape_configs:
      - job_name: 'kubernetes-apiservers'
        kubernetes_sd_configs:
        - role: endpoints
        scheme: https
        tls_config:
          ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
        bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token
        relabel_configs:
        - source_labels: [__meta_kubernetes_namespace, __meta_kubernetes_service_name, __meta_kubernetes_endpoint_port_name]
          action: keep
          regex: default;kubernetes;https
      - job_name: 'kubernetes-nodes'
        scheme: https
        tls_config:
          ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
        bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token
        kubernetes_sd_configs:
        - role: node
        relabel_configs:
        - action: labelmap
          regex: __meta_kubernetes_node_label_(.+)
        - target_label: __address__
          replacement: kubernetes.default.svc:443
        - source_labels: [__meta_kubernetes_node_name]
          regex: (.+)
          target_label: __metrics_path__
          replacement: /api/v1/nodes/${1}/proxy/metrics
      - job_name: 'kubernetes-pods'
        kubernetes_sd_configs:
        - role: pod
        relabel_configs:
        - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape]
          action: keep
          regex: true
        - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_path]
          action: replace
          target_label: __metrics_path__
          regex: (.+)
        - source_labels: [__address__, __meta_kubernetes_pod_annotation_prometheus_io_port]
          action: replace
          regex: ([^:]+)(?::\d+)?;(\d+)
          replacement: $1:$2
          target_label: __address__
        - action: labelmap
          regex: __meta_kubernetes_pod_label_(.+)
        - source_labels: [__meta_kubernetes_namespace]
          action: replace
          target_label: kubernetes_namespace
        - source_labels: [__meta_kubernetes_pod_name]
          action: replace
          target_label: kubernetes_pod_name
      - job_name: 'kube-state-metrics'
        static_configs:
          - targets: ['kube-state-metrics.kube-system.svc.cluster.local:8080']
      - job_name: 'kubernetes-cadvisor'
        scheme: https
        tls_config:
          ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
        bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token
        kubernetes_sd_configs:
        - role: node
        relabel_configs:
        - action: labelmap
          regex: __meta_kubernetes_node_label_(.+)
        - target_label: __address__
          replacement: kubernetes.default.svc:443
        - source_labels: [__meta_kubernetes_node_name]
          regex: (.+)
          target_label: __metrics_path__
          replacement: /api/v1/nodes/${1}/proxy/metrics/cadvisor
      - job_name: 'kubernetes-service-endpoints'
        kubernetes_sd_configs:
        - role: endpoints
        relabel_configs:
        - source_labels: [__meta_kubernetes_service_annotation_prometheus_io_scrape]
          action: keep
          regex: true
        - source_labels: [__meta_kubernetes_service_annotation_prometheus_io_scheme]
          action: replace
          target_label: __scheme__
          regex: (https?)
        - source_labels: [__meta_kubernetes_service_annotation_prometheus_io_path]
          action: replace
          target_label: __metrics_path__
          regex: (.+)
        - source_labels: [__address__, __meta_kubernetes_service_annotation_prometheus_io_port]
          action: replace
          target_label: __address__
          regex: ([^:]+)(?::\d+)?;(\d+)
          replacement: $1:$2
        - action: labelmap
          regex: __meta_kubernetes_service_label_(.+)
        - source_labels: [__meta_kubernetes_namespace]
          action: replace
          target_label: kubernetes_namespace
        - source_labels: [__meta_kubernetes_service_name]
          action: replace
          target_label: kubernetes_name

생성한 컨피그맵 파일을 kubectl apply 명령으로 실행함
```
kubectl apply -f prometheus-config-map.yaml
```

prometheus-deployment.yaml 파일을 작성함
- 프로메테우스를 통해 수집한 데이터를 저장할 볼륨이 필요함
- 따라서 파드에는 메트릭 정보가 저장될 저장소를 설정해야 함
- 해당 파일에 디플로이먼트를 생성하고 해당 파드에 저장소를 연결하는 내용을 입력함

apiVersion: apps/v1
kind: Deployment
metadata:
  name: prometheus-deployment
  namespace: monitoring
spec:
  replicas: 1
  selector:
    matchLabels:
      app: prometheus-server
  template:
    metadata:
      labels:
        app: prometheus-server
    spec:
      containers:
        - name: prometheus
          image: prom/prometheus:latest   
          args:
            - "--config.file=/etc/prometheus/prometheus.yml"
            - "--storage.tsdb.path=/prometheus/"
          ports:
            - containerPort: 9090
          volumeMounts:    
            - name: prometheus-config-volume
              mountPath: /etc/prometheus/
            - name: prometheus-storage-volume
              mountPath: /prometheus/
      volumes:
        - name: prometheus-config-volume
          configMap:
            defaultMode: 420
            name: prometheus-server-conf
        - name: prometheus-storage-volume
          emptyDir: {}

kubectl apply를 통한 디플로이먼트(파드)를 생성함
```
kubectl apply -f prometheus-deployment.yaml
```

prometheus-node-exporter.yaml 파일을 생성하여 노드 내보내기에 대해 정의함
- 노드 내보내기(node exporter) : 쿠버네티스 노드에 대한 정보를 수집하는 역할을 함
- 각 노드에 하나씩 파드 형태로 존재해야 하므로 데몬셋으로 만들어야 함
- 데몬셋으로 '노드 내보내기'를 생성하고, 이것을 외부에 노출시키기 위한 서비스를 생성함

apiVersion: apps/v1
kind: DaemonSet    
metadata:
  name: node-exporter
  namespace: monitoring
  labels:
    k8s-app: node-exporter
spec:
  selector:
    matchLabels:
      k8s-app: node-exporter
  template:
    metadata:
      labels:
        k8s-app: node-exporter
    spec:
      containers:
      - image: prom/node-exporter
        name: node-exporter
        ports:
        - containerPort: 9100
          protocol: TCP
          name: http
---
apiVersion: v1
kind: Service
metadata:
  labels:
    k8s-app: node-exporter
  name: node-exporter
  namespace: kube-system
spec:
  ports:
  - name: http
    port: 9100
    nodePort: 31672
    protocol: TCP
  type: NodePort
  selector:
    k8s-app: node-exporter

kubectl apply 명령어로 데몬셋과 서비스를 생성함
```
kubectl apply -f prometheus-node-exporter.yaml
```

prometheus-svc.yaml 파일을 작성해 외부에서 프로메테우스 서비스에 접속할 수 있도록 노드포트를 사용함
- 외부에서 프로메테우스 파드에 접근하기 위한 노드포트를 정의함
- 노드포트는 30001을 사용하도록 지정함

apiVersion: v1
kind: Service
metadata:
  name: prometheus-service
  namespace: monitoring
  annotations:
      prometheus.io/scrape: 'true'
      prometheus.io/port:   '9090'
spec:
  selector:
    app: prometheus-server
  type: NodePort    
  ports:
    - port: 8080
      targetPort: 9090
      nodePort: 30001

프로메테우스 파드에 접속하기 위한 서비스를 생성함
```
kubectl apply -f prometheus-svc.yaml
```
외부에서 접속할 때에는 노드IP:300001을 이용해 접속함
- 현재 마스터 노드 1대, 워커 노드 1대로 구성되어 있음.
- 따라서 워커 노드 1대에 데몬셋 파드(node-exporter)가 배포되었으며, 프로메테우스 용도의 파드가 1개 실행 중
```
kubectl get pod -n monitoring
```
마스터 노드IP :30001로 접속함
- 접속한 화면이 아래와 같으면 프로메테우스가 정상적으로 설치된 것

* 프로메테우스는 단독으로 운영하는 것보다는 그라파나와 함께 연동해야 완벽한 모니터링을 구축할 수 있어서 보통 함께 사용함

그라파나

- 수집된 메트릭을 이용해 조회, 시각화, 경고 등의 기능을 지원함

- 프로메테우스, 엘라스틱서치(Elasticsearch), OpenTSDB 및 인플럭스 DB(InfluxDB) 같은 시계열 데이터베이스를 지원함

- 구글 스택드라이버(Google Stackdriver), 아마존 클라우드와치(Amazon Cloudwatch), 마이크로소프트 애저 같은 퍼블릭 클라우드는 물론 MySQL, Postgres 같은 SQL 데이터베이스도 지원함

- 프로메테우스에서 수집한 메트릭을 이용해 해당 데이터를 대시보드에서 시각적으로 보여주는 툴

그라파나 설치하기

grafana.yaml 파일을 먼저 작성함
- 데이터 시각화를 표현할 대시보드 생성
- yaml 파일에서는 그라파나 이미지를 가져와서 디프로링먼트를 생성하고 이를 외부로 노출하기 위한 서비스도 함께 생성

apiVersion: apps/v1
kind: Deployment
metadata:
  name: grafana
  namespace: monitoring
spec:
  replicas: 1
  selector:
    matchLabels:
      app: grafana
  template:
    metadata:
      name: grafana
      labels:
        app: grafana
    spec:
      containers:
      - name: grafana
        image: grafana/grafana:latest    
        ports:
        - name: grafana
          containerPort: 3000
        env:    
        - name: GF_SERVER_HTTP_PORT
          value: "3000"
        - name: GF_AUTH_BASIC_ENABLED
          value: "false"
        - name: GF_AUTH_ANONYMOUS_ENABLED   
          value: "true"
        - name: GF_AUTH_ANONYMOUS_ORG_ROLE  
          value: Admin
        - name: GF_SERVER_ROOT_URL
          value: /
---
apiVersion: v1
kind: Service
metadata:
  name: grafana
  namespace: monitoring
  annotations:
      prometheus.io/scrape: 'true'
      prometheus.io/port:   '3000'
spec:
  selector:
    app: grafana
  type: NodePort
  ports:
    - port: 3000
      targetPort: 3000
      nodePort: 30004

디플로이먼트(파드)와 서비스를 생성함
```
kubectl apply -f grafana.yaml
```

프로메테우스와 연동하기

브라우저에서 IP:30004로 접속하면 그라파나 화면이 보임
- 화면에서 add your first data source를 클릭함
Prometheus를 클릭함
HTTP URL에 Prometheus-service의 IP를 입력하고 포트는 8080을 사용
- Prometheus-service의 IP는 kubectl get svc -n monitoring을 통해 확인함
마지막으로 맨아래의 Save & test를 클릭함
- 다음과 같은 화면을 볼 수 있음

대시보드 생성하기

https://grafana.com/grafana/dashboards/로 이동함
- 다양한 유형의 모니터링 템플릿들이 있음
- 검색 부분에 Kubernetes Cluster (Prometheus)를 입력하고 결과중 첫 번째 검색 결과를 클릭함
이동한 화면에서 Copy ID to Clipboard를 클릭해 ID를 복사해 둠
그라파나 화면으로 돌아와서 왼쪽 메뉴 중 대시보드 아이콘 → New → Import 버튼을 클릭함
- 그라파나 웹페이지에서 제공하는 대시보드를 가져올 수 있음
앞에서 복사해 둔 ID를 붙여넣기하고 Load를 클릭함
Prometheus에 Prometheus를 선택한 후 Import를 클릭함
다음과 같이 모니터링 대시보드가 구성됨

02. 컨테이너 리소스 관리하기

- 하나의 노드에는 수십 개에서 수백 개의 파드가 떠 있을 수 있음

- 만약 하나의 파드에서 과도하게 자원(CPU, 메모리 등)을 사용한다면 다른 파드에 영향을 줄 수 있으므로 노드와 파드의 사용량을 지속적으로 모니터링 해야함

- 파드 자원의 사용률이 낮다면 회수하고, 사용률이 높다면 추가적인 자원을 할당하거나 파드를 늘려야함

- 가장 효율적으로 자원을 관리할 수 있는 LimitRange와 오토스케일링 방법에 대해 배움

LimitRange 사용하기

- 파드(컨테이너)에서 사용할 수 있는 리소스(자원)의 사용률을 제한하는 것을 의미함

- CPU가 어느 한계(ex: 80%)에 다다르면 더 이상 사용률이 증가하지 못하도록 설정함

set-limit-range.yaml라는 파일을 작성함
- 생성한 파일에 CPU에 대한 최소값과 최대값을 지정하는 내용을 입력함

apiVersion: v1
kind: LimitRange
metadata:
  name: set-limit-range
spec:
  limits:
  - max:
      cpu: "800m"
    min:
      cpu: "200m"
    type: Container

limitrange를 생성하고, 상태를 확인함
- CPU의 min과 max가 각각 0.2CPU, 0.8CPU로 설정되어 있음
- 1밀리코어(milicore)는 CPU의 1/1000을 의미하므로 800밀리코어는 0.8 코어(core)를 의미함
```
kubectl apply -f set-limit-range.yaml
```
```
kubectl get limitrange

kubectl describe limitrange set-limit-range
```
pod-with-cpu-range.yaml 파일을 작성함
- CPU 요청량(노드에 요청하는 CPU 사이즈)과 최대 사이즈를 지정하기 위함
- CPU 요청량은 500밀리코어, 최대 사이즈는 800밀리코어를 사용하도록 설정함
```
apiVersion: v1
kind: Pod
metadata:
  name: pod-with-cpu-range
spec:
  containers:
  - name: pod-with-cpu-range
    image: nginx
    resources:
      limits:
        cpu: "800m"
      requests:
        cpu: "500m"
```
CPU 사용이 제한된 파드를 생성함
```
kubectl create -f pod-with-cpu-range.yaml
```
파드의 상태를 확인함
- CPU 요청량은 500 밀리코어, 최대 사이즈는 800밀리코어로 설정된 것을 확인할 수 있음
- 하지만 이렇게 자원 사용량에 제한을 두면 서비스 속도에 문제가 발생할 수 있음
- 서비스에 어떠한 영향도 주지 않으면서 빠른 속도를 보장하기 위해 사용하는 것이 오토스케일링
```
kubectl get pods

kubectl describe pod pod-with-cpu-range
```
- requests : 적어도 지정된 만큼의 자원은 컨테이너에서 사용할 수 있도록 보장함
- limits : 유휴 자원이 있다면 최대 지정된 만큼의 자원까지 컨테이너가 사용할 수 있음

오토스케일링

- 할당된 파드의 자원 사용률이 너무 낮거나 높을 때 리소스의 크기를 조정하는 것을 의미함

- 시스템 스스로 자원 사용률을 감지해 자동으로 파드를 늘려주거나 줄여줄 필요가 있음

- 최대 몇 대까지 늘려줄 수 있는지 지정할 수 있는데, 이것을 최대 사이즈라고 함

- 최소 사이즈와 최대 사이즈를 지정해 늘리고 줄이는 파드의 개수를 조정할 수 있음

오토스케일링의 동작 방식
1. 메트릭스 서버에 각 파드에서 사용 중인 자원(ex: CPU, 메모리)이 어느 정도인지 질의함
2. 반환값에 따라 몇 개의 파드를 늘려야 하는지 수평적 파드 오토스케일링(horizontal pod autoscaler)에서 계산함
3. 계산된 파드의 개수만큼 애플리케이션 파드를 늘림

메트릭 서버는 자동으로 설치되지 않아서 수동으로 설치함

kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml

설치가 완료되었다면 메트릭 디플로이먼트 설정을 변경함
- 변경하지 않으면 메트릭 서버가 작동하지 않음
```
kubectl edit deployments.apps -n kube-system metrics-server
```
API 서버(kube-apiserver)의 설정을 변경함
- 이 설정도 변경하지 않으면 메트릭 서버가 작동하지 않음
```
vi /etc/kubernetes/manifests/kube-apiserver.yaml
```

php-apache.yaml라는 파일을 작성함
- 오토스케일링 테스트를 위한 디플로이먼트와 서비스 생성을 위함
- php-apache라는 이름의 디플로이먼트를 생성할 때 사용할 수 있는 CPU 범위(최대 500m)를 지정

apiVersion: apps/v1
kind: Deployment
metadata:
  name: php-apache
spec:
  selector:
    matchLabels:
      run: php-apache
  replicas: 1
  template:
    metadata:
      labels:
        run: php-apache
    spec:
      containers:
      - name: php-apache
        image: k8s.gcr.io/hpa-example
        ports:
        - containerPort: 80
        resources:
          limits:
            cpu: 500m
          requests:
            cpu: 200m
---
apiVersion: v1
kind: Service
metadata:
  name: php-apache
  labels:
    run: php-apache
spec:
  ports:
  - port: 80
  selector:
    run: php-apache

kubectl apply 명령어로 디플로이먼트와 서비스를 생성함
```
kubectl apply -f php-apache.yaml
```
오토스케일링을 설정함
- 파드의 개수를 늘리거나 줄이도록 설정함
- CPU 사용률이 50%를 넘긴다면 파드의 개수를 최대 10개까지 늘릴 수 있음
- CPU 사용률이 50% 이하라면 파드의 개수를 줄일 수 있지만 최소 1개는 유지하도록 설정함
```
kubectl autoscale deployment php-apache --cpu-percent=50 --min=1 --max=10
```
어떤 변화도 주지 않았을 때의 CPU 사용률은 0%임
- 현재의 사용률이 <unknown>으로 표시된다면 2~3분 후에 다시 실행하면 됨
```
kubectl get hpa
```
각 파드에 대한 자원 사용률과 현재 몇 개의 파드가 실행 중인지도 확인함
- 현재 한 개의 파드만 실행 중임
```
kubectl top pods

kubectl get deployment php-apache
```
실제로 부하에 따라 파드의 개수가 변하는지 확인하기 위해 강제로 부하를 높임
- 3~5분 정도 후에 실행하면 결과를 눈으로 확인할 수 있음
- 이후 ctrl + c를 눌러 빠져나옴
```
kubectl run -i --tty load-generator --rm --image=busybox --restart=Never -- /bin/sh -c "while sleep 0.01; do wget -q -O- http://php-apache; done"
```
실제로 CPU에 변화가 있는지 확인하고 파드의 개수를 확인함
- CPU 부하는 153%까지 증가함
- 파드는 7개로 증가함
```
kubectl get hpa

kubectl get deployment php-apache
```