Skip to Content
Infra & DevOpsK8s 패키지 매니저 Helm 기초 및 배포
☁️ Infra & DevOps2019년 9월 30일

K8s 패키지 매니저 Helm 기초 및 배포

#helm#kubernetes#infra-devops#chart

1. YML 템플릿화의 필요성

쿠버네티스(K8s) 클러스터 기반 플랫폼은 점차 서비스가 복잡해지면서 단순한 kubectl apply -f deployment.yaml 방식으로는 인프라 구성 요소를 관리하기 어려웠습니다. Redis HA 클러스터나 Kafka 같은 아키텍처는 컨피그맵, 시크릿, 서비스, 스테이트풀셋 등 설정 파일만 백여 줄에 달합니다. 이 수많은 YAML 파일을 복사/붙여넣기(Copy & Paste) 하다가 실수하는 치명적인 휴먼 에러를 방지하고, 마치 리눅스의 yum이나 Node.js의 npm처럼 쿠버네티스 앱을 손쉽게 패키징하고 버저닝(Versioning)하기 위해 Helm 도입이 필수적이었습니다.

2. Helm Chart의 구조와 핵심 개념

Helm은 CNCF 커뮤니티(Google, Microsoft 등) 주도하에 유지되는 Kubernetes 애플리케이션 패키지 매니저입니다.

  • Chart (차트): Helm이 관리하는 패키지 단위입니다. 복잡한 K8s 리소스들의 묶음이자 템플릿입니다.
  • Tiller (틸러): Helm 2.x 아키텍처 기준으로 K8s 클러스터 내부에 상주하며 클라이언트(helm)의 요청을 받아 실제 리소스를 배포하는 서버 컴포넌트입니다. (※ Helm 3부터는 제거되어 더 심플해졌습니다.)

3. Chart 배포 및 릴리즈 관리 및 구현

1. Helm 클라이언트 설치

환경에 맞는 패키지 매니저를 통해 Helm 바이너리를 로컬 장비에 설치합니다.

bash
# Ubuntu (Snap)
$ sudo snap install helm --classic
 
# MacOS (Homebrew)
$ brew install kubernetes-helm
 
# Windows (Chocolatey)
$ choco install kubernetes-helm
 
# 범용 설치 쉘 스크립트 실행
$ curl -LO https://git.io/get_helm.sh
$ chmod 700 get_helm.sh
$ ./get_helm.sh

2. Helm 초기화 및 Tiller 권한 설정 (Helm 2.x 기준)

helm init 명령은 로컬 클라이언트를 초기화하고 쿠버네티스 클러스터 안에 Tiller 파드를 띄우는 역할을 합니다.

단순히 helm init만 실행하면, 최신 K8s(RBAC 활성화 환경)에서는 권한 오류(no available release name found)가 발생하여 배포가 안 됩니다. 따라서 관리자(cluster-admin) 권한을 가진 ServiceAccount를 먼저 생성한 뒤 Tiller에 연결해주어야 합니다.

bash
# 1. Tiller용 ServiceAccount 생성
$ kubectl create serviceaccount --namespace kube-system tiller
 
# 2. cluster-admin 롤 바이딩 부여
$ kubectl create clusterrolebinding tiller-cluster-rule \
  --clusterrole=cluster-admin --serviceaccount=kube-system:tiller
 
# 3. Tiller 설치 및 권한 적용하여 초기화 (Upgrade)
$ helm init --service-account tiller --upgrade

3. Chart 검색 및 애플리케이션 배포(Install)

Helm 공식 저장소(Repository)에 등록된 수많은 검증된 오픈소스 스택들을 원클릭으로 배포할 수 있습니다. 예를 들어 Redis HA 환경을 구성해보겠습니다.

bash
# 차트 저장소에서 패키지 검색 (예: 280여 개 이상의 공식 차트 제공)
$ helm search
$ helm inspect stable/redis-ha # 해당 차트의 설명 및 기본 값(Values) 확인
 
# Redis HA 클러스터 배포 (릴리즈 이름: redis-ha-test)
$ helm install stable/redis-ha --name redis-ha-test

4. Custom Values 적용 (Upgrade)

온프레미스 환경에 동적 볼륨 프로비저닝(StorageClass)이 없거나 하드웨어 노드가 부족한 경우, 기본으로 잡힌 3대의 Replica나 PV 요구사항 때문에 배포가 Pending 상태로 실패할 수 있습니다. 차트의 동적 변수인 values.yaml 값을 덮어써서 커스터마이징 배포를 진행합니다.

yaml
# config.yaml (내 환경에 맞춰 수정 파일 생성)
persistentVolume:
  enabled: false # 로컬 볼륨 미지원 환경이므로 비활성화
replicas: 2      # 남은 워커 노드 수량에 맞춰 스케일 다운

작성한 커스텀 설정을 바탕으로 배포된 릴리즈를 손쉽게 업그레이드합니다.

bash
$ helm upgrade -f config.yaml redis-ha-test stable/redis-ha

4. 패키지 매니저 도입 결과

플랫폼 초창기에는 Helm 문법인 Go Template 형식의 {{ .Values.replicaCount }} 가 낯설게 느껴져 “그냥 YAML 복사해서 sed로 치환하면 되지 않느냐”는 의견도 있었습니다. 그러나 시스템의 규모가 커지고, 서비스의 잦은 스키마 변경 롤백(Rollback)과 패키지 배포 의존성을 관리해야 하는 시점에 접어들자, Helm Chart로 아키텍처를 패키징해둔 것이 온프레미스 설치 폐쇄망 배포 시간을 기하급수적으로 줄여주는 일등 공신이 되었습니다.

Last updated on