Helm이란? Kubernetes 프로젝트 관리, 유스 케이스
Helm이란?
Helm은 Kubernetes 구성 파일을 하나의 재사용 가능한 패키지로 통합하여 Kubernetes 애플리케이션의 생성, 패키징, 구성 및 배포를 자동화하는 도구이다.
마이크로서비스 아키텍처에서는 애플리케이션이 커질수록 마이크로서비스의 수가 늘어나면서 관리가 어려워진다. 오픈소스 컨테이너 오케스트레이션 기술인 쿠버네티스(Kubernetes)를 사용하면 여러 마이크로서비스를 하나의 배포로 묶어 프로세스를 간소화할 수 있다. 하지만 쿠버네티스 애플리케이션의 개발 라이프사이클을 관리할 때에도 버전 관리, 리소스 할당, 업데이트, 롤백 등 여러 가지 고유한 문제가 발생한다.
이러한 문제에 대한 가장 손쉬운 해결책 중 하나는 헬름(Helm)으로, 헬름을 사용하면 배포의 일관성, 반복성, 안정성을 높일 수 있다.
Helm을 사용하여 쿠버네티스 관리 간소화
컨테이너는 애플리케이션과 그 종속성을 하나의 이미지 파일로 묶은 경량 소프트웨어 컴포넌트이다. 컨테이너는 서로 다른 환경 간 이식성이 뛰어나 애플리케이션의 시작 시간을 단축하고 빠르게 확장할 수 있다.
쿠버네티스 배포는 YAML 설정 파일을 사용한다. 배포가 복잡하고 자주 업데이트되는 경우, 이러한 파일의 모든 버전을 추적하는 것은 어려운데, Helm은 하나의 배포용 YAML 파일과 버전 정보를 관리할 수 있는 편리한 도구이다. 이 파일을 사용하면 간단한 명령어로 복잡한 쿠버네티스 클러스터를 설정하고 관리할 수 있다. 여기에서는 헬름의 다양한 구성 요소를 살펴보고, 이를 활용하여 쿠버네티스 관리를 간소화하는 방법을 살펴본다.
Helm chart란?
Helm chart는 애플리케이션을 쿠버네티스 클러스터에 배포하는 데 필요한 모든 리소스를 포함하는 패키지이다. 패키지에는 배포, 서비스, 시크릿, 그리고 특정 애플리케이션의 상태를 정의하는 구성 맵의 다양한 YAML 설정 파일이 포함되어 있다.
Helm chart는 이러한 YAML 파일과 템플릿을 패키징한 것으로, 이를 통해 매개 변수화된 값에 따라 추가 설정 파일을 생성할 수 있다. 이러한 방식으로 다양한 환경에 맞게 설정 파일을 커스터마이징하거나 여러 배포에 재사용할 수 있는 설정 파일을 생성할 수 있다. 또한, 각 Helm chart를 개별적으로 버전 관리할 수 있기 때문에 서로 다른 설정의 여러 버전의 애플리케이션을 쉽게 관리할 수 있다.
config 파일
config 파일에는 애플리케이션의 설정이 포함되어 있으며, 일반적으로 YAML 파일에 저장되며, Kubernetes 클러스터의 리소스는 이 값에 따라 배포된다.
release
Chart를 실행하는 인스턴스를 릴리스라고 하며, helm install 명령을 실행하면 config 파일과 차트 파일을 가져와 모든 쿠버네티스 리소스를 배포한다.
아키텍처
Helm의 개념을 이해했다면, 이제 헬름의 아키텍처를 살펴볼 차례인데, Helm의 아키텍처에는 클라이언트와 라이브러리라는 두 가지 주요 구성요소가 있다.
Helm 클라이언트는 로컬 차트 개발, 리포지토리 및 릴리스 관리를 위한 엔드 유저용 커멘드 라인 유틸리티로, MySQL 명령을 실행하기 위해 MySQL 데이터베이스 클라이언트를 사용하는 것처럼 Helm 명령을 실행하기 위해 Helm 클라이언트를 사용한다.
Helm 라이브러리는 모든 주요 처리를 담당한다. 이 라이브러리에는 Helm 명령으로 지정된 처리를 실행하기 위한 실제 코드가 포함되어 있으며, Helm 라이브러리에서 config와 차트 파일의 조합을 처리하고 릴리스를 생성한다.
Helm 아키텍처는 버전 2에서 3으로 넘어오면서 크게 개선됐다. 버전 2에서는 Tiller 서버가 헬름 클라이언트와 쿠버네티스 API 서버를 중개하는 역할을 했다. 또한 Helm에서 생성한 모든 리소스를 추적했다. 버전 3에서는 클라이언트 전용 아키텍처를 지향하며 Tiller 서버를 없애고 API 직접 연결을 통해 쿠버네티스 API 서버와 상호작용하도록 했다.
Helm 작동 원리
Helm 애플리케이션 라이브러리는 차트를 사용하여 Kubernetes 애플리케이션을 정의, 생성, 설치 및 업그레이드할 수 있다. Helm 차트를 사용하면 쿠버네티스 명령줄 인터페이스(CLI)를 사용하지 않고도 클러스터를 제어하고 복잡한 쿠버네티스 명령어를 기억하지 않고도 쿠버네티스 매니페스트를 관리할 수 있다.
Helm이 유용하도록 현실적인 시나리오를 생각해 보자. 프로덕션 환경에 10개의 복제본이 있는 애플리케이션을 배포한다고 가정해보자. 애플리케이션의 YAML 파일에 이 사양을 지정하고 kubectl 명령을 사용하여 배포를 실행한다.
다음은 스테이징 환경에서 동일한 응용 프로그램을 실행한다. 그러나 스테이징 환경에는 3개의 복제본(replica)가 필요하며, 스테이징 환경에서는 내부 애플리케이션 빌드를 실행해야 한다. 이 경우 배포용 YAML 파일의 복제본 수와 Docker image 태그를 업데이트하고 스테이징 Kubernetes 클러스터에서 업데이트된 파일을 사용한다.
애플리케이션이 복잡할수록 YAML 파일의 수가 늘어난다. 하나의 앱을 다양한 환경에 배포하기 위해 수많은 YAML 파일을 업데이트하는 것은 매우 번거로운 일이며, 결과적으로 YAML 파일의 설정 필드도 늘어날 수밖에 없다. Helm을 사용하면 환경에 따라 필드를 파라미터화할 수 있다. 앞의 예에서는 복제본 수와 Docker 이미지에 정적 값을 지정하지 않고, 다른 파일에서 해당 값을 지정한다. 그 다른 파일은 values.yaml이다.
이 방식을 이용하면 환경별로 values 파일을 준비하고 각 파일에 적절한 값을 설정하면 되는데, Helm에서는 실제 YAML 설정과 설정 필드 값 관리를 분리할 수 있다.
Helm 저장소
Helm 리포지토리(repository)는 Helm 차트를 업로드할 수 있는 곳이다. 개인 리포지토리를 만들어 조직 내에서 차트를 공유할 수도 있고, Artifact Hub라는 글로벌 Helm 리포지토리를 통해 다양한 용도의 차트를 검색하고 설치할 수 있는 기능도 있다. 간단히 말해, Docker 이미지의 Docker Hub가 Helm 차트의 Artifact Hub라고 할 수 있다.
Helm으로 배포 및 롤백하기
Helm 차트를 생성한 후에는 앱을 배포하는 것은 매우 간단하며, 모든 Kubernetes 리소스를 배포하는 데 2~3개의 Helm 명령어만 실행하면 된다.
실제 예를 들어, 헬름 차트를 사용하여 배포한 쿠버네티스 클러스터에서 애플리케이션을 실행하고 있다고 가정해보자. 이 애플리케이션에 Prometheus와 같은 모니터링 솔루션을 구성해보자. 두 가지 선택지가 있다.
- Prometheus 애플리케이션을 위한 모든 배포와 서비스를 처음부터 새로 만든다면, 시간이 오래 걸린다.
- Artifact Hub에서 Prometheus 차트를 찾아 자신의 요구 사항에 따라 설정을 업데이트하고 설치한다. Docker Hub에서 기존 Docker 이미지를 찾아 Dockerfile의 FROM 문에 지정하는 것과 유사하다.
다음 단계에 따라 원하는 헬름 차트를 설치할 수 있다.
- Helm 라이브러리가 Helm 차트를 가져온 위치를 파악할 수 있도록 Helm 리포지토리를 로컬에 등록한다.
- 설정한 리포지토리에서 사용 가능한 모든 Helm 차트를 가져온다.
values.yaml파일을 필요에 따라 업데이트하고,helm install명령을 사용하여 특정 Helm 차트를 설치한다.
Helm을 사용하는 또 다른 장점은 롤백 프로세스가 간단하다는 것이다.
Helm은 애플리케이션 레벨에서 작동한다. 즉, 실행 중인 애플리케이션의 상태(‘릴리스’)가 유지된다. 애플리케이션의 새 버전을 배포했는데 예상대로 작동하지 않는 상황을 생각해 보면, helm rollback 명령을 사용하여 이전 안정된 릴리스로 되돌릴 수 있다. 이 명령은 모든 배포, 서비스, 쿠버네티스 리소스를 롤백한다.
Helm이 없었다면 이렇게 쉽게 롤백할 수 없었을 것이고, 각 쿠버네티스 리소스마다 롤백을 수행해야 했기 때문에 복잡한 애플리케이션을 관리하기가 더 어려웠을 것이다.
Helm과 CI/CD
Helm을 활용하면 CI/CD(Continuous intergration & Continuous Delivery) 파이프라인에서 Kubernetes 애플리케이션의 빌드 및 테스트가 훨씬 더 쉬워진다. 애플리케이션을 임의의 환경에 자동으로 배포하여 빌드 시간을 단축할 수 있다. 파이프라인에서 셀프 호스팅 런너를 사용하면 빌드 및 테스트 환경의 유연성을 높일 수 있다.
CircleCI의 셀프 호스팅 런너를 사용하면 사용자가 관리하는 환경에서 CI/CD 작업을 실행할 수 있다. 즉, 독립형 가상 머신이나 쿠버네티스와 같은 전체 클러스터를 실행 환경으로 사용할 수 있다. 컨테이너 러너를 사용하면 헬름 차트를 사용하여 컨테이너화된 워크로드를 프라이빗 쿠버네티스 클러스터에 배포하고 필요에 따라 환경을 확장할 수 있다.
Helm 사용의 장점과 단점
Helm에는 도움이 되는 사용 사례와 그렇지 않은 사용 사례가 있다. 이 섹션에서는 Helm이 도움이 되는 사용 사례와 도움이 되지 않는 사용 사례를 확인하고, Helm이 도움이 되는지 아닌지를 구분하는 몇 가지 포인트를 제시한다.
Helm이 적합한 경우
Helm은 수많은 마이크로서비스를 포함하는 복잡한 애플리케이션을 쿠버네티스에서 실행하는 프로젝트에 유용하며, Helm을 사용하면 애플리케이션 배포 및 관리를 쉽게 자동화하여 수작업을 줄이고 시스템의 안정성과 안정성을 향상시킬 수 있다. 또한, 사전 구성된 다양한 패키지로 구성된 리포지토리를 통해 애플리케이션에 새로운 기능을 쉽게 추가할 수 있다.
Helm을 사용하여 애플리케이션의 구성요소를 설치 및 업그레이드가 용이한 모듈형 차트로 구성하면 애플리케이션 구성요소 관리 프로세스를 간소화할 수 있다. 또한, 애플리케이션 유지보수에 필요한 수작업이 줄어들어 복잡한 시스템을 수동으로 관리할 때 발생하는 오류와 불일치를 방지할 수 있다.
Helm은 여러 환경(개발, 스테이징, 프로덕션 등)에 컨테이너를 배포할 수 있도록 지원하므로, 개발 프로세스 전반에 걸쳐 컨테이너의 라이프사이클을 쉽게 관리할 수 있다.
Helm이 적합하지 않은 경우
Helm은 서버에 배포해야 할 컨테이너가 하나뿐인 프로젝트에는 적합하지 않다. 이 경우 헬름으로 컨테이너 배포를 관리할 필요가 없으며, 오히려 헬름을 사용하면 프로세스가 복잡해질 수 있으며, 헬름은 여러 개의 컨테이너 배포를 하나의 단위로 관리하기 위해 만들어졌기 때문에 이 시나리오에는 적합하지 않다.
패키지 관리자를 사용하지 않고 소수의 쿠버네티스 애플리케이션을 수동으로 관리할 수 있는 경우에도 Helm은 큰 도움이 되지 않는다.
또한, Helm과 같은 타사 도구 사용을 금지하는 엄격한 보안 정책이 있는 환경에서는 Helm을 사용할 수 없을 것이다.
Helm을 도입해야 하는 이유
프로젝트에 Helm을 사용하는 것이 도움이 되는지 아닌지를 판단할 수 있는 몇 가지 포인트가 있다. 예를 들어, 프로젝트에 여러 개의 쿠버네티스 애플리케이션이 포함되어 있고, 이를 통합적으로 관리하고 배포해야 하는 경우이다. 이런 경우에는 Helm을 사용하여 이러한 애플리케이션을 하나의 차트로 패키징하면 관리와 배포가 용이해진다.
프로젝트에서 쿠버네티스 애플리케이션을 자주 업데이트하고 배포하는 경우에도 Helm은 애플리케이션의 라이프사이클(배포, 업데이트, 롤백 등)을 관리할 수 있는 툴을 갖추고 있기 때문에 도움이 된다. 따라서 애플리케이션 업데이트 관리와 배포가 훨씬 더 쉬워진다.
마지막은 프로젝트에 여러 팀과 구성원이 참여하여 공동으로 Kubernetes 애플리케이션을 개발하고 배포해야 하는 경우다. 이 경우 헬름의 버전 관리 및 차트 공유 기능이 도움이 되며, 팀 간 협업과 배포 간 일관성 유지가 용이해진다.