같은 앱을 Helm 과 Kustomize 로 두 번 포장하다

목표

같은 Deployment 를 두 가지 전달 도구로 패키징해 봅니다. Helm 으로 차트를 만들고 values 를 바꿔
템플릿·설치·업그레이드하고, Kustomize 로 base 를 짠 뒤 prod 오버레이로 replicas 와 라벨을 덧씌웁니다.
"어떤 매니페스트가 실제로 클러스터에 적용됐는가" 를 helm 릴리스와 kustomize 산출물 양쪽에서 확인합니다.

왜 중요한가

쿠버네티스 매니페스트는 손으로 쓴 YAML 하나로 끝나지 않습니다. 환경마다 replicas·이미지·라벨이
달라지고, 그 차이를 관리하는 방법이 곧 "앱 전달(delivery)" 의 핵심입니다. Helm 은 값(values)을
끼워 넣는 템플릿으로, Kustomize 는 base 위에 오버레이를 겹치는 방식으로 같은 문제를 풉니다.
둘의 사고방식은 다르지만 결과물은 똑같이 API 서버로 가는 매니페스트입니다.

helm install 과 helm upgrade 가 릴리스라는 단위로 변경 이력을 남긴다는 점, Kustomize 가 원본을
건드리지 않고 오버레이로만 차이를 표현한다는 점을 직접 만져 보면, 배포 파이프라인에서 "지금 무엇이
적용돼 있는가" 를 릴리스 리비전과 조립 결과로 되짚는 감각이 생깁니다.

단계

1. 네임스페이스 kcna-pkg 를 만듭니다.
2. helm create 로 webapp 차트 뼈대를 찍어 냅니다.
3. replicaCount 를 3 으로 바꿔 helm template 결과를 파일로 저장합니다.
4. 릴리스 web 으로 차트를 설치합니다.
5. --set replicaCount=5 로 업그레이드해 리비전과 replicas 를 올립니다.
6. Kustomize base(store Deployment)를 손으로 짜고 kubectl kustomize 로 조립을 확인합니다.
7. prod 오버레이로 replicas 4·env=prod 라벨을 덧씌워 적용합니다.
8. helm·kustomize 결과를 /root/kcna-pkg/report.txt 에 장부로 남깁니다.

참고

• helm list -n kcna-pkg -o json 과 helm history web -n kcna-pkg 로 릴리스 상태·리비전을 봅니다.
• kubectl kustomize <디렉터리> 는 클러스터에 손대지 않고 조립 결과만 보여 주므로, 적용 전에 확인하기 좋습니다.
• 공식 문서: [Helm Charts](https://helm.sh/docs/topics/charts/) ·

[Kustomize 레퍼런스](https://kubectl.docs.kubernetes.io/references/kustomize/).

단계 8개

1. 패키징 작업장 네임스페이스를 연다
2. helm 이 차트 뼈대를 찍어 낸다
3. values 를 바꿔 3개로 템플릿한다
4. 차트를 클러스터에 설치한다
5. 업그레이드로 5개로 키운다
6. Kustomize base 를 손으로 짠다
7. prod 오버레이로 4개·env=prod 를 씌운다
8. 무엇을 어떻게 패키징했는지 장부로 남긴다