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 개요

Pod LifeCycle: Kubernetes에서 파드의 상태를 정의하고 추적하기 위한 일련의 단계
Pending
→Running
→Succeeded
또는Failed
- 특정 경우
Unknown
상태가 될 수도 있음
Phase | 설명 |
---|---|
Pending | – 파드 라이프사이클의 첫 번째 단계 – 파드가 스케줄러에 의해 노드에 할당 – 아직 하나도 컨테이너가 생성 / 준비되지 않은 상태 – 일반적으로 – 노드 리소스 부족 혹은 노드 장애로 인해 사용 불가한 경우 – 컨테이너를 만들기 위한 CPU/메모리 등의 자원이 부족한 경우 – 컨테이너 이미지를 가져오는 중이거나 실패한 경우 |
Running | – 파드가 노드에 성공적으로 스케줄링 – 하나 이상의 컨테이너가 생성되어 실행 중 – 일반적으로 – 컨테이너가 정상적으로 시작되었고, 애플리케이션이 실행 중 – CrashLoopBackOff 또는 재시작 정책에 따라 컨테이너가 반복 실행 |
Succeeded | – 파드 내부의 모든 컨테이너가 정상적으로 종료, 재시작이 필요 없음 – 일반적으로 – Job 등의 일회성 작업 |
Failed | – 파드 내부의 모든 컨테이너가 종료 – 하나 이상이 실패하여 비정상적으로 종료된 경우. – 일반적으로 – exit code가 0이 아닌 경우 – OOMKilled 등 (exit code 137) |
Unknown | – kubelet이 파드 상태를 알 수 없음 – 일반적으로 – 노드 다운 – kubelet 또는 apiserver와의 네트워크 통신에 문제 |
- 파드 실행 중 컨테이너에 문제가 발생하면
- kubelte이 재시작 정책에 따라 컨테이너를 재시작
Running
상태에서도 재시작이 반복될 수 있음
- Kubernetes는 파드 내부 각 컨테이너의 상태를 개별적으로 추적하며, 파드를 정상 상태로 유지하거나 재생성할지 여부를 스케줄러와 컨트롤러가 판단
- 컨테이너에서 kubelet에 의해 주기적으로 수행되는 진단
- 일종의 Pod HealthCheck
- 진단을 수행하기 위해 kubelet은 컨테이너 안에서 코드를 실행하거나 네트워크 요청을 전송
방식 | 설명 |
---|---|
exec | 컨테이너 내에서 지정된 명령어를 실행 명령어 상태 코드가 0으로 종료되면 진단이 성공한 것으로 간주 |
grpc | gRPC 클라이언트로 컨테이너의 gRPC 서버에 호출을 전송 서비스의 상태가 SERVING 상태일 경우 진단 성공으로 간주 활성화 위해 GRPCContainerProbe feature gate가 필요 |
httpGet | 지정된 포트 및 경로에서 컨테이너의 IP주소에 HTTP GET 요청 수행 응답 상태 코드가 200 이상 400 미만이면 성공으로 간주 SpringBoot의 Actuator와 함께 자주 사용 |
tcpSocket | 지정된 포트에서 컨테이너의 IP주소에 대해 TCP 연결 시도 포트가 열려 있고 연결되면 성공으로 간주 연결만 되고 데이터 전송이 없어도 성공으로 간주 |
종류 | 설명 |
---|---|
livenessProbe | 컨테이너가 정상적으로 동작 중인지 여부 확인 프로브 실패 시 kubelet은 컨테이너를 죽이고 재시작 정책에 따라 처리 |
readinessProbe | 컨테이너가 요청을 처리할 준비가 되었는지 여부 확인 프로브 실패 시, 해당 컨테이너가 속한 파드의 엔드포인트에서 제외되어 서비스 트래픽을 받지 않음 |
startupProbe | 애플리케이션이 시작되었는지 여부 확인 성공할 때까지는 다른 프로브가 작동하지 않으며, 지정된 시간 동안 기다려줌 지정된 시간 내에 실패 시 컨테이너를 종료하고 재시작 정책에 따라 처리 |
2.2. 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

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

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

- Kustomize
kubectl
에 기본 내장된 도구- Kubernetes 구성에 대한 사용자 정의 제공 도구
- 주요 기능
- 오버레이 기능을 통한 환경별 설정 분리 기능
- 공통 설정의 재사용 가능성
- Helm
- 가장 널리 사용되는 매니페스트 관리 도구
- Kubernetes 사용 시 Helm 사용법에 대한 이해 필요성
- Kubernetes 애플리케이션을 체계적으로 배포 및 관리하기 위한 패키지 매니저
- 주요 기능
- 템플릿 기반 매니페스트 생성 기능
- 버전 관리, 업그레이드, 롤백 기능
- 차트를 통한 설정 관리 및 재사용 가능성
- 기타 도구
- Kpt
- Jsonnet
3.1. Kustomize
K
ubernetesCustomize
(Kustomize
) – customize raw, template-free YAML files for multiple purposes- 쿠버네티스 리소스(YAML) 를 레이어별로 구성
- 쿠버네티스 리소스를 변경하지 않고 필드를 재정의하여 새로운 쿠버네티스 리소스를 생성하는 도구
- Linux
sed
명령어와 유사한 동작 방식
- Linux
- 쿠버네티스 리소스를 직접 수정하지 않고, 오버레이(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 실행 순서
resources
→generators
→transformers
→validators
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 .
- Image Tag 변경 – 링크
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


Chart
- Helm 에서 사용 되는 패키지
- 애플리케이션, 도구, 서비스를 구동하는 데 필요한 모든 리소스 정의가 포함
- Kubernetes 리소스들(Deployment, Service 등)
- yum, apt, brew 기능과 유사
Repository
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 개요
- 2017년 Weaveworks 직원들이 처음 사용
- 선언형 인프라를 Git에 정의하여 자동 배포 및 운영
- Git을 중심으로 시스템 변경 사항을 관리하고 동기화
주요 특징
- Git은 단일 진실 원천(SSOT) 역할
- 선언형 YAML 파일로 원하는 상태 정의
- Git 상태와 클러스터 상태 자동 동기화
- Git 이력 기반 롤백 및 변경 추적 가능
- 애플리케이션 코드와 배포 코드 분리
도입 시 고려사항
- 관찰 가능성과 고가용성 확보
- CI/CD 파이프라인 설계
- 조직/팀 단위 설정 및 권한 관리
- Namespace 기반 RBAC 구성
4.2. 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 클러스터내부 리소스 > 동일
