⚙️ Helm 마스터하기: CRD 설치는 건너뛰고, 템플릿만 쏙 뽑아보기!

안녕하세요, 쿠버네티스 유저 여러분! 👋 오늘은 Helm을 더욱 강력하고 유연하게 사용할 수 있게 해주는 두 가지 핵심 기능에 대해 알아보려고 합니다. 바로 CRD(Custom Resource Definitions) 설치를 건너뛰는 기능과, 차트를 실제로 설치하지 않고 결과물인 쿠버네티스 매니페스트(YAML)만 확인하는 기능입니다.

 

이 기능들이 왜 필요하고, 언제 어떻게 사용해야 하는지 궁금하셨나요? CI/CD 파이프라인을 구축하거나, 복잡한 차트를 안전하게 관리하고 싶다면 오늘 내용에 꼭 주목해 주세요! 🚀

 

---

🤔 CRD, 왜 설치를 건너뛰고 싶을까요?

Helm 차트에는 애플리케이션에 필요한 CRD가 crds/ 디렉터리에 포함된 경우가 많습니다. helm install을 실행하면 Helm은 다른 템플릿보다 먼저 이 CRD들을 클러스터에 설치해주죠. 편리한 기능이지만, 몇 가지 상황에서는 이게 오히려 문제가 될 수 있습니다.

1. 권한 문제 🛡️: 클러스터 전체에 영향을 미치는 CRD를 설치하려면 높은 수준의 권한(Cluster-Admin)이 필요합니다. 하지만 일반 애플리케이션 배포는 제한된 네임스페이스 권한으로만 진행하고 싶을 수 있습니다. 역할과 책임을 분리하는 거죠.
2. CRD 중앙 관리 🏛️: 여러 팀이나 여러 애플리케이션이 동일한 CRD를 공유해서 사용하는 경우가 있습니다. (예: Prometheus Operator, Istio). 이럴 때 각 팀이 Helm 차트를 설치할 때마다 CRD를 설치/업그레이드하려고 시도하면 충돌이 발생하거나, 한 팀의 업그레이드가 다른 팀에 영향을 줄 수 있습니다. CRD는 클러스터 관리자가 중앙에서 딱 한 번 설치하고 관리하는 것이 훨씬 안전합니다.
3. CRD 업그레이드 방지 🛑: Helm 3부터는 helm upgrade 시 crds/ 디렉터리의 CRD는 절대 업그레이드하지 않습니다. 실수로 CRD가 변경되거나 삭제되는 것을 막기 위한 안전장치이지만, 이 때문에 CRD 관리가 더 까다로워지기도 합니다. 그래서 처음부터 CRD는 Helm 차트와 별개로 관리하는 전략을 선택하기도 합니다.

이런 문제를 해결하기 위해 Helm은 아주 간단한 해결책을 제공합니다.

✅ --skip-crds 플래그 사용하기

이름 그대로, CRD 설치를 건너뛰게 해주는 마법의 플래그입니다. helm install 또는 helm upgrade 명령어에 --skip-crds 플래그를 추가하기만 하면 됩니다.

 

사용 예시:

# prometheus-community/kube-prometheus-stack 차트를 설치하되, 
# CRD는 이미 클러스터에 설치되어 있다고 가정하고 건너뛴다.

$ helm install my-prometheus prometheus-community/kube-prometheus-stack --skip-crds --namespace monitoring --create-namespace

 

이렇게 하면 Helm은 crds/ 디렉터리를 완전히 무시하고, 나머지 템플릿들(Deployment, Service, ConfigMap 등)만 클러스터에 설치합니다. 이제 CRD 관리는 클러스터 관리자의 몫으로 남겨두고, 애플리케이션 개발자는 안전하게 자신의 애플리케이션 배포에만 집중할 수 있습니다!

---

🧐 "어떤 YAML이 만들어질까?" 렌더링 결과 미리보기

Helm 차트는 values.yaml 파일과 로직(함수, 조건문 등)이 결합되어 최종적으로 쿠버네티스 YAML 파일을 만들어내는 '틀'입니다. 그런데 때로는 클러스터에 실제로 무언가를 설치하기 전에, Helm이 과연 어떤 YAML 파일을 만들어낼지 눈으로 직접 확인하고 싶을 때가 많습니다.

 

이럴 때 helm template 명령어가 아주 유용합니다.

1. GitOps 워크플로우 🤖: ArgoCD나 Flux 같은 GitOps 도구는 최종적으로 렌더링된 YAML 파일을 소스코드 저장소(Git)에 저장하고 클러스터와 동기화합니다. helm template은 바로 이 '렌더링된 YAML'을 생성하는 핵심 도구입니다.
2. CI/CD 파이프라인 💡: 변경 사항을 클러스터에 적용하기 전, CI 단계에서 helm template을 실행하여 생성될 YAML 파일이 문법적으로 올바른지, 의도한 대로 변경되었는지 자동으로 검증(lint, validate)할 수 있습니다.
3. 정책 검사 (Policy Check) 👮: OPA(Open Policy Agent) 같은 도구를 사용해 "모든 Pod에는 특정 레이블이 있어야 한다" 또는 "LoadBalancer 타입의 Service는 만들 수 없다" 같은 조직의 정책을 렌더링된 YAML 파일에 적용하여 준수 여부를 검사할 수 있습니다.
4. 단순 디버깅 및 학습 🧑‍🎓: 내가 수정한 values.yaml 파일이 템플릿에 어떻게 적용되는지, 이 차트는 도대체 어떤 리소스들을 만들어내는지 확인하고 싶을 때 가장 빠르고 안전한 방법입니다.

✅ helm template 사용하기

helm template 명령어는 helm install과 매우 유사하게 사용할 수 있지만, 클러스터와 통신하는 대신 결과물을 터미널 화면(stdout)에 출력해 줍니다.

# my-chart 라는 로컬 차트의 템플릿 결과를 출력한다.

$ helm template ./my-chart

실전 활용 예시 (다양한 플래그와 함께):

helm install에서 사용하는 대부분의 플래그를 helm template에서도 똑같이 사용할 수 있어 실제 설치 상황을 거의 완벽하게 시뮬레이션할 수 있습니다.

# 릴리즈 이름을 'my-release'로 지정하고,
# 'production' 네임스페이스에 설치되는 상황을 가정하며,
# 별도의 values-prod.yaml 파일을 사용하여 템플릿을 렌더링하고,
# 그 결과를 my-manifests.yaml 파일로 저장한다.

$ helm template my-release ./my-chart \
  --namespace production \
  --values ./values-prod.yaml \
  > my-manifests.yaml

• my-release: 릴리즈 이름을 지정합니다. {{ .Release.Name }} 같은 템플릿 변수에 영향을 줍니다.
• --namespace production: 네임스페이스를 지정합니다. {{ .Release.Namespace }} 변수에 영향을 줍니다.
• --values ./values-prod.yaml: 기본 values.yaml을 덮어쓸 추가 설정 파일을 지정합니다.
• >: 표준 출력 리디렉션을 사용해 결과를 파일로 저장합니다.

---

✨ 정리하며

오늘은 Helm의 강력한 보조 기능인 --skip-crds와 helm template에 대해 알아보았습니다.

• --skip-crds: 권한 분리와 안정적인 CRD 관리가 필요할 때 CRD 설치만 쏙 빼고 나머지를 설치합니다.
• helm template: 클러스터에 영향을 주지 않고 생성될 리소스를 미리 확인하여 GitOps, CI/CD, 정책 검사 등 다양한 자동화에 활용합니다.

이 두 가지 기능을 잘 활용하면 Helm을 훨씬 더 안전하고 전문적으로 다룰 수 있게 될 겁니다. 여러분의 쿠버네티스 운영이 한결 편안해지기를 바랍니다! 😊

 

태그: Helm, Kubernetes, 쿠버네티스, CI/CD, GitOps, DevOps, CRD, YAML, 템플릿