Certified Kubernetes Application Developer (CKAD) #9 Helm: install, upgrade, rollback, values
#8 Deployment 전략에서 blue-green과 canary로 무중단 배포의 패턴을 손으로 만들어 봤습니다. 그런데 실무에서 애플리케이션 하나를 배포하려면 Deployment 하나만으로 끝나지 않습니다. Deployment, Service, ConfigMap, Secret, Ingress가 한 묶음으로 따라다니고, 환경마다 값만 조금씩 다른 매니페스트를 반복해서 관리해야 합니다. 이 매니페스트 묶음을 하나의 패키지로 설치하고 버전을 매겨 올리고 되돌리는 도구가 Helm입니다.
CKAD에서 Helm의 출제 비중 자체는 크지 않습니다. 그러나 Application Deployment도메인에 포함되어 있어, 차트를 설치하고 values를 바꿔 다시 적용하고 문제가 생기면 롤백하는 기본 흐름은 시험 범위입니다. 이번 글은 깊은 차트 작성보다 helm 명령 운용에 초점을 두어, 손으로 따라 치며 익히겠습니다.
Helm이 푸는 문제 #
K8s 실무 트랙 #2에서 매니페스트를 kubectl apply -f로 적용하는 흐름을 다뤘습니다. 단순한 앱은 그것으로 충분하지만, 현실의 애플리케이션은 다음 같은 부담을 동반합니다.
- 한 앱이 Deployment, Service, ConfigMap, Secret, Ingress 등 여러 매니페스트로 구성된다
- dev, staging, prod 환경마다 replica 수, 이미지 태그, 도메인 같은 값만 다르다
- 새 버전을 배포했다가 문제가 생기면 이전 상태로 한 번에 되돌려야 한다
- 외부에서 만든 애플리케이션(예: PostgreSQL, Redis)을 검증된 설정으로 설치하고 싶다
Helm은 이 매니페스트 묶음을 chart라는 패키지로 만들고, 거기에 값을 주입해 클러스터에 설치한 결과를 release로 관리합니다. 패키지 매니저가 소프트웨어를 설치하고 업그레이드하고 제거하듯, Helm은 쿠버네티스 애플리케이션을 같은 방식으로 다룹니다.
핵심 개념: chart, release, repository #
세 단어만 정확히 구분하면 Helm 명령이 한눈에 들어옵니다.
| 개념 | 설명 |
|---|---|
| chart | 매니페스트 템플릿과 기본 값을 담은 패키지. 설치의 재료 |
| release | chart를 특정 값으로 클러스터에 설치한 결과. 이름과 버전(revision)을 가짐 |
| repository | chart를 모아 배포하는 저장소. helm repo add로 등록 |
| values | chart의 템플릿에 주입되는 설정 값. values.yaml 또는 --set으로 지정 |
같은 chart를 이름만 달리해 여러 번 설치하면 각각 별개의 release가 됩니다. release는 설치할 때마다 revision 번호가 1씩 올라가고, 이 번호가 rollback의 기준이 됩니다.
chart의 디렉터리 구조 #
chart는 정해진 디렉터리 구조를 가진 묶음입니다. 직접 작성할 일은 적지만 구조를 알아야 values가 어디서 오는지 이해됩니다.
mychart/
Chart.yaml # 차트 메타데이터 (name, version, appVersion)
values.yaml # 기본 값. --set 나 -f로 덮어쓰기 전의 출발점
templates/ # Go 템플릿으로 작성된 매니페스트
deployment.yaml
service.yaml
_helpers.tpl # 템플릿 헬퍼 (이름 규칙 등)
charts/ # 의존 차트(subchart) 보관templates/ 안의 매니페스트는 {{ .Values.replicaCount }}처럼 값을 참조하고, 그 값은 values.yaml의 기본값에서 시작해 --set이나 -f로 덮입니다. 이 흐름이 Helm의 전부라고 봐도 됩니다.
helm create로 표준 골격을 한 번에 만들 수 있습니다.
helm create mychartrepository 등록과 검색 #
외부 chart를 쓰려면 먼저 저장소를 등록하고 인덱스를 갱신합니다.
# 저장소 등록
helm repo add bitnami https://charts.bitnami.com/bitnami
# 등록한 저장소의 인덱스 갱신 (항상 install 전에)
helm repo update
# 등록된 저장소 목록
helm repo list
# 저장소에서 chart 검색
helm search repo nginx
helm search repo bitnami/postgresqlhelm repo update를 빼먹으면 오래된 인덱스를 보고 설치하게 되니, install 전에 한 번 갱신하는 습관이 안전합니다. chart의 어떤 값을 바꿀 수 있는지 확인하려면 helm show values가 유용합니다.
# chart의 기본 values.yaml을 그대로 출력
helm show values bitnami/nginxinstall: chart를 release로 설치 #
설치는 helm install <release 이름> <chart> 형식입니다. release 이름을 직접 정하는 점이 핵심입니다.
# bitnami/nginx를 myweb이라는 release로 설치
helm install myweb bitnami/nginx
# 네임스페이스를 지정해 설치 (없으면 생성)
helm install myweb bitnami/nginx --namespace web --create-namespace
# 설치된 release 목록
helm list
# 모든 네임스페이스의 release
helm list -A
# 특정 release의 상태
helm status mywebhelm list에 release 이름, revision, 상태(deployed), chart 버전이 나타납니다. release가 정상이면 kubectl get all -n web으로 chart가 만들어 낸 Pod와 Service를 확인할 수 있습니다.
release 이름을 자동으로 #
이름을 정하기 귀찮을 때는 --generate-name으로 Helm이 이름을 만들게 할 수 있습니다. 다만 시험에서는 보통 release 이름을 지정하라고 하므로 직접 정하는 형식에 익숙해지는 편이 낫습니다.
helm install bitnami/nginx --generate-namevalues 오버라이드: 같은 chart, 다른 설정 #
chart의 진짜 가치는 값만 바꿔 환경별로 다르게 설치하는 데 있습니다. 값을 덮어쓰는 방법은 두 가지입니다.
--set으로 인라인 지정
#
간단한 값 한두 개를 바꿀 때 씁니다.
# 단일 값
helm install myweb bitnami/nginx --set replicaCount=3
# 점 표기로 중첩 값, 콤마로 여러 개
helm install myweb bitnami/nginx \
--set replicaCount=3 \
--set image.tag=1.27
# 배열 인덱스 표기
helm install myweb bitnami/nginx --set ingress.hosts[0].host=example.com-f로 values 파일 지정
#
바꿀 값이 많거나 환경별로 파일을 나눠 두고 싶을 때는 별도 YAML 파일을 넘깁니다.
# myvalues.yaml
replicaCount: 3
image:
tag: "1.27"
service:
type: ClusterIPhelm install myweb bitnami/nginx -f myvalues.yaml
# 여러 파일을 겹쳐 적용 (뒤가 우선)
helm install myweb bitnami/nginx -f base.yaml -f prod.yaml값의 우선순위 #
같은 키가 여러 곳에서 지정되면 정해진 순서로 덮입니다. 뒤로 갈수록 우선순위가 높습니다.
- chart의
values.yaml(가장 낮음, 기본값) -f로 넘긴 파일 (여러 개면 나중 파일이 우선)--set으로 지정한 값 (가장 높음)
즉 --set은 어떤 파일 값보다도 강하게 덮습니다. 한 키를 -f 파일과 --set 양쪽에서 지정하면 --set 값이 적용됩니다. 적용된 최종 값이 헷갈리면 helm get values로 확인합니다.
# release에 실제로 적용된 사용자 지정 값
helm get values myweb
# 기본값까지 포함한 전체 값
helm get values myweb -aupgrade와 rollback #
설치 후 값이나 chart 버전을 바꾸려면 helm upgrade를 씁니다. upgrade 할 때마다 revision이 올라가고, 그 이력으로 언제든 되돌릴 수 있습니다.
# 값을 바꿔 업그레이드 (revision이 2로 증가)
helm upgrade myweb bitnami/nginx --set replicaCount=5
# release가 없으면 설치, 있으면 업그레이드
helm upgrade --install myweb bitnami/nginx -f prod.yaml
# release의 revision이력
helm history mywebhelm upgrade --install은 release 존재 여부를 신경 쓰지 않고 한 명령으로 처리하므로 CI 파이프라인에서 자주 쓰입니다.
rollback: 이전 revision으로 되돌리기 #
업그레이드가 잘못되면 helm history로 revision 번호를 확인하고 helm rollback으로 되돌립니다.
# 이력 확인
helm history myweb
# REVISION STATUS CHART ...
# 1 superseded nginx-15.0.0
# 2 deployed nginx-15.0.0
# revision 1로 되돌리기 (새 revision 3이 생성됨)
helm rollback myweb 1
# 번호를 생략하면 바로 이전 revision으로
helm rollback mywebrollback은 과거 상태를 그대로 복원하면서 새 revision을 만듭니다. 따라서 revision 1로 롤백하면 내용은 1과 같지만 history에는 revision 3으로 기록됩니다. 이 점을 기억해야 다음 작업에서 번호를 헷갈리지 않습니다.
적용 전 미리보기: template과 dry-run #
#1에서 kubectl --dry-run을 강조했듯, Helm도 적용 전에 결과를 확인하는 수단이 있습니다. 시험에서 잘못 설치하기 전에 한 번 들여다보는 습관이 시간을 아낍니다.
# 클러스터에 적용하지 않고 렌더링된 매니페스트만 출력
helm template myweb bitnami/nginx -f myvalues.yaml
# 실제 설치 흐름을 그대로 따르되 적용은 하지 않음 (서버 검증 포함)
helm install myweb bitnami/nginx --dry-run --debug -f myvalues.yamlhelm template은 순수하게 로컬에서 템플릿만 렌더링하므로 빠르고, --dry-run --debug는 API 서버에 보내 검증까지 거치므로 실제 설치에 더 가깝습니다. 값이 의도대로 들어갔는지 확인할 때는 렌더링 결과의 replicas:나 image: 줄을 직접 봅니다.
uninstall: release 제거 #
release를 지우면 그 release가 만든 모든 리소스가 함께 제거됩니다.
# release 제거
helm uninstall myweb
# 네임스페이스를 지정해 제거
helm uninstall myweb --namespace web
# 이력은 남기고 제거 (rollback 용)
helm uninstall myweb --keep-history기본 동작은 history까지 함께 지웁니다. 나중에 되돌릴 가능성이 있으면 --keep-history를 붙입니다.
시험 포인트 #
- 개념 3종. chart(재료) , release(설치 결과, revision 보유) , repository(저장소)를 정확히 구분한다
- install 형식.
helm install <release> <repo/chart>. release 이름을 직접 정하는 위치를 기억한다 - values 우선순위.
values.yaml<-f파일 <--set.--set이 가장 강하다 - upgrade와 rollback.
helm upgrade로 revision 증가,helm history로 번호 확인,helm rollback <release> <revision>으로 복원. rollback도 새 revision을 만든다 - 미리보기.
helm template은 로컬 렌더링,helm install --dry-run --debug는 서버 검증 포함 - 확인 명령.
helm list,helm status,helm get values로 설치 상태와 적용된 값을 점검한다 - repo 갱신. install 전에
helm repo update를 거르지 않는다
정리 #
이번 글에서 잡은 것:
- Helm은 매니페스트 묶음을 패키지로 다루는 도구. chart를 values와 함께 설치한 결과가 release이다
- repo 흐름.
helm repo add→helm repo update→helm search repo로 chart를 찾는다 - install과 values.
helm install <release> <chart>에--set또는-f로 값을 덮는다.--set이 최우선 - upgrade와 rollback.
helm upgrade로 revision을 올리고,helm history와helm rollback으로 되돌린다 - 미리보기와 제거.
helm template,--dry-run --debug로 결과를 확인하고helm uninstall로 정리한다
CKAD에서 Helm의 비중은 작지만, install,upgrade,values,rollback의 기본 명령은 손에 익혀 두어야 막히지 않습니다.
다음: Kustomize #
Helm이 템플릿과 값 주입으로 매니페스트를 패키지화했다면, 같은 문제를 템플릿 없이 patch로 푸는 도구가 Kustomize입니다.
#10 Kustomize: overlay 패턴, 환경별 매니페스트에서는 base와 overlay로 환경별 매니페스트를 구성하는 법, kustomization.yaml의 구조, kubectl apply -k로 적용하는 흐름, 그리고 Helm과 Kustomize를 언제 골라 쓰는지까지 직접 만들어 보며 정리하겠습니다.