You are currently viewing GL-Docker & Kubernetes week4

GL-Docker & Kubernetes week4

1. Kubernetes Probe & GitOps 개요

Probe를 통한 Pod 상태 관리 방법

  • Liveness Probe: 컨테이너가 정상 동작 중인지 확인. 실패 시 재시작
  • Readiness Probe: 서비스 트래픽을 받을 준비가 되었는지 확인. 실패 시 서비스에서 제외
  • Startup Probe: 컨테이너 시작 시 초기화 완료 여부 확인. 초기 구동이 느린 앱에 유용

매니페스트 관리 도구 소개

  • Kustomize: 쿠버네티스 리소스를 오버레이 방식으로 재사용 가능
  • Helm: 템플릿 기반의 패키지 관리 도구. 복잡한 배포 구성에 적합

GitOps 개념 및 도구

  • GitOps: Git을 단일 신뢰 소스로 사용해 쿠버네티스 리소스를 선언적으로 관리
  • ArgoCD: GitOps 방식의 지속적 배포(Continuous Delivery)를 지원하는 대표 도구

실습 환경 구성 (Kind, Controlplane 1 + Worker 1)

  • Windows WSL2 기준, kind 및 환경구성
# Windows WSL2 (Ubuntu) - PowerShell / CMD (관리자 권한)
dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart
dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart
wsl --list -o
wsl --install -d ubuntu

# WSL2 Ubuntu
sudo snap install docker
sudo groupadd docker
sudo usermod -aG docker $USER
docker --version

# Kind 설치
[ $(uname -m) = x86_64 ] && curl -Lo ./kind https://kind.sigs.k8s.io/dl/v0.27.0/kind-linux-amd64
sudo chmod +x ./kind
sudo mv ./kind /usr/local/bin/kind

# Kind Cluster 생성
kind create cluster

# kubectl 설치
sudo snap install kubectl --classic
kubectl get pods -A

# Krew 설치
wget https://github.com/kubernetes-sigs/krew/releases/download/v0.4.5/krew-linux_amd64.tar.gz
tar zxvf krew-linux_amd64
./krew-linux_amd64 install krew
~/.bashrc >> export PATH="${KREW_ROOT:-$HOME/.krew}/bin:$PATH"
source ~/.bashrc
kubectl krew

# k9s 설치
wget https://github.com/derailed/k9s/releases/download/v0.50.4/k9s_linux_amd64.deb
sudo dpkg -i k9s_linux_amd64.deb
sudo apt-get install -f
k9s

# Helm 설치
sudo snap install helm --classic
helm ls

2. Pod LifeCycle

2.1. Probe 개요

Kubernetes Liveness Probes: A Complete Guide

Pod Lifecycle

Pod LifeCycle: Kubernetes에서 파드의 상태를 정의하고 추적하기 위한 일련의 단계

  • PendingRunningSucceeded 또는 Failed
  • 특정 경우 Unknown 상태가 될 수도 있음
Phase설명
Pending– 파드 라이프사이클의 첫 번째 단계
– 파드가 스케줄러에 의해 노드에 할당
– 아직 하나도 컨테이너가 생성 / 준비되지 않은 상태
– 일반적으로
– 노드 리소스 부족 혹은 노드 장애로 인해 사용 불가한 경우
– 컨테이너를 만들기 위한 CPU/메모리 등의 자원이 부족한 경우
– 컨테이너 이미지를 가져오는 중이거나 실패한 경우
Running– 파드가 노드에 성공적으로 스케줄링
– 하나 이상의 컨테이너가 생성되어 실행 중
– 일반적으로
– 컨테이너가 정상적으로 시작되었고, 애플리케이션이 실행 중
– CrashLoopBackOff 또는 재시작 정책에 따라 컨테이너가 반복 실행
Succeeded– 파드 내부의 모든 컨테이너가 정상적으로 종료, 재시작이 필요 없음
– 일반적으로
– Job 등의 일회성 작업
Failed– 파드 내부의 모든 컨테이너가 종료
– 하나 이상이 실패하여 비정상적으로 종료된 경우.
– 일반적으로
– exit code가 0이 아닌 경우
– OOMKilled 등 (exit code 137)
Unknown– kubelet이 파드 상태를 알 수 없음
– 일반적으로
– 노드 다운
– kubelet 또는 apiserver와의 네트워크 통신에 문제

  • 파드 실행 중 컨테이너에 문제가 발생하면
    • kubelte이 재시작 정책에 따라 컨테이너를 재시작
    • Running 상태에서도 재시작이 반복될 수 있음
  • Kubernetes는 파드 내부 각 컨테이너의 상태를 개별적으로 추적하며, 파드를 정상 상태로 유지하거나 재생성할지 여부를 스케줄러와 컨트롤러가 판단


Probe

  • 컨테이너에서 kubelet에 의해 주기적으로 수행되는 진단
    • 일종의 Pod HealthCheck
  • 진단을 수행하기 위해 kubelet은 컨테이너 안에서 코드를 실행하거나 네트워크 요청을 전송

Check mechanisms

방식설명
exec컨테이너 내에서 지정된 명령어를 실행
명령어 상태 코드가 0으로 종료되면 진단이 성공한 것으로 간주
grpcgRPC 클라이언트로 컨테이너의 gRPC 서버에 호출을 전송
서비스의 상태가 SERVING 상태일 경우 진단 성공으로 간주
활성화 위해 GRPCContainerProbe feature gate가 필요
httpGet지정된 포트 및 경로에서 컨테이너의 IP주소에 HTTP GET 요청 수행
응답 상태 코드가 200 이상 400 미만이면 성공으로 간주
SpringBoot의 Actuator와 함께 자주 사용
tcpSocket지정된 포트에서 컨테이너의 IP주소에 대해 TCP 연결 시도
포트가 열려 있고 연결되면 성공으로 간주
연결만 되고 데이터 전송이 없어도 성공으로 간주

Types of Probes

종류설명
livenessProbe컨테이너가 정상적으로 동작 중인지 여부 확인
프로브 실패 시 kubelet은 컨테이너를 죽이고 재시작 정책에 따라 처리
readinessProbe컨테이너가 요청을 처리할 준비가 되었는지 여부 확인
프로브 실패 시, 해당 컨테이너가 속한 파드의 엔드포인트에서 제외되어 서비스 트래픽을 받지 않음
startupProbe애플리케이션이 시작되었는지 여부 확인
성공할 때까지는 다른 프로브가 작동하지 않으며, 지정된 시간 동안 기다려줌
지정된 시간 내에 실패 시 컨테이너를 종료하고 재시작 정책에 따라 처리

2.2. Liveness Probe

Liveness Probe

  • Liveness Probe: 컨테이너를 재시작해야 하는 시점 판단
    • 예를 들어, 애플리케이션이 실행 중이지만 데드락 상태로 진행이 불가능한 경우 등
  • Liveness Probe가 반복적으로 실패하면, kubelet은 해당 컨테이너를 재시작함
  • 실행을 지연시키고 싶다면 다음 중 하나를 사용:
    • initialDelaySeconds를 설정해 일정 시간 후에 Liveness Probe 시작
    • startupProbe를 사용해 애플리케이션 초기 구동 시점 분리
  • 설정되지 않으면 기본적으로 Success
  • 실패시 컨테이너 재시작

Liveness Probe 실습

  • liveness-test용 YAML 생성
cat <<EOF>> liveness-test.yaml
apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-http
spec:
  containers:
  - name: liveness
    image: registry.k8s.io/e2e-test-images/agnhost:2.40
    args:
    - liveness
    livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
        httpHeaders:
        - name: Custom-Header
          value: Awesome
      initialDelaySeconds: 3
      periodSeconds: 3
EOF

kubectl apply -f liveness-test.yaml
  • Probe 설정
    • 컨테이너의 8080 포트의 /healthz 경로가 성공(Status 200)하면 Probe 성공
    • 첫 번째 프로브를 수행하기 전 3초를 기다림
      • initialDelaySeconds: 3
    • kubelet 이 3초마다 LivenessProbe 를 수행
      • periodSeconds: 3
# Pod 확인
watch kubectl get pod -o wide

...
NAME             READY   STATUS    RESTARTS      AGE   IP            NODE          NOMINATED NODE   READINESS GATES
liveness-http    1/1     Running   2 (14s ago)   51s   10.244.1.17   kind-worker   <none>           <none>
...

# Pod 상세 정보
kubectl describe pod liveness-http

...
Events:
  Type     Reason     Age                 From               Message
  ----     ------     ----                ----               -------
  Warning  Unhealthy  19s (x12 over 79s)  kubelet            Liveness probe failed: HTTP probe failed with statuscode: 500
  Normal   Killing    19s (x4 over 73s)   kubelet            Container liveness failed liveness probe, will be restarted
  Warning  BackOff    7s (x3 over 19s)    kubelet            Back-off restarting failed container liveness in pod liveness-http_default(0f16d9a4-b767-410e-8d06-bd802da16b04)
...

결과 확인

  • Liveness: http-get http://:8080/healthz delay=3s timeout=1s period=3s #success=1 #failure=3
  • 요청헤더의 별도 키값을 넣어주지않아 health check 실패, pod 재시작

2.3. Readiness Probe

Readiness Probe

  • Readiness Probe: 컨테이너의 트래픽 수신 가능 여부 판단
    • 네트워크 연결 설정, 파일 로드, 캐시 워밍업 등 시간이 걸리는 초기 작업을 수행하는 동안 체크
  • 실패 시, 해당 파드를 모든 일치하는 서비스 엔드포인트에서 제거
  • 초기 실행시 Failure 상태로 시작, 성공 시 Success > ep 등록
  • 설정되지 않으면 기본적으로 Success로 간주
  • 실패시 svc의 대상에서 제거되어 트래픽 전달X, 재시작 되지는 않음

Readiness Probe 실습

  • readiness probe 생성
cat <<EOF>> readiness-test.yaml
apiVersion: v1
kind: Pod
metadata:
  labels:
    test: readiness
  name: readiness-http
spec:
  containers:
  - name: readiness
    image: registry.k8s.io/e2e-test-images/agnhost:2.40
    args:
    - liveness
    readinessProbe:
      httpGet:
        path: /healthz
        port: 8080
        httpHeaders:
        - name: Custom-Header
          value: Awesome
      initialDelaySeconds: 3
      periodSeconds: 3
EOF

kubectl apply -f readiness-test.yaml
  • Probe 설정
    • 컨테이너의 8080 포트의 /healthz 경로가 성공(Status 200)하면 Probe 성공
    • 첫 번째 프로브를 수행하기 전 3초를 기다림
      • initialDelaySeconds: 3
    • kubelet 이 3초마다 ReadinessProbe 를 수행
      • periodSeconds: 3
# Pod 확인
watch kubectl get pod -o wide

...
NAME             READY   STATUS    RESTARTS   AGE   IP            NODE          NOMINATED NODE   READINESS GATES
readiness-http   0/1     Running   0          19s   10.244.1.18   kind-worker   <none>           <none>
...

# Pod 상세 정보
kubectl describe pod readiness-http

...
Events:
  Type     Reason     Age                 From               Message
  ----     ------     ----                ----               -------
  Warning  Unhealthy  1s (x16 over 43s)  kubelet             Readiness probe failed: HTTP probe failed with statuscode: 500

결과 확인

  • 헤더값이 존재하지않아 실패
  • liveness는 재시작 O, readiness 는 재시작 X

2.4. Startup Probe

probe – Kubernetes 에서 Pod 에 대한 헬스체크

Startup Probe

  • startup probe: 컨테이너 내 애플리케이션의 시작 여부 확인
  • 시작이 느린 컨테이너에 대해 liveness probe로 인해 조기에 종료되는 것을 방지
  • startup probe 설정 시, 성공하기 전까지는 liveness/readiness probe 비활성화
  • 컨테이너 시작 시에만 한 번 실행 <> liveness와 readiness의 주기적 실행
  • 설정되지 않으면 기본적으로 Success
  • 실패시 재시작

3. Manifest Management

Manifest

  • JSON 또는 YAML 포맷으로 작성된 k8s API 오브젝트 상세
  • Kubernetes 리소스를 정의하는 설정 파일 (YAML)
  • 선언형 파일

Manifest 관리 도구의 필요성

  1. 환경별 구성 분리
    • dev, stg, prd 등 각 환경에 따라 필요 설정값 다름
    • YAML 파일을 복사해 관리하면 누락, 오타 등의 실수
    • 공통 구성에 환경별 차이만 덮어씌우는 방식으로 안정적 관리가 가능
  2. 템플릿화 및 변수화
    • 리소스 정의의 구조적 일관성 유지
    • 설정 변경 시 전체 YAML 수정 없이 변수만 바꾸면 되어 유지보수가 용
    • 재사용성 상승, 팀 내 협업 시 충돌 감소
  3. 버전 관리 및 롤백
    • Helm이나 Kustomize는 변경 이력을 추적 가능
    • 문제가 발생했을 때 이전 상태로 쉽게 롤백
    • Git과 연동 시 YAML의 변경 내역도 함께 관리
  4. 자동화 및 GitOps 통합
    • Git을 중심으로 선언적 인프라 관리가 가능
    • CI/CD 파이프라인에 쉽게 통합
    • 배포 과정을 자동화함으로써 수작업 실수 감소 / 일관된 릴리스를 유지

대표적 Manifest 관리 도구

[쿠어클#13] Helm과 Kustomize 비교하며 사용하기 (2/2)
  • Kustomize
    • kubectl에 기본 내장된 도구
    • Kubernetes 구성에 대한 사용자 정의 제공 도구
  • 주요 기능
    • 오버레이 기능을 통한 환경별 설정 분리 기능
    • 공통 설정의 재사용 가능성


  • Helm
    • 가장 널리 사용되는 매니페스트 관리 도구
    • Kubernetes 사용 시 Helm 사용법에 대한 이해 필요성
    • Kubernetes 애플리케이션을 체계적으로 배포 및 관리하기 위한 패키지 매니저
  • 주요 기능
    • 템플릿 기반 매니페스트 생성 기능
    • 버전 관리, 업그레이드, 롤백 기능
    • 차트를 통한 설정 관리 및 재사용 가능성


  • 기타 도구
    • Kpt
    • Jsonnet

3.1. Kustomize

Kustomize

  • Kubernetes Customize (Kustomize) – customize raw, template-free YAML files for multiple purposes
  • 쿠버네티스 리소스(YAML) 를 레이어별로 구성
  • 쿠버네티스 리소스를 변경하지 않고 필드를 재정의하여 새로운 쿠버네티스 리소스를 생성하는 도구
    • Linux sed 명령어와 유사한 동작 방식
  • 쿠버네티스 리소스를 직접 수정하지 않고, 오버레이(Overlay) 개념을 통해 필드만 덮어써서 다양한 환경(dev, stg, prd 등)에 맞는 설정을 생성할 수 있음
  • Base는 공통 리소스를 정의하고, Overlay는 환경별 차이만 정의하여 조합

  • Base
    • Kustomize를 통해 변경 대상이 되는 YAML 파일들이 저장된 디렉토리
    • 재사용 가능한 공통 리소스로 구성되며, 환경에 관계없이 공통적으로 사용되는 정의를 포함
      • 예: deployment.yaml, service.yaml, ingress.yaml 등
    • 여러 환경에서 공유될 수 있는 기본 리소스 역할을 하며, 중복 정의를 방지할 수 있음
    • Terraform의 모듈, Helm의 차트와 유사한 개념

  • Overlay
    • 특정 환경(dev, stg, prd 등)의 설정 차이를 정의하는 디렉토리
    • 각 환경에 필요한 값만 덮어쓰는 방식으로 관리되며, Base 디렉토리를 참조함
    • 일반적으로 overlays/dev, overlays/stg, overlays/prd 식으로 디렉토리 구분
      • 예: dev 환경에서는 replicas를 1로, prod 환경에서는 3으로 설정
    • 오버레이 구조를 통해 동일한 앱을 다양한 설정으로 배포 가능

  • kustomization.yaml
    • Kustomize가 실행될 때 참조하는 구성 파일
    • 어떤 리소스를 포함할지, 어떤 필드를 덮어쓸지, 어떤 설정을 생성할지를 정의
    • 주요 항목에는 다음이 포함됨:
      • resources: 포함할 base 또는 다른 리소스 목록
      • namePrefix: 리소스 이름 앞에 붙일 접두사 설정
      • patches: 특정 필드의 덮어쓰기 또는 병합 정의 (JSON6902 또는 Strategic Merge)
      • configMapGenerator / secretGenerator: ConfigMap 및 Secret을 인라인 정의하여 생성
      • commonLabels / commonAnnotations: 모든 리소스에 공통으로 부여할 메타데이터 정의
    • 템플릿 문법 없이 YAML만으로 커스터마이징이 가능하며, 유지보수가 직관적임

  • Kustomization.yaml 필드
    • resources : kustomize 를 적용할 yaml 파일
    • generators : 새로운 필드 생성
    • transformers : 필드 변경
    • validators : 검증 – 실패 시 배포 금지
    • 그 외에도 configMapGenerator , namePrefix , patches 등의 Plug-in 이 존재
    • kustomize 실행 순서
      • resourcesgeneratorstransformersvalidators

Kustomize 기본 사용

  • kustomize 사용을 위한 파일 생성
# 실습 디렉토리 생성
mkdir kustomize && cd kustomize

# 기본 kustomize 파일 생성
cat << EOF >> kustomization.yaml
resources:
  - pod.yaml

images:
  - name: nginx
    newName: new-nginx
    newTag: 1.23.1
EOF

cat << EOF >> pod.yaml
apiVersion: v1
kind: Pod
metadata:
  labels:
    name: nginx
  name: nginx
spec:
  containers:
  - image: nginx:latest
    name: nginx
    resources:
      limits:
        cpu: 100m
        memory: 64Mi
EOF

  • kustomize 작동 확인
    • 기존 pod.yaml의 images: 필드가 변경됨
# kustomize 실행

# Tree 구조 확인
tree .

...
.
├── kustomization.yaml
└── pod.yaml
...

# kustomization.yaml 파일이 있는 PATH 실행
kubectl kustomize <PATH>

# 현재 Directory 에서 실행
kubectl kustomize .

...
apiVersion: v1
kind: Pod
metadata:
  labels:
    name: nginx
  name: nginx
spec:
  containers:
  - image: new-nginx:1.23.1
    name: nginx
    resources:
      limits:
        cpu: 100m
        memory: 64Mi
...

kubectl kustomize . > pod-kustomize.yaml
diff pod.yaml pod-kustomize.yaml

9c9
<   - image: nginx:latest
---
>   - image: new-nginx:1.23.1
  • kustomize 된 resource 생성
# kustomize 배포
kubectl kustomize . | kubectl apply -f -

# kustomize 파일로 추출 후 배포
kubectl kustomize . > pod-kustomize.yaml | kubectl apply -f pod-kustomize.yaml

# 배포 확인
kubectl describe pod nginx | grep -i containers: -A4

kustomization 필드 활용

  • Resource 필드
    • 특정 yaml 파일을 kustomization 설정에 따라 변경하고자 할 때 사용
    • 같은 경로라도 kustomization 에 지정되어 있지 않으면 적용 대상이 아님
mkdir kustomize-1 && cd kustomize-1

cat << EOT > service.yaml
apiVersion: v1
kind: Service
metadata:
  name: nginx
spec:
  selector:
    app: nginx
  ports:
  - port: 80
    targetPort: 80
EOT

cat << EOF > pod-1.yaml
apiVersion: v1
kind: Pod
metadata:
  labels:
    name: nginx-1
  name: nginx-1
spec:
  containers:
  - image: nginx:latest
    name: nginx-1
    resources:
      limits:
        cpu: 100m
        memory: 64Mi
EOF

cat << EOF > pod-2.yaml
apiVersion: v1
kind: Pod
metadata:
  labels:
    name: nginx-2
  name: nginx-2
spec:
  containers:
  - image: nginx:latest
    name: nginx-2
    resources:
      limits:
        cpu: 100m
        memory: 64Mi
EOF

cat << EOF > kustomization.yaml
resources:
  - pod-1.yaml
  - service.yaml
EOF
tree .

...
.
├── kustomize.yaml
├── pod-1.yaml
├── pod-2.yaml
└── service.yaml
...

kubectl kustomize .

  • Transformers 필드
    • 필드값을 변경하는 기능
    • 다양한 빌트인 존재

  • Namespace 변경 – Link
kubectl create ns test

cat << EOT > kustomization.yaml
namespace: test
resources:
  - pod-1.yaml
  - service.yaml
EOT

kubectl kustomize .
cat << EOT > kustomization.yaml
namespace: test
images:
  - name: nginx
    newTag: 1.23.1
resources:
  - pod-1.yaml
  - service.yaml
EOT

# kustomize 실행
kubectl kustomize .

Base / Overlays

  • 신규 디렉터리로 이동해 공통점인 base, 변경점인 overlay 생성
cd .. && mkdir kustomize-2 && cd kustomize-2

# 실습 디렉토리 구성
mkdir -p base overlays/dev overlays/prd

tree .
...
.
├── base
└── overlays
    ├── dev
    └── prd
...
# Base kustomization.yaml 생성
cat << EOT > ./base/kustomization.yaml
resources:
- pod.yaml
EOT

# Base pod.yaml 생성 (공통으로 사용할 YAML 파일)
cat << EOT > ./base/pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  labels:
    app: myapp
spec:
  containers:
  - name: nginx
    image: nginx:latest
EOT

cat << EOT > ./overlays/dev/kustomization.yaml
resources:
- ../../base
namePrefix: dev-
EOT

cat << EOT > ./overlays/prd/kustomization.yaml
resources:
- ../../base
namePrefix: prd-
EOT
# 현재 디렉토리 구조
.
├── base
│   ├── kustomization.yaml
│   └── pod.yaml
└── overlays
    ├── dev
    │   └── kustomization.yaml
    └── prd
        └── kustomization.yaml


# dev kustomize 실행
kubectl kustomize overlays/dev > dev-kustomized.yaml

# prd kustomize 실행
kubectl kustomize overlays/prd > prd-kustomized.yaml

❯ diff -U 5 dev-kustomized.yaml prd-kustomized.yaml

--- dev-kustomized.yaml 2025-05-18 01:02:44.781292254 +0900
+++ prd-kustomized.yaml 2025-05-18 01:02:44.991048698 +0900
@@ -1,10 +1,10 @@
 apiVersion: v1
 kind: Pod
 metadata:
   labels:
     app: myapp
-  name: dev-myapp-pod
+  name: prd-myapp-pod
 spec:
   containers:
   - image: nginx:latest
     name: nginx

결과확인

  • kustomization에 지정된 값에 따른 pod.yaml 업데이트
  • resources: 필드
    • kustomization.yaml에서 지정된 pod-1,service.yaml에만 변경 적용
  • Transform 필드:
    • kustomization.yaml에서 지정된 필드값만 변경 적용
  • base/overlay
    • 각 overlay의 환경에 따라 prefix 변경

3.2. Helm

What is Helm? A complete guide

Intro to Helm Charts for Complete Beginners
  • Chart
    • Helm 에서 사용 되는 패키지
    • 애플리케이션, 도구, 서비스를 구동하는 데 필요한 모든 리소스 정의가 포함
      • Kubernetes 리소스들(Deployment, Service 등)
    • yum, apt, brew 기능과 유사
  • Repository
    • 헬름 차트를 모아두고 공유하는 장소
    • 공유 저장소
      • Artifact Hub – Link
    • 설치형
  • Release
    • Helm Chart를 실제 Kubernetes 클러스터에 배포한 인스턴스
    • 하나의 Chart로 여러 개의 Release를 만들 수 있음 (예: myapp-dev, myapp-prod)
  • Values
    • values.yaml 또는 커맨드라인에서 전달하는 사용자 정의 값
    • 템플릿 파일 내의 변수들을 바인딩하여 동적인 리소스 생성 가능

Helm 기본 사용

  • 기본 mychart 생성 후 앱 배포 및 확인
# Helm 디렉토리 이동
mkdir helm-practice

# Helm Repo 확인
helm repo ls

# Helm 생성
helm create mychart

# Helm 구조 확인
cd mychart
tree .

...
.
├── Chart.yaml
├── charts
├── templates
│   ├── NOTES.txt
│   ├── _helpers.tpl
│   ├── deployment.yaml
│   ├── hpa.yaml
│   ├── ingress.yaml
│   ├── service.yaml
│   ├── serviceaccount.yaml
│   └── tests
│       └── test-connection.yaml
└── values.yaml
...


# Helm 배포
# helm install <RELEASE_NAME> <패키지 경로> [flags]
helm install myapp .

# Helm Release 확인
helm list

# Helm 으로 배포된 리소스 확인
kubectl get po,deploy,svc,sa

# Helm 삭제
helm delete myapp

Values.yaml 활용

  • 변경점을 기록한 values.yaml 을 사용해 image tag 업데이트하여 배포

# Community Repository 추가
helm repo add bitnami https://charts.bitnami.com/bitnami

# Helm Repo 조회
helm repo ls
...
NAME   	URL
bitnami	https://charts.bitnami.com/bitnami
...

# Bitnami 의 Helm Chart 조회
helm search repo bitnami

# Helm Nginx 설치
# 최신 차트 정보를 가져오도록 하는 명령어
helm repo update

# Helm
# helm install <RELEASE_NAME> <CHART 경로> [flags]
helm install mynginx bitnami/nginx

kubectl describe deploy mynginx
kubectl describe deployments.apps mynginx | grep 'Containers:' -A5
cat <<EOF > values.yaml
image:
  tag: 1.24
EOF

# 기존 Helm 설정을 values.yaml 파일에 기반하여 변경
helm upgrade mynginx bitnami/nginx -f values.yaml

kubectl describe deploy mynginx
kubectl describe deployments.apps mynginx | grep 'Containers:' -A5

# Helm Realese 조회
helm ls
...
Version 이 올라감
...

결과 확인

  • 기존 nginx chart default version
  • values.yaml 지정된 1.24로 업데이트

4. GitOps

4.1. GitOps 개념

카카오클라우드에서 GitOps로 DevOps 효율성 극대화하기

GitOps 개요

  • 2017년 Weaveworks 직원들이 처음 사용
  • 선언형 인프라를 Git에 정의하여 자동 배포 및 운영
  • Git을 중심으로 시스템 변경 사항을 관리하고 동기화

주요 특징

  • Git은 단일 진실 원천(SSOT) 역할
  • 선언형 YAML 파일로 원하는 상태 정의
  • Git 상태와 클러스터 상태 자동 동기화
  • Git 이력 기반 롤백 및 변경 추적 가능
  • 애플리케이션 코드와 배포 코드 분리

도입 시 고려사항

  • 관찰 가능성과 고가용성 확보
  • CI/CD 파이프라인 설계
  • 조직/팀 단위 설정 및 권한 관리
  • Namespace 기반 RBAC 구성

4.2. ArgoCD

예제로 배우는 ArgoCD

ArgoCD 개요

  • Git을 배포 원천으로 사용하는 GitOps CD 도구
  • 선언형 매니페스트 기반으로 쿠버네티스 리소스를 자동 동기화

주요 기능

  • GUI와 CLI를 통해 애플리케이션 상태 및 변경 이력 확인
  • Git 저장소 변경 시 자동 또는 수동으로 클러스터 상태 업데이트
  • Kustomize, Helm, Jsonnet 등 다양한 템플릿 도구 지원

확장성

  • Argo Rollouts를 통해 Canary, Blue-Green 등의 배포 전략 구현
  • Argo CD Notifications로 배포 성공, 실패, 동기화 이벤트 알림 설정 가능

운영 및 보안

  • 팀 단위 RBAC 설정을 통한 접근 제어
  • Git 기반 승인 및 변경 이력 관리로 감사 추적 가능

ArgoCD 구성 방식

  • 핵심 구성 요소는 쿠버네티스 컨트롤러로 이루어짐
  • 컨트롤러는 클러스터 상태를 지속적으로 감시하고 Git에 정의된 의도한 상태와 비교

컨트롤러 작동 원리

  • 현재 클러스터 상태를 주기적으로 확인
  • 의도한 상태와 다를 경우 필요한 리소스 변경을 자동으로 적용

ArgoCD의 역할

  • Git에 정의된 선언형 설정을 기준으로 클러스터를 자동 관리
  • GitOps 모델의 중심 역할로, 배포 자동화와 일관성 확보에 기여



ArgoCD WEB UI를 사용해 github repo와 연동하여 배포하기

1. Argo CD UI 접속 및 앱 생성

  • 브라우저에서 Argo CD UI 접속 후 로그인
  • New App 버튼 클릭
  • 적절한 앱, 프로젝트 이름 및 동기화 정책 지정

2. 저장소 및 경로 설정

  • 연결할 git repo 경로 및 revision(branch) 설정
  • 레포내 배포할 manifests의 경로 지정

3. 배포 대상 클러스터 및 네임스페이스 설정

  • 클러스터 내의 argocd가 api-server 연결되도록 clusterURL 설정
  • 배포할 namespace 설정

4. 앱 생성 완료

  • 해당 설정을 마치고 create로 argocd app 생성

5. 앱 배포(Sync)

  • sync를 통해 git의 manifest와 k8s 클러스터 내부 동기화

ArgoCD 설치

  • helm을 사용하여 설치
# ArgoCD Namespace 생성
kubectl create ns argocd

# Terminal 2번
watch kubectl get pod,pvc,svc -n argocd

# Helm Repo 등록
helm repo add argo https://argoproj.github.io/argo-helm
helm repo update

helm install argocd argo/argo-cd --set server.service.type=NodePort --namespace argocd

# ArgoCD 서비스 접근을 위한 노드포트 변경
kubectl patch svc argocd-server -n argocd \
  -p '{"spec": {"ports": [{"port": 443, "targetPort": 8080, "nodePort": 31001}]}}'
  
# 리소스 확인
kubectl get all -n argocd
  • ArgoCD WEB UI 접속
# 초기 비밀번호 확인
kubectl -n argocd get secrets argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d

...
pRhrwU2NzfgpEOE3
...

# ArgoCD UI 접근
open http://localhost:31001
  • WSL2 환경에서 port-forwarding 통한 접근
kubectl port-forward -n argocd service/argocd-server 31001:80 > /dev/null 2>&1 &

# ID admin
# PW pRhrwU2NzfgpEOE3

ArgoCD 를 통한 Application 배포

결과 확인

  • WebUI에서 조회가능한 resource
  • kubectl cli로 조회한 k8s 클러스터내부 리소스 > 동일

Leave a Reply