Kubernetes 환경에서 Helm은 사실상 표준 패키지 매니저로 자리잡았습니다. 간단한 명령어 하나로 수백 줄의 YAML을 배포하고, 롤백과 업그레이드까지 처리할 수 있기 때문이죠. 하지만 Helm의 작동 방식은 매우 엄격하게 선언적이기 때문에, 때로는 커스터마이징의 유연성이 떨어진다는 피드백도 많습니다.
이 글에서는 Helm의 일반적인 특성과 한계, 그리고 이를 확장하는 방법까지 설명합니다.
Helm이란?
Helm은 Kubernetes 애플리케이션을 정의하고 설치하며 관리하는 패키지 매니저입니다. Linux의 apt, macOS의 brew에 대응된다고 볼 수 있습니다.
Helm의 핵심 요소는 다음과 같습니다:
| 구성요소 | 설명 |
| Chart | Kubernetes 리소스 템플릿 집합 |
| Values | 사용자 입력 값 (chart 설정을 제어) |
| Release | 특정 Chart의 인스턴스 (version 포함) |
| Templates | Go 템플릿 엔진 기반으로 Kubernetes 리소스를 생성 |
Helm의 기본 원리
- helm install myapp ./mychart 실행 시:
- templates/ 디렉토리의 YAML 파일과 values.yaml을 합쳐서 Kubernetes 리소스를 생성
- kubectl apply로 클러스터에 반영
- Release 정보는 클러스터에 Secret이나 ConfigMap 형태로 저장
- 이후 helm upgrade, helm rollback, helm uninstall 등을 통해 상태 관리 가능
Helm의 커스터마이징 한계
Helm은 chart template 내의 구조를 벗어난 사용자 정의 사항에 대해 다음과 같은 제약을 가집니다.
1. 선언적 상태 강제
Helm은 "source of truth"를 Chart의 template + values.yaml로 간주합니다. 이외의 변경 사항은 Helm이 알지 못합니다.
kubectl edit로 수동 변경해도 helm upgrade 시 원래대로 되돌아감
2. 특정 리소스만 override 허용
일부 chart는 다음과 같은 값을 통해 커스터마이징을 허용하지만:
config:
existingConfigMap: my-custom-config이는 ConfigMap 전체가 아닌 특정 key (config.conf 등)만 덮어씌우는 구조일 수 있습니다.
3. 고급 파일 마운트는 복잡
- extraVolumes, extraVolumeMounts를 사용해 파일을 마운트할 수 있지만,
- chart 내부에서 동일 경로에 default 값을 강제로 쓰면 무시되거나 overwrite됨
Helm 커스터마이징 확장 전략
Helm은 제한적일 수 있지만, 아래 방법으로 극복할 수 있습니다:
✅ 1. extraVolumes + extraVolumeMounts로 구성 파일 주입
extraVolumes:
- name: custom-config
configMap:
name: my-config
extraVolumeMounts:
- name: custom-config
mountPath: /etc/myapp/config.yaml
subPath: config.yaml⚠ 반드시 chart가 해당 경로에 파일을 자동으로 생성하지 않는지 확인 필요
✅ 2. chart 자체를 fork하거나 local chart 작성
- Helm chart의 템플릿 구조를 fork하여 직접 수정
- 필요한 설정 포인트를 더 노출하거나, 경로 변경 등 유연성 확보
git clone https://github.com/some-org/helm-chart
# 수정 후 로컬 chart로 설치
helm install myapp ./custom-helm-chart✅ 3. postRender hook 사용
Helm 3.1+부터는 --post-renderer 플래그를 통해, Helm이 생성한 YAML을 최종적으로 수정하는 필터 프로그램을 삽입할 수 있습니다.
예시:
helm install myapp ./mychart --post-renderer ./kustomize-wrapper.sh✅ 4. helm template + kustomize
Helm으로 YAML만 생성하고, 이를 Kustomize로 후처리해 완전히 커스터마이징:
helm template myapp ./mychart > rendered.yaml
kustomize build overlays/dev | kubectl apply -f -✅ Helm은 어디까지 쓸 수 있고, 어디서 멈춰야 하는가?
| 사용 목적 | 권장 여부 |
| 간단한 배포/업그레이드 | ✅ 강력 추천 |
| CI/CD 자동화 | ✅ 적합 |
| config-level 세부 제어 | ⚠ 제한적 |
| 파일 기반 설정 주입 | ⚠ 구조 분석 필요 |
| 전체 구조 커스터마이징 | ❌ 직접 작성이 더 낫다 |
결론
Helm은 Kubernetes 생태계에서 빠르고 일관된 배포를 위한 강력한 도구입니다. 그러나 Helm 자체는 "chart의 선언적 구조"에 매우 충실하기 때문에, 복잡한 커스터마이징에는 다소 부자연스럽거나 우회가 필요할 수 있습니다.
Helm을 사용할 땐 항상 다음을 기억하세요:
"Helm은 빠른 배포를 위한 것이지, 완벽한 구성 컨트롤러가 아니다."
필요 시 직접 YAML을 작성하거나, chart를 수정하는 것도 생산성을 높이는 전략이 될 수 있습니다.
댓글