Helm

Kubernetes는 복잡한 인프라를 잘 다루지만, 사람은 복잡도를 직접 관리하기가 어렵습니다. 실제로 클러스터에 애플리케이션을 배포할 때는 여러 Kubernetes 오브젝트들의 조합이 필요해지고, 이 조합이 커질수록 운영 부담이 급격히 올라갑니다.

예를 들어 “상대적으로 단순한” WordPress조차 보통 이런 구성요소가 필요합니다.

• Deployment: WordPress 웹 서버, MySQL 같은 DB 파드 실행
• PV/PVC: DB 데이터 영속 저장
• Service: WordPress 웹 서버를 외부/내부로 노출
• Secret: 관리자 비밀번호, DB 인증 정보 등 민감 정보 저장
• (옵션) CronJob/Job: 백업, 정리 작업 등
• (옵션) Ingress: 도메인/경로 기반 라우팅

그리고 각 오브젝트마다 YAML 파일이 따로 있으면, 결국 이런 흐름이 됩니다.

1. YAML 파일 여러 개 준비
2. kubectl apply -f ...를 여러 번 실행
3. 기본 설정이 마음에 안 들면 여러 YAML을 열어 각각 수정
4. 시간이 지나 업그레이드가 필요하면 또 여러 YAML 수정
5. 나중에 삭제하려면 “이 앱에 속한 오브젝트가 뭐였지?”를 기억해서 하나씩 삭제

“그냥 다 합쳐서 한 YAML 파일로 만들면 되지 않나?”도 가능합니다. 하지만 한 파일이 수십 페이지가 되면, 트러블슈팅/수정 포인트 찾기가 더 어려워지는 역효과가 자주 납니다. 파일을 나눠두면 “deployment 관련은 mydeployment.yaml”처럼 위치라도 짐작할 수 있는데, 한 파일로 뭉치면 검색과 실수 가능성이 늘어납니다.

---

Kubernetes는 오브젝트만 알고, “앱”은 모른다

Kubernetes 자체는 “WordPress라는 앱”을 모르고, 단지 다음처럼 생각합니다.

• “Deployment 하나 만들라고 했네 → 만들자”
• “Service 하나 만들라고 했네 → 만들자”
• “PVC 하나 만들라고 했네 → 만들자”

즉, 각 오브젝트를 개별 리소스로만 관리합니다.
이 PV, 이 Secret, 이 Service, 이 Deployment가 “하나의 WordPress 앱”에 속한다는 앱 단위의 맥락을 Kubernetes는 기본적으로 묶어주지 않습니다.

---

Helm: Kubernetes의 “패키지 매니저” + “릴리즈 매니저”

Helm은 이 문제를 해결하기 위해 애플리케이션을 ‘오브젝트 묶음(패키지)’으로 관리하는 관점으로 설계되었습니다. 그래서 Helm을 흔히 이렇게 부릅니다.

• Kubernetes의 패키지 매니저
• 설치/업그레이드/삭제/롤백을 책임지는 릴리즈(Release) 매니저

핵심은 다음입니다.

• Helm에겐 “WordPress 앱 패키지(Chart)”가 있고
• 우리가 “WordPress라는 릴리즈를 설치/업그레이드/삭제”라고 말하면
• Helm이 내부적으로 “이 릴리즈에 속한 오브젝트들”을 알고 알아서 처리합니다.

---

게임 설치 프로그램 비유로 이해하기

게임 하나가 수십만 개 파일로 구성된다고 해도, 우리가 파일을 하나씩 다운로드/복사하지는 않습니다. 대신:

• 인스톨러 실행
• 설치 경로 선택
• Install 클릭

하면 설치기가 알아서 수많은 파일을 적절한 위치에 배치합니다.

Helm도 비슷합니다.

• 수십~수백 개 YAML 오브젝트를
• 우리가 오브젝트별로 신경 쓰지 않고
• “설치/업그레이드/삭제” 같은 한 번의 명령으로 애플리케이션 단위로 처리합니다.

---

values.yaml: “여러 YAML 수정”을 “한 곳에서 설정”으로 바꾸기

기존 방식에서는 PV가 20Gi로 되어 있으면 PV YAML/PVC YAML을 각각 찾아서 수정해야 합니다. 그리고 DB 비밀번호, 서비스 타입, replica 수… 설정 지점이 여러 파일에 흩어집니다.

Helm은 기본값을 갖고 있고, 우리가 바꾸고 싶은 값만 values.yaml 한 곳에 모아서 오버라이드합니다.

• PV 크기(예: 20Gi → 100Gi)
• WordPress 사이트 이름
• 관리자 비밀번호
• DB 설정(엔진/계정/스토리지 등)
• 리소스 requests/limits
• Service 타입(ClusterIP/NodePort/LoadBalancer)
• Ingress 설정(호스트/경로/TLS)

---

Helm 기본 개념 정리 (차트/릴리즈/리비전)

• Chart: 애플리케이션 패키지(템플릿 + 기본 values)
• Release: “차트를 특정 이름으로 특정 클러스터/네임스페이스에 설치한 결과물”
• Revision: release의 변경 이력(업그레이드할 때마다 revision이 증가)

Helm은 release의 상태/이력을 저장해두기 때문에 다음이 가능합니다.

• 업그레이드
• 롤백(이전 revision으로 되돌리기)
• uninstall 시 “이 릴리즈에 속한 리소스”를 추적해서 제거

---

자주 쓰는 Helm 커맨드: 설치부터 삭제까지

1) 차트 저장소(repo) 추가 & 검색

helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update

helm search repo wordpress

2) 설치(install)

# 예: my-wp 라는 release 이름으로 설치
helm install my-wp bitnami/wordpress -n blog --create-namespace

3) values 확인 후 커스터마이징

차트가 지원하는 values는 차트마다 다르므로, 먼저 “기본 values”를 확인하는 습관이 중요합니다.

helm show values bitnami/wordpress > values.yaml

그 다음 values.yaml에서 원하는 부분만 수정합니다. (아래는 “형태 예시”입니다. 실제 키는 차트의 values를 기준으로 확인하세요.)

# values.yaml (예시 형태)
wordpressUsername: admin
wordpressPassword: "change-me"

service:
  type: LoadBalancer

persistence:
  enabled: true
  size: 100Gi

mariadb:
  auth:
    rootPassword: "db-root-pw"
  primary:
    persistence:
      size: 100Gi

수정한 values로 설치/적용:

helm upgrade --install my-wp bitnami/wordpress -n blog -f values.yaml

upgrade --install은 “없으면 설치, 있으면 업그레이드” 패턴이라 운영에서 자주 씁니다.

4) 업그레이드(upgrade)

helm upgrade my-wp bitnami/wordpress -n blog -f values.yaml

5) 릴리즈 확인(list/status/get)

helm list -n blog
helm status my-wp -n blog

# 실제로 적용된 values 확인
helm get values my-wp -n blog

6) 롤백(rollback)

업그레이드가 문제를 일으키면 이전 revision으로 되돌릴 수 있습니다.

helm history my-wp -n blog
helm rollback my-wp 1 -n blog   # 예: revision 1로 롤백

7) 삭제(uninstall)

helm uninstall my-wp -n blog

중요 포인트(현업에서 자주 헷갈림):

• Helm uninstall은 “차트가 만든 리소스”를 지웁니다.
• 하지만 PVC/PV 데이터는 의도적으로 남기기도 합니다.
  • StorageClass의 ReclaimPolicy, 차트 설정, helm.sh/resource-policy: keep 여부 등에 따라 “데이터가 남을 수” 있습니다.
  • 즉 “앱은 지웠는데 데이터 볼륨은 남았다”가 정상 동작인 경우가 많습니다(데이터 보호 목적).

---

Helm이 주는 운영상 이점 요약

• 설치: 앱 전체를 단일 명령으로 설치
• 커스터마이징: values.yaml 한 곳에서 설정 변경
• 업그레이드: 단일 명령으로 버전/설정 변경 반영
• 롤백: revision 기반으로 안정적인 되돌리기
• 삭제: 릴리즈 단위로 관련 리소스를 추적해서 제거
• 앱을 앱답게: “오브젝트 묶음”이 아니라 “애플리케이션 단위”로 다루게 해줌

---

정리: Helm은 “마이크로 관리”를 없애준다

Kubernetes만으로도 앱 배포는 가능하지만, 규모가 커질수록 사람의 작업은 다음을 반복하게 됩니다.

• 파일 찾기
• 값 수정하기
• 적용/업그레이드 시 실수 방지
• 관련 리소스 추적/삭제

Helm은 이 부담을 “릴리즈”라는 개념으로 흡수해서, 우리가 다음만 말하게 만듭니다.

• “이 앱 설치해”
• “이 앱 업그레이드해”
• “이 버전으로 롤백해”
• “이 앱 삭제해”