[CKA] Helm 정리01 – Chart, Release, Revision 개념과 install / upgrade / rollback

1. Helm이 왜 필요한가?

[+] Kubernetes에서 하나의 애플리케이션을 배포하려면 보통 다음과 같은 리소스들이 필요하다.

• Deployment
• Service
• ConfigMap
• Secret
• PVC / PV
• Ingress

[+] 아래와 같은 문제점이 발생.

• YAML 파일 수가 많아진다.
• 환경(dev / stage / prod)마다 값이 달라진다.
• 업그레이드와 롤백이 번거롭다.

Helm은 이 여러 YAML 리소스를 “하나의 애플리케이션 단위”로 묶어 관리하기 위한 도구

 

 

 

2. Helm 기본 개념 정리

[+] Helm 한 줄 정의

Helm은 Kubernetes용 패키지 매니저다.

 

[+] 핵심 용어

용어	의미
Chart	애플리케이션 패키지
Release	Chart가 클러스터에 설치된 결과
Revision	Release의 변경 이력
Repository	Chart 저장소
values.yaml	설정값 파일

---

3. Helm 2 vs Helm 3 차이점

Helm 3는 Tiller를 제거하고 Kubernetes API를 직접 호출
현재 실무 및 시험 기준은 Helm 3만 사용

구분	Helm 2	Helm 3
Tiller	필요	❌ 제거
권한 모델	Tiller 권한	kubectl과 동일
Release 범위	클러스터	네임스페이스
보안	취약	개선

---

4. Helm Chart 구조 이해

 

[+] 각 파일/디렉터리 의미

- templates/

• Deployment, Service, Secret 등의 YAML 템플릿
• Go Template 문법 사용
• values.yaml 값이 주입됨

- values.yaml

• 사용자가 수정하는 설정 파일
• replica 수, 이미지 태그, 서비스 타입 등

- Chart.yaml

• 차트 자체의 정보
• 차트 이름, 버전, 의존성 정의

- charts/

• MariaDB 같은 의존성 차트 저장 위치

---

5. Chart.yaml 파일의 핵심 포인트

[+]중요한 판단 포인트

• apiVersion: v2
  → Helm 3 전용 차트
• version
  → Chart 버전 (템플릿/구조 변경 이력)
• appVersion
  → 애플리케이션 버전 (WordPress 버전)

Chart 버전과 App 버전은 의도적으로 분리되어 관리된다.

 

 

[+] 의존성 차트 (Subchart) 개념

 

[+] 의미

• WordPress는 DB가 필요
• 기본값으로 MariaDB를 함께 설치
• mariadb.enabled=false 시 외부 DB 사용 가능

환경별 유연한 배포 설계

---

6. Chart → Release → Revision 흐름

 

---

7. 주요 명령어

명령어	명령어역할	Release 변화	Revision 변화	설명
helm install	최초 설치	생성	rev 1 생성	Chart를 처음 배포
helm upgrade	업데이트	유지	rev 증가	설정/차트 변경 적용
helm rollback	이전 상태 복원	유지	rev 증가	과거 Revision 기준으로 복원
helm list	상태 조회	없음	없음	설치된 Release 목록 확인

 

핵심 규칙

• Revision 번호는 절대 줄어들지 않는다.
• rollback도 새로운 Revision을 만든다.
• Release는 install 시 한 번만 생성된다.

---

마무리 요약

Helm Chart는 여러 Kubernetes 리소스를 하나의 애플리케이션 단위로 묶어
설치, 업그레이드, 롤백을 표준화하는 패키지다.
Helm 3에서는 보안과 운영성을 개선해 실무와 CKA 시험 모두에서 핵심 도구로 사용된다.