Kustomize vs Helm

Helm과 Kustomize를 비교하면서, 왜 두 도구가 모두 필요하고, 어떤 프로젝트에 어떤 도구가 적합한지를 판단할 수 있는 안목을 키우는 데 목적. 단순한 기능 설명을 넘어서 철학, 구조, 유스케이스 차이를 직관적으로 정리.

---

✅ Helm과 Kustomize의 차이 요약

항목	Helm	Kustomize
핵심 기능	패키징 + 템플릿 + 배포 + 관리	순수 YAML 오버레이를 통한 환경별 설정
복잡도	비교적 복잡 (Go 템플릿 문법 사용)	단순, 읽기 쉬움
설정 방식	values.yaml로 변수 주입	patch.yaml로 리소스 오버레이드
구성 파일 문법	Go 템플릿 포함된 “비정형 YAML”	순수 YAML
조건문 / 반복문	지원 (if, range, function 등)	미지원
Hooks 지원	있음 (pre-install, post-delete 등)	없음
목적	패키지 배포와 설치 관리 중심	환경별 config 커스터마이징 중심
장점	기능 풍부, 공유/재배포 쉬움, 생태계 큼	구조 단순, 읽기 쉬움, 템플릿 無
단점	복잡한 템플릿 구조로 가독성 떨어짐	기능 제한적, 패키징/재배포는 어려움

---

🔍 Helm의 방식 정리

🧩 Helm 구조

mychart/
├── templates/
│   ├── deployment.yaml   ← Go 템플릿 문법 포함
│   └── service.yaml
├── values.yaml           ← default 값 정의
├── values.dev.yaml       ← dev 환경용 값
├── values.staging.yaml   ← staging 환경용
└── Chart.yaml            ← 메타데이터

📌 템플릿 예시 (deployment.yaml)

replicas: {{ .Values.replicaCount }}
image:
  tag: {{ .Values.image.tag }}

📌 값 정의 예시 (values.staging.yaml)

replicaCount: 2
image:
  tag: "2.4.4"

💻 설치 명령어

helm install my-app ./mychart -f values.staging.yaml

---

🎯 선택 기준: 언제 Helm? 언제 Kustomize?

상황	추천 도구	이유
외부 차트를 사용해야 함 (e.g. WordPress, nginx ingress 등)	Helm	이미 패키징된 차트 사용 가능
재사용 가능한 패키지를 만들고 배포해야 함	Helm	helm package, helm repo 기능
단순한 내부 애플리케이션 환경별 커스터마이징	Kustomize	YAML로 구성, 간단 명료
팀원이 YAML에 익숙하고 템플릿 문법이 부담스러움	Kustomize	읽기 쉬운 구조
배포 lifecycle 제어가 필요함 (hook, upgrade, rollback)	Helm	패키지 매니저 기능 내장
복잡한 조건 분기나 반복 설정이 필요한 경우	Helm	템플릿 문법으로 제어 가능

✅ 많은 실무에서는 Helm으로 배포하고, 이후 Kustomize로 환경별 patch를 입히는 하이브리드 방식도 활용함

---

🧠 핵심 정리

• Helm은 Kubernetes의 패키지 매니저로 기능이 풍부하고 재사용성과 배포 자동화에 유리
• Kustomize는 Kubernetes 리소스를 환경별로 쉽게 오버라이드 하기 위한 구성 관리 도구
• Helm은 템플릿 기반, Kustomize는 순수 YAML 기반
• 읽기 쉬움 vs 기능 풍부함의 트레이드오프
• 프로젝트 규모, 팀 구성, 배포 방식에 따라 선택은 달라질 수 있음