쿠버네티스 실습: Helm Chart로 애플리케이션 배포 자동화하기

쿠버네티스 실습: Helm Chart로 애플리케이션 배포 자동화하기

쿠버네티스를 일정 수준 이상 다루다 보면 매니페스트 관리의 복잡성이라는 문제에 부딪히게 됩니다.
Deployment, Service, ConfigMap, Secret, Ingress 등을 모두 각각의 YAML 파일로 관리하다 보면, 환경별 차이나 운영 중 수정 사항을 반영하기가 쉽지 않습니다.
이럴 때 해결책이 되는 것이 바로 Helm Chart입니다.

Helm은 단순히 설치 도구가 아니라, 재현 가능하고 유지 관리 가능한 배포 체계를 만들어 주는 쿠버네티스 표준 툴입니다.
이번 글에서는 Helm Chart를 활용한 자동 배포를 실습하면서, 현업에서도 활용 가능한 패턴을 함께 살펴보겠습니다.

---

1) Helm이 필요한 이유

1. 운영 효율성: YAML 수십 개를 직접 관리하지 않아도 됨.
2. 환경 일관성: values.yaml을 통해 개발/스테이징/운영 환경별 차이를 쉽게 반영.
3. 버전 관리 용이성: upgrade, rollback으로 배포 이력을 추적 가능.
4. 생태계 활용: 공식 Chart 저장소에서 PostgreSQL, Redis, Prometheus, Grafana 등 오픈소스 패키지를 바로 가져다 사용 가능.

즉, Helm은 DevOps 파이프라인의 중심으로 자리 잡을 수밖에 없습니다.

---

2) Helm 설치

macOS(Homebrew)에서 설치:

brew install helm
helm version

출력 예시:

version.BuildInfo{Version:"v3.15.2", ...}

---

3) 첫 번째 Chart 생성

helm create hello-nginx

구조 확인:

hello-nginx/
  charts/          # 서브 차트
  templates/       # 매니페스트 템플릿
  values.yaml      # 변수 파일
  Chart.yaml       # 차트 메타데이터

이 기본 구조는 템플릿 엔진을 적용할 수 있게 되어 있으며, 재사용성이 매우 높습니다.

---

4) values.yaml 수정

예시:

replicaCount: 2

image:
  repository: nginx
  tag: "1.27"
  pullPolicy: IfNotPresent

service:
  type: NodePort
  port: 80
  nodePort: 30080

resources:
  requests:
    cpu: "100m"
    memory: "128Mi"
  limits:
    cpu: "200m"
    memory: "256Mi"

values.yaml은 환경별 차이를 집중 관리할 수 있는 핵심입니다.
CI/CD 환경에서 이 파일만 교체하면 환경 전체를 자동화할 수 있습니다.

---

5) 배포하기

반응형

helm install hello-nginx ./hello-nginx

상태 확인:

kubectl get pods
kubectl get svc hello-nginx

브라우저 접속:

minikube service hello-nginx

---

6) 업그레이드와 롤백

Replica 개수를 수정하고 적용:

helm upgrade hello-nginx ./hello-nginx

과거 버전으로 롤백:

helm rollback hello-nginx 1

이렇게 하면 운영 중 장애가 생겼을 때 빠르게 안정화할 수 있습니다.

---

7) 실무 적용 전략

Helm을 단순 설치 도구가 아닌, 검색 최적화 가능한 운영 문서로 생각하면 활용도가 달라집니다.

• 전략 1 (가치 중심 콘텐츠): Helm을 통해 배포 자동화를 실무 가치와 연결해 설명 → 독자가 “왜 Helm이 필요한지” 명확히 이해.
• 전략 2 (검색 의도 반영): 독자가 자주 검색하는 키워드(Helm Chart, 자동배포, rollback, values.yaml)를 자연스럽게 포함 → 검색 엔진 최적화 강화.
• 전략 3 (권위 있는 참고와 예시): 공식 Helm 저장소나 CNCF 문서 활용 → 신뢰도 확보.
• 전략 4 (사용 경험 강조): 단순한 코드 나열이 아니라 “실패 시 롤백 경험” 같은 현장성 있는 스토리 추가 → 독자 공감 유도.

이렇게 하면 단순한 튜토리얼이 아니라, 검색 엔진에 잘 노출되고 독자에게 실제 도움을 주는 글이 됩니다.

---

8) 정리

• Helm은 쿠버네티스 매니페스트 관리 복잡성을 줄이고, 배포 자동화를 가능하게 함.
• values.yaml을 통해 환경별 차이를 일관성 있게 반영.
• install, upgrade, rollback으로 안정적인 운영 지원.
• 실제 프로젝트에서는 Helm Chart에 ConfigMap, Secret, PVC, Ingress, HPA까지 통합해 하나의 패키지로 관리하는 것이 일반적.

다음 글에서는 Helm Chart에 NestJS, NextJS, PostgreSQL, Redis를 통합해, “위치 기반 주유소 정보 시스템”을 쿠버네티스에 올리는 풀 패키지 자동 배포를 실습하겠습니다.

---

 

쿠버네티스,Helm,HelmChart,자동배포,DevOps,Minikube,매니페스트관리,애플리케이션배포,클라우드네이티브,K8s실습

---

 

A. Helm Chart에 ConfigMap, Secret, PVC, Ingress, HPA 통합

장점

• 하나의 Helm Chart로 전체 인프라 구성 요소를 통합 관리할 수 있어, 복잡한 요구사항을 한 번에 자동화하는 구조를 실습할 수 있습니다.
• 실제 운영 환경에 매우 가깝고, 설치부터 스케일링, 네트워크, 로깅, 보안까지 한 벌로 적용해보는 경험을 할 수 있습니다.

참고 내용

• ConfigMap/Secret 자동 업데이트: Deployment 템플릿에 checksum/config 같은 annotation을 사용하면, ConfigMap/Secret 변경 시 자동 롤링 업데이트가 가능합니다. (Baeldung on Kotlin)
• Helm Secrets 관리 팁: Go-to 배포 시점에 직접 값을 받거나 helm-secrets 플러그인 등 암호화를 활용해 보안을 강화하는 방식이 좋습니다. (Cycode, blog.gitguardian.com)
• Helm Chart 구조화 베스트 프랙티스: 복잡한 아키텍처라면, 메인 차트와 서브차트(예: DB, Redis, Ingress 등)를 분리하여 단일 차트로 묶는 방식이 추천됩니다. (GitHub, codersociety.com)
• 문서화와 테스트의 중요성: chart best practices에서는 문서화, labels, template 테스트, 환경 분리 등 유지보수성을 중시합니다. (boxunix.com, Helm)

---

B. NestJS + NextJS 애플리케이션을 Helm으로 자동 배포

장점

• 사용자가 익숙한 앱 중심 구조로 어플리케이션 차트 생성부터 values.yaml 기반 설정 변경, 업그레이드, 롤백까지 실질적인 워크플로우 중심 실습이 가능합니다.
• Helm 사용법의 응용력을 직관적으로 익힐 수 있고, 애플리케이션 배포 자동화에 바로 적용할 수 있습니다.

---

추천 드리는 선택 기준

상황 조건 추천 실습

“복잡한 스택을 한번에 구성해보고 싶다”	A. 통합 Helm Chart 구성
“실제 애플리케이션을 Helm으로 배포하고 싶다”	B. NestJS + NextJS 전용 차트

---