Kubernetes는 복잡한 인프라를 훌륭하게 관리하지만, 사람이 직접 애플리케이션을 배포/업그레이드/삭제하려고 하면 “오브젝트 단위 관리”가 곧 부담이 됩니다. 예를 들어 WordPress 같은 비교적 흔한 웹앱도 실제로는 Deployment(웹/DB), Service, Secret, PV/PVC, (옵션으로 Ingress, CronJob/Job 백업 등)처럼 여러 오브젝트가 함께 맞물려야 정상 동작합니다. YAML 파일도 여러 장이 되고, 커스터마이징/업그레이드/삭제까지 생각하면 관리 비용이 급격히 올라갑니다.

Helm은 이 부담을 줄이기 위해 등장한 Kubernetes 패키지 매니저(그리고 릴리즈 매니저) 입니다. Helm을 쓰면 앱을 “오브젝트 여러 개”가 아니라 패키지(Chart) → 설치본(Release) 단위로 다루게 되고, 설치/업그레이드/롤백/삭제를 “릴리즈” 하나로 일괄 처리할 수 있습니다.

1. WordPress 예시가 자주 나오는 이유

여기서 말하는 WordPress는 “꼭 쓰라는 제품”이 아니라 Helm이 해결하는 문제를 보여주기 좋은 대표 샘플입니다.

  • WordPress = 오픈소스 CMS(콘텐츠 관리 시스템)
    블로그/웹사이트를 만들고 운영하는 웹 애플리케이션.
  • Kubernetes에서 WordPress를 띄우려면 보통:
    • WordPress 웹(Deployment)
    • DB(MySQL/MariaDB 등) (Deployment/StatefulSet)
    • 스토리지(PV/PVC)
    • 노출(Service/Ingress)
    • 비밀값(Secret)
      같은 오브젝트가 함께 필요합니다.

즉 “하나의 앱”인데 “YAML 수십 장”이 될 수 있는 케이스라 Helm의 가치가 잘 드러납니다.

2. Helm 2 vs Helm 3: 왜 Helm 3가 표준인가

Helm 3는 Helm 2 대비 구조적으로 큰 변화가 있었습니다.

2.1 Tiller 제거(가장 큰 변화)

  • Helm 2: Helm Client → Tiller(클러스터 내부) → Kubernetes API
    Tiller가 중간자 역할을 하며 작업 수행
    • 단점: 구성 복잡도 증가
    • 보안 이슈: Tiller가 강한 권한(“God mode”)으로 운용되기 쉬움
  • Helm 3: Helm Client → Kubernetes API (직접)
    • RBAC로 사용자/서비스 계정 권한을 Kubernetes 방식대로 정교하게 제한 가능
    • kubectl이든 helm이든 “요청 주체”의 RBAC 권한이 그대로 적용

2.2 3-way Strategic Merge Patch(업그레이드/롤백이 더 똑똑해짐)

Helm 3는 변경 적용 시 이전 상태 + 목표 상태 + 현재 live 상태를 함께 고려해 패치를 구성하는 성향이 강합니다.
예를 들어, Helm 설치 후 누군가 kubectl set image로 수동 변경을 했다면:

  • Helm 2는 “차트/리비전 비교” 중심이라 수동 변경을 놓쳐 롤백이 기대와 다를 수 있음(강의 흐름)
  • Helm 3는 live 상태까지 봐서 “원래 리비전 상태로 되돌리기”에 더 유리

운영 원칙은 “Helm으로 설치한 건 Helm으로 변경”이지만, 현실에서 드리프트가 생길 수 있어 Helm 3의 이 차이가 의미가 큽니다.

3. Helm 구성요소: Chart, Release, Revision, Repository, Metadata

Helm을 이해하는 핵심 단어는 5개입니다.

3.1 Chart

  • 앱을 배포하기 위한 파일 묶음(템플릿 + 기본값 + 메타데이터)
  • Kubernetes 오브젝트를 어떤 규칙으로 만들지 정의

3.2 Release

  • Chart를 클러스터에 적용하면 생기는 설치본(인스턴스)
  • 같은 차트라도 릴리즈 이름만 다르면 여러 개 설치 가능
    (예: my-site, my-second-site)

3.3 Revision

  • Release의 스냅샷(변경 이력)
  • install → revision 1
  • upgrade → revision 2
  • rollback → “revision이 과거로 돌아가는 게 아니라” 새 revision이 추가(예: revision 3)

3.4 Repository / Artifact Hub

  • 차트를 제공하는 저장소가 Helm repository
  • 전 세계 차트를 검색하는 허브가 Artifact Hub(artifacthub.io)

3.5 Metadata(Helm이 남기는 기록)

Helm은 “자기가 무엇을 설치했고 어떤 리비전인지”를 알아야 upgrade/rollback/uninstall이 가능합니다.
그래서 Helm 3는 이 메타데이터를 클러스터 내부(보통 Secret) 에 저장합니다.

주의: Secret은 기본적으로 base64 인코딩일 뿐 “암호화”가 아닙니다. 민감 환경에서는 etcd encryption at rest 등을 함께 고려합니다.

4. Helm Chart 구조와 템플레이팅

Chart는 “정해진 폴더/파일 구조”를 가집니다.

<chart-root>/
  templates/     # Kubernetes 리소스 템플릿
  values.yaml    # 설정(입력값) 기본값
  Chart.yaml     # 차트 메타데이터
  README.md      # 문서(선택)
  LICENSE        # 라이선스(선택)
  charts/        # 의존 차트(서브차트, 선택)

4.1 templates + values.yaml = 최종 매니페스트 생성

템플릿에는 값이 하드코딩되지 않고 .Values로 주입됩니다.

# templates/deployment.yaml (개념 예시)
spec:
  replicas: {{ .Values.replicaCount }}
  template:
    spec:
      containers:
      - image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
# values.yaml (개념 예시)
replicaCount: 2
image:
  repository: nginx
  tag: "1.27"

렌더링 결과를 설치 전에 확인하려면:

helm template my-test ./my-chart -f values.yaml

5. Chart.yaml: 차트의 “신분증” 완전 정리

Chart.yaml은 차트의 메타데이터입니다. Helm 3에서 특히 중요한 이유는 apiVersion(v1/v2) 로 차트 스펙을 구분하기 때문입니다.

예시:

apiVersion: v2
name: wordpress
description: A Helm chart for WordPress
type: application

version: 24.1.3
appVersion: "6.4.3"

keywords:
  - wordpress
  - cms
  - blog

home: https://wordpress.org
icon: https://example.com/wordpress-icon.png

maintainers:
  - name: Example Maintainer
    email: maintainer@example.com

dependencies:
  - name: mariadb
    version: 12.3.1
    repository: https://charts.bitnami.com/bitnami
    condition: mariadb.enabled

핵심 필드:

  • apiVersion
    • Helm 3용 차트 스펙: v2
    • Helm 2 시대 차트: v1 또는 미기재(구형)
  • appVersion
    • 차트가 배포하는 “앱 버전”(정보 목적)
  • version
    • 차트 자체 버전(필수). appVersion과 독립
  • type
    • application: 앱 배포용(대부분)
    • library: 다른 차트에서 재사용할 유틸 템플릿 제공
  • dependencies
    • WordPress ↔ MariaDB처럼 2-tier 앱에서 DB 차트를 서브차트로 포함 가능

6. bitnami는 뭐고, bitnami/apache는 무슨 뜻인가

  • Bitnami는 오픈소스 소프트웨어를 컨테이너 이미지/Helm 차트로 잘 패키징해서 제공하는 대표 공급자입니다.
  • Helm에서 bitnami/apache는:
    • bitnami = repo 별칭
    • apache = 차트 이름

repo 등록:

helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update

7. Helm CLI 기본 흐름: help → search → repo add → install → list → uninstall → repo update

7.1 도움말(인터넷보다 빠른 경우가 많음)

helm help
helm repo --help
helm rollback --help

7.2 차트 검색

  • Artifact Hub 검색(개념): helm search hub wordpress
  • 로컬 repo에서 검색: helm search repo wordpress
helm search hub wordpress
helm search repo wordpress

7.3 설치(Release 생성)

helm install my-release bitnami/wordpress

설치 예시 출력(대표 형태):

NAME: my-release
NAMESPACE: default
STATUS: deployed
REVISION: 1
NOTES:
...

7.4 릴리즈 확인/삭제

helm list
helm uninstall my-release

7.5 repo 업데이트(로컬 인덱스 갱신)

helm repo update

8. 설치 시 커스터마이징: --set vs -f values.yaml vs helm pull --untar

WordPress 기본 블로그 이름이 User's Blog로 뜨는 것처럼, 대부분 차트는 기본값이 있고 설치 시 오버라이드할 수 있습니다.

8.1 --set (소수 값 변경에 편리)

helm install my-wp bitnami/wordpress \
  --set wordpressBlogName="Helm Tutorials" \
  --set wordpressEmail="john@example.com"

8.2 -f customvalues.yaml (값이 많을 때 권장)

# customvalues.yaml
wordpressBlogName: "Helm Tutorials"
wordpressEmail: "john@example.com"
helm install my-wp bitnami/wordpress -f customvalues.yaml

8.3 차트를 로컬로 내려받아 수정 후 설치

helm pull bitnami/wordpress --untar
# wordpress/values.yaml 수정
helm install my-wp ./wordpress

실무에서는 가능하면 로컬 수정 대신 -f values.yaml 방식으로 관리하는 편이 업데이트 추적에 유리합니다.

9. helm install amaze-surf bitnami/apache를 “최대한 상세히” 해부

helm install amaze-surf bitnami/apache
  • install: 설치(릴리즈 생성)
  • amaze-surf: 릴리즈 이름(설치본 식별자)
  • bitnami/apache: bitnami repo의 apache 차트

Helm이 내부적으로 하는 일(요약 순서):

  1. repo 인덱스에서 차트 위치/버전 확인(필요 시 다운로드)
  2. values 병합(기본 values + 오버라이드)
  3. 템플릿 렌더링(최종 YAML 생성)
  4. Kubernetes API로 리소스 생성/수정
  5. 릴리즈 메타데이터(Secret 등) 저장
  6. NOTES 안내 출력

설치 전 결과를 미리 보고 싶으면:

helm template amaze-surf bitnami/apache | head -n 80

자주 붙이는 옵션(운영 안정성):

helm install amaze-surf bitnami/apache \
  -n web --create-namespace \
  --wait --timeout 10m \
  --atomic

10. Lifecycle Management(핵심): 설치 → 업그레이드 → 이력 추적 → 롤백

릴리즈는 “짧게 띄웠다 내리는 실습 대상”이 아니라, 몇 달~몇 년 운영되는 대상입니다. Helm은 그 운영 주기를 릴리즈 단위로 관리합니다.

10.1 오래된 차트 버전으로 설치(리비전 1)

helm install nginx-release bitnami/nginx --version <old-chart-version>

예시 출력:

NAME: nginx-release
STATUS: deployed
REVISION: 1

10.2 현재 Nginx 이미지 버전 확인(kubectl)

kubectl get pods

예시:

nginx-release-nginx-6f6b8c6cc8-8wq2d   1/1   Running   0   1m
kubectl describe pod nginx-release-nginx-6f6b8c6cc8-8wq2d

예시(핵심):

Image: docker.io/bitnami/nginx:1.19.2-debian-10-r0

10.3 업그레이드(리비전 2)

helm upgrade nginx-release bitnami/nginx

예시 출력:

Release "nginx-release" has been upgraded.
REVISION: 2

업그레이드 후 Pod가 교체되고, 이미지도 최신으로 바뀌는지 확인:

kubectl get pods
kubectl describe pod <new-pod>

10.4 이력 확인: helm list, helm history

helm list

예시:

NAME          NAMESPACE REVISION STATUS   CHART        APP VERSION
nginx-release default   2        deployed nginx-13.2.1 1.21.4
helm history nginx-release

예시:

REVISION  STATUS    CHART        APP VERSION  DESCRIPTION
1         deployed  nginx-11.1.0  1.19.2       Install complete
2         deployed  nginx-13.2.1  1.21.4       Upgrade complete

10.5 롤백: 과거 상태로 “내용은 되돌리되”, 새 리비전 생성(예: 리비전 3)

helm rollback nginx-release 1
helm history nginx-release

예시:

3 deployed nginx-11.1.0 1.19.2 Rollback to 1

“revision 1로 돌아간다”는 말은 번호가 1로 돌아가는 게 아니라, 새 revision이 생성되어 그 내용이 revision 1과 같아지는 방식입니다.

11. 중요한 한계: Helm rollback은 “선언(매니페스트)”만 되돌린다

Helm의 rollback은 Kubernetes 오브젝트 선언을 되돌립니다.

  • Deployment/Service/Secret 등 “리소스 스펙”은 과거로 돌아갈 수 있음
  • 하지만 PV 데이터, 외부 DB 데이터까지 자동으로 복구하지는 않습니다.

예:

  • MySQL을 롤백하면 MySQL Pod 버전/설정은 이전으로 갈 수 있지만
  • 실제 DB 데이터는 PV/외부 스토리지에 남아 그대로일 수 있습니다.

그래서 데이터까지 포함한 일관된 복구가 필요하다면:

  • 업그레이드 전 DB 스냅샷/백업
  • 필요 시 복구 수행
    같은 별도 전략이 필요하며, 강의에서는 이를 자동화하는 방법으로 Chart Hooks를 예고합니다.

12. 운영 팁(짧고 중요한 것만)

  • 네임스페이스는 명시하는 습관이 안전합니다.
  • helm install my-app bitnami/apache -n web --create-namespace
  • 설치/업그레이드 전에는 결과를 미리 보는 루틴이 유용합니다.
  • helm show values bitnami/apache | less helm template my-app bitnami/apache | less
  • “Helm으로 설치한 리소스는 Helm으로 변경”이 가장 안정적입니다(드리프트 최소화).
  • 실패 대응이 중요한 환경이면:
    • --wait, --timeout, --atomic 조합을 고려합니다.

마무리: Helm을 쓰면 “Kubernetes 앱 운영 단위”가 바뀐다

Helm의 본질은 하나입니다.

Kubernetes 앱을 “오브젝트들의 집합”이 아니라, “릴리즈(Release)라는 앱 단위”로 취급하게 해준다.

그 결과:

  • 설치/업그레이드/롤백/삭제가 릴리즈 단위로 간단해지고
  • 변경 이력(Revision)이 남아 운영이 투명해지며
  • 팀 단위 협업이 쉬워집니다.

'CKA' 카테고리의 다른 글

Kustomize - Kustomize vs Helm  (0) 2026.01.08
Kustomize  (0) 2026.01.08
Helm - Lifecycle Management(Upgrade/Rollback)  (0) 2026.01.07
Helm - Customize Parameters  (0) 2026.01.07
Helm - CLI  (0) 2026.01.07

티스토리툴바