HELM

차트는 쿠버네티스 애플리케이션을 정의하는 파일들의 집합이다. 하나의 차트는 특정 서비스나 애플리케이션(예: NGINX 웹 서버, MySQL 데이터베이스)을 배포하는 데 필요한 모든 리소스 정의를 포함한다. 이는 디렉터리 구조로 구성되며, 가장 기본적인 차트는 Chart.yaml, values.yaml, templates/ 디렉터리 등의 파일로 이루어진다.

차트의 구조는 다음과 같다.

templates/ 디렉터리 내의 파일들은 고 템플릿 언어로 작성된 템플릿이다. 이 템플릿은 values.yaml 파일이나 사용자가 제공하는 값 파일의 변수로 렌더링되어, 실제 쿠버네티스에 적용할 매니페스트(디플로이먼트, 서비스, 컨피그맵 등)를 생성한다. 이를 통해 단일 차트로 다양한 환경(개발, 스테이징, 프로덕션)에 맞춰 설정을 변경하여 애플리케이션을 배포할 수 있다.

차트는 버전 관리가 가능하며, 의존성을 선언하여 다른 차트를 포함할 수 있다. 패키지 형식으로 .tgz 파일로 압축되어 헬름 리포지토리에 저장되고 공유된다. 사용자는 공개 리포지토리에서 차트를 검색해 설치하거나, 조직의 요구사항에 맞게 자체 차트를 생성하고 비공개 리포지토리에 호스팅할 수 있다.

HELM 리포지토리는 차트(Chart) 패키지를 저장하고 공유하는 서버를 가리킨다. 이는 APT나 YUM과 같은 전통적인 패키지 관리자의 저장소와 유사한 역할을 한다. 사용자는 리포지토리를 HELM 클라이언트에 추가하여 해당 리포지토리에 등록된 차트들을 검색하고 설치할 수 있다.

리포지토리는 크게 공개 리포지토리와 사설 리포지토리로 구분된다. 가장 대표적인 공개 리포지토리는 Artifact Hub와 연동된 공식 HELM 스테이블 리포지토리와 비트나미(Bitnami) 리포지토리이다. 사설 리포지토리는 조직 내부에서 자체 개발한 차트나 공개되지 않은 차트를 관리하기 위해 구축한다. 사설 리포지토리는 간단한 HTTP/HTTPS 서버, 객체 저장소(Object Storage) 또는 차트 뮤지엄(Chart Museum)과 같은 전용 리포지토리 서버를 이용해 호스팅할 수 있다.

리포지토리 관리에 사용하는 주요 HELM 명령어는 다음과 같다.

리포지토리는 index.yaml이라는 인덱스 파일을 유지하며, 이 파일은 저장된 모든 차트의 메타데이터(이름, 버전, 설명 등) 목록을 담고 있다. 사용자가 helm repo update를 실행하면 클라이언트는 이 인덱스 파일을 가져와 로컬 캐시를 업데이트하여 오프라인에서도 빠르게 차트를 검색할 수 있게 한다.

HELM에서 릴리스는 쿠버네티스 클러스터에 배포된 특정 차트의 인스턴스를 의미한다. 사용자가 helm install 명령어를 실행하면, HELM은 해당 차트의 템플릿과 사용자가 제공한 구성값(values.yaml)을 결합하여 실제 쿠버네티스 매니페스트 파일을 생성하고 클러스터에 배포한다. 이렇게 생성된 배포 단위가 바로 릴리스이다. 하나의 차트로부터 서로 다른 구성값을 사용하여 여러 개의 독립적인 릴리스를 생성할 수 있다. 예를 들어, 동일한 웹 애플리케이션 차트를 사용하여 개발 환경용 릴리스와 스테이징 환경용 릴리스를 각각 별도의 이름으로 배포하는 것이 가능하다.

릴리스는 자신의 수명 주기를 가지며, helm 명령어를 통해 전체적으로 관리된다. 주요 릴리스 관리 작업은 다음과 같다.

HELM은 모든 릴리스 변경 사항을 추적한다. helm upgrade를 수행할 때마다 릴리스의 새 리비전(Revision)이 생성된다. 이 히스토리를 통해 어떤 변경이 이루어졌는지 확인할 수 있으며, 필요시 helm rollback 명령어를 사용하여 특정 리비전으로 쉽게 복구할 수 있다. 릴리스 이름은 네임스페이스 내에서 고유해야 하며, 이를 통해 각 배포를 식별한다.

HELM 클라이언트는 사용자의 로컬 머신이나 CI/CD 파이프라인에서 실행되는 명령줄 도구이다. 이 클라이언트는 사용자가 HELM 차트를 관리하기 위한 모든 명령을 입력하는 주 인터페이스 역할을 한다.

주요 기능은 다음과 같다. 차트를 HELM 리포지토리에서 검색하고, 로컬에 다운로드하며, 쿠버네티스 클러스터에 차트를 설치하여 릴리스를 생성한다. 또한 기존 릴리스를 업그레이드, 롤백, 삭제하는 작업도 수행한다. 사용자는 helm install, helm upgrade, helm list, helm uninstall 등의 명령을 통해 쿠버네티스 애플리케이션의 라이프사이클을 관리한다.

HELM 클라이언트는 YAML 형식의 구성 파일과 명령줄 플래그를 통해 차트의 값을 오버라이드할 수 있다. 이는 동일한 차트를 서로 다른 환경(개발, 스테이징, 프로덕션)에 맞게 파라미터화하여 배포하는 데 필수적이다. 또한 클라이언트는 차트를 패키징(helm package)하고, 리포지토리에 푸시하는 작업도 담당한다.

HELM의 버전에 따라 클라이언트의 동작 방식에 차이가 있다. HELM 2에서는 클라이언트가 클러스터 내부에 설치된 Tiller 서버와 통신하여 명령을 실행했다. 반면, HELM 3에서는 Tiller가 제거되고, 클라이언트가 직접 쿠버네티스 API와 상호작용하는 아키텍처로 변경되었다. 이로 인해 HELM 3 클라이언트의 설치와 운영이 더 간소화되고 보안성이 향상되었다.

HELM 2에서는 Tiller라는 서버측 구성 요소가 쿠버네티스 클러스터 내에 별도의 파드로 배포되었다. Tiller는 HELM 클라이언트의 명령을 받아 클러스터 내에서 실제 차트의 설치, 업그레이드, 삭제 작업을 수행하는 역할을 담당했다. 이 아키텍처는 중앙 집중식 에이전트를 통해 릴리스를 관리했지만, Tiller가 광범위한 클러스터 관리 권한을 가지게 되어 보안상의 주요 취약점으로 지적되었다.

HELM 3에서는 Tiller가 완전히 제거되었다. 대신 HELM 클라이언트가 직접 쿠버네티스 API와 상호작용하며, 필요한 로직은 클라이언트에 내장된 HELM 라이브러리를 통해 처리된다. 이 변경으로 인해 설치 및 운영이 단순화되었고, 가장 중요한 보안 문제가 해결되었다. 이제 사용자는 쿠버네티스 RBAC를 통해 HELM 클라이언트를 실행하는 사용자나 서비스 계정에 필요한 권한만 부여하면 된다.

아키텍처 변화에 따라 릴리스 정보의 저장 방식도 변경되었다. HELM 2에서는 Tiller가 릴리스 정보를 쿠버네티스 ConfigMap에 저장했지만, HELM 3에서는 시크릿 객체에 저장하여 보안성을 강화했다. 이로 인해 HELM 2와 HELM 3은 서로 호환되지 않는 별개의 릴리스 저장소를 사용하게 되었다.

이러한 변화는 HELM을 더 가볍고 안전하게 만들었으며, 쿠버네티스의 표준 보안 및 인증 메커니즘과의 통합을 원활하게 했다.

HELM 차트는 쿠버네티스 애플리케이션을 정의하는 패키지입니다. 사용자는 공개된 차트 저장소에서 필요한 애플리케이션을 검색하고, 단일 명령어로 클러스터에 설치할 수 있습니다.

차트를 검색하려면 helm search 명령어를 사용합니다. 공식 Artifact Hub에 등록된 수많은 차트를 검색하려면 helm search hub [키워드]를 실행합니다. 예를 들어, helm search hub nginx는 NGINX와 관련된 공개 차트 목록을 보여줍니다. 이미 추가된 로컬 저장소에서 검색하려면 helm search repo [키워드]를 사용합니다. 저장소를 추가하지 않았다면, 먼저 공식 안정(stable) 저장소를 helm repo add stable https://charts.helm.sh/stable 명령으로 추가해야 합니다.

차트를 설치하여 쿠버네티스에 애플리케이션을 배포하는 과정을 HELM 릴리스 생성이라고 합니다. 기본 설치 명령어는 helm install [릴리스 이름] [차트 위치]입니다. 차트 위치는 저장소의 차트 이름(예: stable/nginx)이나 로컬 차트 디렉토리 경로, URL이 될 수 있습니다. 설치 시 --values 플래그로 사용자 정의 값 파일을 제공하거나, --set 플래그로 개별 파라미터를 덮어쓸 수 있습니다. 성공적으로 설치되면 HELM은 릴리스의 이름, 네임스페이스, 상태 및 리비전 번호 등의 정보를 출력합니다.

설치 후 helm list 명령으로 현재 네임스페이스의 모든 릴리스 목록을 확인할 수 있습니다. 특정 릴리스의 상세 정보와 사용된 값은 helm get manifest [릴리스 이름]과 helm get values [릴리스 이름] 명령으로 조회합니다.

릴리스는 HELM 차트의 특정 인스턴스를 의미합니다. 동일한 차트를 같은 쿠버네티스 클러스터에 서로 다른 구성 값으로 여러 번 설치하면 각각 독립적인 릴리스가 생성됩니다. 이는 하나의 애플리케이션 패키지를 다양한 환경(예: 개발, 스테이징, 프로덕션)이나 다른 설정으로 배포할 수 있게 해줍니다.

릴리스 관리는 주로 helm list, helm upgrade, helm rollback, helm uninstall 명령어를 통해 이루어집니다. helm list (또는 helm ls) 명령을 실행하면 현재 클러스터에 배포된 모든 릴리스의 이름, 네임스페이스, 리비전 번호, 상태, 차트 버전 정보를 확인할 수 있습니다. helm upgrade 명령은 기존 릴리스의 구성을 업데이트하거나 차트의 새 버전으로 업그레이드할 때 사용합니다. 업그레이드가 성공하면 릴리스의 리비전 번호가 1씩 증가합니다.

릴리스의 변경 이력은 리비전 단위로 관리됩니다. 문제가 발생했을 때 helm rollback <RELEASE_NAME> <REVISION_NUMBER> 명령을 사용하면 특정 리비전 상태로 쉽게 되돌릴 수 있습니다. 예를 들어, helm rollback my-app 2는 my-app 릴리스를 리비전 2의 상태로 복원합니다. 애플리케이션을 완전히 제거해야 할 때는 helm uninstall <RELEASE_NAME> 명령을 사용합니다. HELM 3에서는 이 명령이 실행되면 해당 릴리스와 관련된 대부분의 쿠버네티스 리소스가 제거됩니다[1].

릴리스 상태는 주로 다음 중 하나로 표시됩니다.

차트를 생성하려면 helm create 명령어를 사용하여 기본 구조의 차트를 만들 수 있다. 이 명령은 지정한 이름의 디렉토리를 생성하고, 그 안에 YAML 파일과 템플릿 파일들로 구성된 표준 차트 구조를 준비한다. 생성된 디렉토리 내에는 Chart.yaml(차트 메타데이터), values.yaml(기본 구성 값), templates/ 디렉토리(쿠버네티스 매니페스트 템플릿), 그리고 charts/ 디렉토리(의존성 차트)가 포함된다. 개발자는 이 기본 구조를 바탕으로 자신의 애플리케이션에 맞게 템플릿과 값을 수정한다.

차트의 핵심 파일인 Chart.yaml에는 다음과 같은 메타정보가 정의된다.

템플릿 파일은 templates/ 디렉토리 내에 위치하며, Go 템플릿 언어를 확장한 Helm 템플릿 언어로 작성된다. 이 템플릿들은 values.yaml 파일이나 설치 시 제공되는 값 파일에 정의된 변수들을 활용하여 동적인 쿠버네티스 리소스 매니페스트를 생성한다. 템플릿 내에서는 조건문, 반복문, 함수, 파이프라인 등을 사용하여 복잡한 로직을 구현할 수 있다.

차트 개발이 완료되면, helm package 명령어를 실행하여 차트 디렉토리를 패키징한다. 이 명령은 차트를 .tgz 확장자의 압축 파일로 만들어주며, 패키지명에는 차트 이름과 버전이 자동으로 포함된다. 패키징 전에 helm lint 명령으로 차트 구조와 문법에 문제가 없는지 검증하는 것이 좋다. 생성된 패키지는 Helm 차트 리포지토리에 업로드하여 공유하거나, helm install 명령에 직접 경로를 지정하여 설치할 수 있다.

차트 템플릿은 Helm 차트의 핵심 구성 요소로, Kubernetes 매니페스트 파일을 생성하기 위한 템플릿 파일이다. 이 파일들은 templates/ 디렉터리 내에 위치하며, Go 템플릿 언어를 기반으로 작성된다. 템플릿은 고정된 YAML 파일이 아니라, 사용자가 제공하는 값(Values)이나 빌트인 객체에 따라 동적으로 내용이 채워지는 청사진 역할을 한다. 이를 통해 단일 차트로 다양한 환경(개발, 스테이징, 프로덕션)에 맞는 Kubernetes 리소스를 생성할 수 있다.

템플릿 내에서는 점(.) 표기법을 사용하여 Values 객체에 접근한다. 예를 들어, {{ .Values.image.repository }}는 사용자가 정의한 컨테이너 이미지 저장소 이름을 참조한다. values.yaml 파일은 이러한 값들의 기본값을 정의하는 곳이다. 사용자는 --set 플래그를 사용하거나 별도의 값 파일(myvalues.yaml)을 -f 옵션으로 제공하여 이 기본값을 재정의할 수 있다. 이는 설정과 코드를 분리하는 핵심 메커니즘이다.

템플릿은 단순한 변수 치환을 넘어 조건문(if/else), 반복문(range), 파이프라인(|), 함수 호출 등 강력한 논리를 포함할 수 있다. 또한 _helpers.tpl 파일에 정의된 네임드 템플릿을 생성하고 재사용하여 코드 중복을 줄일 수 있다. 템플릿 작성 시 주의할 점은 최종 생성된 YAML이 Kubernetes에 의해 유효해야 한다는 것이다. helm template 명령어는 실제 클러스터에 설치하지 않고도 렌더링된 매니페스트를 미리 검증하는 데 유용하다.

값(Values)의 관리 체계는 다음과 같이 구성된다.

이러한 계층적 구조를 통해 중앙 집중식 기본값 정의와 환경별 세부 조정이 가능해진다.

HELM Hooks는 쿠버네티스 리소스의 라이프사이클 특정 지점에 커스텀 작업을 삽입할 수 있게 해주는 기능이다. 이를 통해 차트 설치, 업그레이드, 롤백, 삭제 과정에서 추가적인 설정이나 정리 작업을 자동화할 수 있다. Hook은 특정 어노테이션으로 식별되며, 일반 쿠버네티스 매니페스트 파일과 동일한 형태로 작성되지만 별도의 디렉터리(templates/hooks/)에 위치하거나 templates/ 디렉터리 내에서 helm.sh/hook 어노테이션으로 정의된다.

Hook은 설치 프로세스 중 특정 시점에 실행된다. 주요 Hook 유형과 실행 시점은 다음과 같다.

Hook으로 생성된 리소스는 기본적으로 Hook 작업이 완료된 후 삭제된다. 그러나 "helm.sh/hook-delete-policy" 어노테이션을 사용하여 삭제 동작을 제어할 수 있다. 예를 들어, hook-succeeded 또는 hook-failed 정책을 지정하여 성공 또는 실패 시에만 리소스를 삭제하도록 설정할 수 있다. 테스트 Hook은 성공적인 배포를 검증하는 용도로 사용되며, helm test 명령을 통해 실행된다. 이는 포드가 정상적으로 기동하고 서비스를 제공하는지 확인하는 데 유용하다.

Hook의 실행 순서는 "helm.sh/hook-weight" 어노테이션 값에 의해 결정된다. 가중치는 정수로 표현되며, 값이 낮을수록 먼저 실행된다. 이를 통해 복잡한 배포 시나리오에서 여러 Hook 작업의 의존성과 순서를 정밀하게 제어할 수 있다. Hook은 데이터베이스 마이그레이션, 설정 파일 생성, 외부 서비스에 대한 사전 검증, 배포 후 알림 전송 등 다양한 운영 작업을 자동화하는 강력한 메커니즘을 제공한다.