Helm은 Kubernetes 환경에서 애플리케이션을 보다 쉽게 배포하고 관리하기 위한 패키지 관리 도구.
여러 개의 매니페스트 파일을 하나의 패키지 형태로 묶어 효율적인 배포와 버전 관리를 가능하게 한다.
Kubernetes 애플리케이션을 설치하기 위한 패키지
즉, 여러 개의 Kubernetes 리소스 파일(Deployment, Service, ConfigMap 등)을 하나의 버전 관리 가능한 묶음으로 만든 것.
배포 단순화
helm install my-app ./my-chart환경별 설정 관리
values.yaml 파일을 통해 개발, 스테이징, 운영 환경별 설정을 쉽게 분리할 수 있다.helm install my-app ./my-chart -f values-prod.yaml버전 관리 및 롤백
helm rollback my-app 1재사용과 표준화
| 구분 | 설명 |
|---|---|
| 배포 효율성 | 여러 리소스를 한 번에 설치하거나 업데이트 가능하다 |
| 유지보수 용이 | 버전 관리와 롤백 기능 내장되어 있다 |
| 재사용성 | 공통 Chart를 여러 서비스에서 재활용 가능하다 |
| 환경별 설정 용이 | values.yaml 파일로 손쉽게 환경별 설정 변경 가능하다 |
| CI/CD 연동성 | ArgoCD, Jenkins, GitOps 등과 자연스럽게 통합 가능하다 |
| 구분 | 설명 |
|---|---|
| 템플릿 복잡도 | Go 템플릿 문법이 복잡해질 경우 유지보수가 어려움 |
| 디버깅 어려움 | 렌더링된 결과를 보기 전까지 오류를 파악하기 힘듦 |
| 버전 충돌 가능성 | 여러 팀이 같은 Chart를 공유할 경우 관리 부담 증가한다. |
| 보안 주의 필요 | 외부 Chart Repository 사용 시 신뢰성 검증이 중요하다 |
brew install helm
curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash
choco install kubernetes-helm
설치 후 버전 확인:
helm version
my-chart/
├── Chart.yaml # Chart 메타데이터 (이름, 버전 등)
├── values.yaml # 기본 설정 값
├── templates/ # Kubernetes 매니페스트 템플릿
│ ├── deployment.yaml
│ ├── service.yaml
│ └── _helpers.tpl
└── README.md
helm create my-chart
이 명령으로 my-chart 디렉토리가 생성되며, 기본 Deployment/Service 템플릿이 포함되어 있다.
helm package ./mychart
./mychart: Chart 디렉토리 경로
실행 결과: mychart-<버전>.tgz 파일 생성 (Chart.yaml의 version 참조)
만들어진 Chart를 실제 Kubernetes 클러스터에 배포하려면:
helm install my-app ./my-chart
my-app은 Release 이름이며, Helm은 이 이름을 기준으로 배포 이력을 관리한다.
배포 후 상태 확인:
helm status my-app
현재 클러스터 내 설치된 Helm Release 목록 보기:
helm list
환경별 설정 값을 수정하려면 values.yaml을 수정하거나,
별도의 파일을 만들어 옵션으로 지정할 수 있다.
예시:
helm upgrade my-app ./my-chart -f values-prod.yaml
또는 명령어 인라인(--set) 방식으로도 변경 가능:
helm upgrade my-app ./my-chart --set image.tag=v2.0.0
Helm은 이전 배포 이력을 자동으로 관리하므로, 문제가 생기면 손쉽게 롤백할 수 있다.
helm rollback my-app 1
더 이상 필요 없는 배포는 아래 명령으로 제거할 수 있다.
helm uninstall my-app
삭제 후에도 이력은 남기지 않으므로, 완전히 제거된다.
템플릿이 실제로 어떤 YAML로 생성되는지 보고 싶다면:
helm template ./my-chart
이 명령은 Chart를 실제로 배포하지 않고, Kubernetes 리소스 매니페스트를 콘솔에 출력한다.
디버깅 시 유용하다.
Helm은 공식 및 커뮤니티 Chart Repository를 통해
Nginx, MySQL, Redis 등 이미 만들어진 Chart를 바로 설치할 수 있다.
bitnami는 이제 미지원이라고 보면 된다.
예시:
helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update
helm install my-mysql bitnami/mysql
Repository 목록 확인:
helm repo list
| 항목 | 명령어 | 설명 |
|---|---|---|
| Chart 생성 | helm create my-chart | 새 Chart 기본 구조 생성 |
| Chart 설치 | helm install my-app ./my-chart | 클러스터에 배포 |
| 설정 변경 | helm upgrade my-app ./my-chart -f values.yaml | 환경별 설정 적용 |
| 롤백 | helm rollback my-app 1 | 이전 버전으로 되돌리기 |
| 삭제 | helm uninstall my-app | Release 제거 |
| 템플릿 확인 | helm template ./my-chart | 렌더링 결과 미리보기 |
동일 패턴의 여러 사이트 운영 예시
여러 개의 유사한 사이트를 운영해야 하는 경우, Helm이 유용하다.
Helm + Git 브랜치 관리 가이드**를 실제 예시
networking-chart values 파일로 분리)customer-a, customer-b, customer-c
networking-chart/
├── Chart.yaml
├── values.yaml
├── templates/
│ ├── daemonset.yaml
│ ├── configmap.yaml
│ └── _helpers.tpl
├── values-customer-a.yaml
├── values-customer-b.yaml
├── values-customer-c.yaml
└── README.md
Chart.yamlapiVersion: v2
name: networking-chart
description: Helm chart for deploying Cilium CNI
version: 1.2.0
appVersion: "1.16.0"
values.yaml (기본 설정)cilium:
image: quay.io/cilium/cilium
version: v1.15.6
enableHubble: false
clusterName: default
resources:
requests:
cpu: 100m
memory: 128Mi
values-customer-a.yamlcilium:
version: v1.14.8
enableHubble: true
clusterName: customer-a-cluster
resources:
requests:
cpu: 250m
memory: 256Mi
values-customer-b.yamlcilium:
version: v1.15.6
enableHubble: false
clusterName: customer-b-cluster
resources:
requests:
cpu: 150m
memory: 200Mi
values-customer-c.yamlcilium:
version: v1.16.0
enableHubble: true
clusterName: customer-c-cluster
resources:
requests:
cpu: 300m
memory: 512Mi
각 환경(고객사)별로 Helm 명령을 아래처럼 실행한다.:
# Customer A
helm install cilium-a ./networking-chart -f values-customer-a.yaml
# Customer B
helm install cilium-b ./networking-chart -f values-customer-b.yaml
# Customer C
helm install cilium-c ./networking-chart -f values-customer-c.yaml
필요시 Helm CLI를 이용해 직접 --set 옵션으로 일부 설정을 덮어쓸 수 있다.(최우선순위 적용):
helm upgrade cilium-a ./networking-chart \
--set cilium.version=v1.16.1 \
--set cilium.enableHubble=true
| 환경 | Cilium 버전 | Hubble | CPU | Memory | Cluster Name |
|---|---|---|---|---|---|
| customer-a | v1.14.8 | ㅇ | 250m | 256Mi | customer-a-cluster |
| customer-b | v1.15.6 | x | 150m | 200Mi | customer-b-cluster |
| customer-c | v1.16.0 | ㅇ | 300m | 512Mi | customer-c-cluster |
여러 환경을 운영을 위해 Git 브랜치 전략으로 Chart와 설정을 분리 관리하는 것이 좋다.
git-repo/
├── charts/
│ └── networking-chart/ # 공통 Helm Chart
├── values/
│ ├── customer-a/values.yaml
│ ├── customer-b/values.yaml
│ ├── customer-c/values.yaml
├── environments/
│ ├── customer-a/ # GitOps 툴 (ArgoCD 등) 참조 경로
│ ├── customer-b/
│ ├── customer-c/
└── README.md
| 브랜치 | 역할 |
|---|---|
| main | 공통 Chart 및 안정화된 버전 유지 |
| feature/update-cilium-v1.16 | Cilium 버전 업그레이드 테스트 |
| customer-a | Customer A 전용 설정 관리 (values 차별화) |
| customer-b | Customer B 전용 설정 관리 |
| customer-c | Customer C 전용 설정 관리 |
# 새로운 버전 테스트 브랜치 생성
git checkout -b feature/update-cilium-v1.16
# Chart.yaml 및 values.yaml 수정
vi charts/networking-chart/Chart.yaml
vi charts/networking-chart/values.yaml
# 변경 내용 커밋
git add .
git commit -m "Update Cilium to v1.16.0"
# main 브랜치로 Pull Request 생성 후 검토
git push origin feature/update-cilium-v1.16
배포 환경별로는 GitOps(예: ArgoCD, FluxCD)에서 브랜치를 추적하게 하여 자동 배포를 관리한다..
예를 들어 ArgoCD에서 각 고객사별로 다른 values 파일을 참조하도록 설정할 수 있습니다.
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: customer-a-cilium
spec:
project: default
source:
repoURL: https://github.com/org/k8s-networking.git
path: charts/networking-chart
targetRevision: customer-a
helm:
valueFiles:
- values/customer-a/values.yaml
destination:
server: https://kubernetes.default.svc
namespace: kube-system
| 항목 | 설명 |
|---|---|
| 공통 Chart 유지 | Cilium 기반 네트워킹 Chart를 하나만 관리 |
| 환경별 설정 분리 | values-*.yaml 또는 브랜치별 관리 |
| Git 관리 방식 | main에서 공통 Chart 유지, 고객/환경별 브랜치 운영 |
| GitOps 연동 | ArgoCD/FluxCD로 자동 배포 구성 가능 |
| 장점 | 설정 표준화, 버전 일관성, 빠른 업데이트 및 롤백 가능 |
Helm Chart 리포지토리의 목차 역할을 하는 YAML 파일이다.
즉, 리포지토리에 어떤 Chart가 있고, 각각의 버전이 어디서 다운로드되는지, 언제 생성됐는지 같은 정보를 모두 기록한 파일이다.
Helm에서 말하는 index 파일(index.yaml)은 Helm Chart 리포지토리의 목차 역할을 하는 YAML 파일이다.
즉, 리포지토리에 어떤 Chart가 있고, 각각의 버전이 어디서 다운로드되는지, 언제 생성됐는지 같은 정보를 모두 기록한 파일이다.
apiVersion: v1
entries:
mychart:
- version: 0.2.0
urls:
- https://example.com/charts/mychart-0.2.0.tgz
created: "2025-10-26T12:00:00Z"
- version: 0.1.0
urls:
- https://example.com/charts/mychart-0.1.0.tgz
created: "2025-10-20T12:00:00Z"
generated: "2025-10-26T12:01:00Z"
entries: Chart 이름별로 버전 리스트urls: 해당 Chart 패키지(.tgz) 다운로드 경로created: 해당 Chart 버전이 생성된 날짜generated: index.yaml이 생성된 날짜Helm 클라이언트가 Chart 목록을 조회할 수 있게 함
helm search repo 명령 시 index.yaml을 참고Chart 버전 관리
리포지토리 자동 갱신 지원
--merge 옵션)##Helm Package 명령 상세
helm package는 Helm Chart 디렉토리를 배포 가능한 .tgz 패키지 파일로 압축하는 명령어이다.
패키지로 만든 Chart는 Helm 리포지토리에 업로드하거나 다른 환경에서 설치할 수 있다.
helm package ./mychart
./mychart: 패키징할 Chart 디렉토리 경로
실행 결과: mychart-<버전>.tgz 파일 생성
Chart.yaml의 version 참조예시:
$ helm package ./mychart
Successfully packaged chart and saved it to: /home/user/mychart-0.1.0.tgz
| 옵션 | 설명 |
|---|---|
--destination | 패키지 저장 경로 지정 |
--version | Chart 버전을 override |
--app-version | Chart 안의 appVersion을 override |
--sign | 패키지 서명 |
--key | 서명 키 지정 |
--keyring | 서명 키링 파일 지정 |
예시:
helm package ./mychart --version 0.2.0 --destination ./dist
./dist/mychart-0.2.0.tgzhelm repo index ./dist --url https://example.com/charts --merge ./dist/index.yaml
helm install mychart ./dist/mychart-0.2.0.tgz
Helm Dependency는 하나의 Chart가 다른 Chart를 내부 의존성으로 포함하도록 관리하는 기능이다.
예시 (Helm 3 Chart.yaml):
apiVersion: v2
name: webapp
version: 1.0.0
dependencies:
- name: redis
version: 16.0.0
repository: "https://charts.bitnami.com/bitnami"
- name: postgres
version: 15.2.0
repository: "https://charts.bitnami.com/bitnami"
helm dependency update ./webapp
charts/ 디렉토리에 하위 Chart .tgz 다운로드Chart.lock 파일 갱신##ConfigMap 변경 시 자동 Rolling Update 트리거링
ConfigMap이 변경될 때, Deployment의 Rolling Update가 자동으로 시작되도록 설정하는 방법이다.
sha256sum 함수를 사용해 Deployment에 변경 내역을 주입하는 방식으로 구현ConfigMapGenerator를 사용해 문제 해결 가능 sha256sum 함수를 사용하여 configmap.yaml 파일 내용의 SHA-256 값을 계산하고, 이를 Pod의 annotation에 넣어 ConfigMap이 바뀔 때마다 자동으로 롤링 업데이트가 발생하도록 설정spec:
replicas: {{ .Values.replicaCount }}
selector:
matchLabels:
app.kubernetes.io/name: {{ .Chart.Name }}
template:
metadata:
labels:
app.kubernetes.io/name: {{ .Chart.Name }}
annotations:
checksum/config: {{ include (print $.Template.BasePath "/configmap.yaml") . | sha256sum }}
checksum/config annotation에 ConfigMap 내용의 SHA-256 해시를 주입helm upgrade를 수행하면 Deployment의 Pod가 롤링 업데이트 되는지 확인sha256sum 활용으로 자동화 및 변경 추적이 용이| 항목 | 설명 |
|---|---|
| 문제 | ConfigMap 변경 시 Deployment 자동 롤링 업데이트 미발생 |
| 해결책 | ConfigMap 내용 SHA-256 해시를 Deployment annotation에 삽입 |
| 방법 | Helm 템플릿 함수 sha256sum과 include 사용 |
| 결과 | ConfigMap 변경 시 Pod 정의 변경 → 자동 롤링 업데이트 |
`