쿼카러버의 기술 블로그
[쿠버네티스] Helm이란? Helm 차트란? 본문
쿠버네티스는 container orchestration, 즉 컨테이너를 쉽고 빠르게 배포/확장하고 관리를 자동화해주는 툴이다. 쿠버네티스를 활용하면 다수의 컨테이너화된 어플리케이션을 쉽게 배포할 수 있다.
쿠버네티스를 활용한 어플리케이션 배포에 가장 기본이 되는 것은 yaml파일이다. 쿠버네티스의 오브젝트를 정의하고 생성할 때 yaml파일 형식을 활용하기 때문이다. 쿠버네티스를 통해 어플리케이션을 배포하기 위해서는 많은 object들이 필요하다. 대표적인 예가 deployment, pod, configmap secret, service, persistent volume, persistent volume claim 등이 있다.
위와 같은 쿠버네티스 object(리소스)들을 정의하고 다루는데 활용되는 yaml파일을 관리하는 것은 반복적이고 지루한 작업이다. 쿠버네티스를 통해 어플리케이션을 배포하다보면 비슷한 틀과 내용을 공유하고, 내부 값(configuration)만 일부 변경하면 되는데, 어플리케이션마다 모두 yaml파일을 만들어줘야 하다보니 매우 번거롭다.
자! 예상했겠지만 이러한 문제점을 해결해주기 위해 있는 것이 바로 helm이다. helm은 쿠버네티스에서 어플리케이션을 배포하기 위해 사용되는 대표적인 패키징 툴이다. helm를 이용하면 원하는 어플리케이션을 쿠버네티스에 손쉽게 설치할 수 있다. 그리고 helm-chart는 쿠버네티스 리소스를 하나로 묶은 패키지에 해당하고 이 또한 yaml파일 형식으로 구성돼 있다. 즉 helm으로 차트를 관리하는 목적은 여러 개의 yaml 파일들을 관리하기 쉽게 하기 위한 것이다. 즉 helm을 활용하면 컨테이너 배포 뿐 아니라 어플레케이션을 배포하기 위해 필요한 쿠버네티스 리소스를 모두 패키지 형태로 배포해주는 역할을 한다.
본 글에서는 위와 같은 helm-chart에 대해서 다룬다. helm을 설치하고 활용하는 예제 글은 추후에 다른 글에서 다룰 것이고 이번에는 아래 helm과 관련된 주제들을 다룬다.
(1) helm, helm chart란 무엇인가?
(2) helm의 기능은 어떤게 있는가?
참고로 helm은 버전에 따라 변화가 큰 편이기 때문에 본 글을 기준으로 기본적인 helm의 개념을 알아가는 정도로 생각하고 읽는 것을 추천한다.
1) helm, helm chart란 무엇인가?
helm은 쿠버네티스를 위한 패키지 매니저다. 패키지 매니저가 뭔지 모르겠는 독자를 위해 패키지 매니저 예시를 조금 들어보겠다.
(1) ubuntu의 apt
(2) Mac의 brew
(3) Node의 npm
위와 같이 패키지를 설치, 업데이트, 수정, 삭제하는 작업을 편리하고 안전하게 수행하기 위해 사용되는 툴이다. 그리고 helm은 쿠버네티스용 패키지 매니저라고 생각하면 되겠다. 그리고 여기서 패키지는 쿠버네티스 리소스를 하나로 묶은 helm chart다. 여기서 말하는 helm chart란 YAML파일의 묶음(패키지)으로, 이 묶음을 public 혹은 private registry에 push해두고, helm 명령어를 활용해 helm chart를 설치하여 쿠버네티스 리소스를 배포할 수 있다.
쿠버네티스에서 어플리케이션을 배포하기 위해 필요한 object(리소스)들을 예로 들어보면 아래가 있다.
service: pod를 외부 IP를 노출시키기 위해 서비스가 필요하다.deployment: pod를 관리하기 위해 deployment가 필요하다.statefulset: database와 같은 stateful application을 위해 필요하다configMap: external configuration 설정을 위해 필요하다secret: credential과 같은 secret한 정보들을 저장하기 위해 필요하다.
그리고 위와 같은 object들을 생성하기 위해서는 각각 마다 yaml을 생성해주어야 한다. 그리고 위와 같은 yaml파일들을 사전에 정의해두고 패키징 한 뒤에 추후에 쿠버네티스 클러스터에 어플리케이션을 배포할 때 위와 같은 object들을 쉽게 배포하기 위해 패키징한게 바로 helm-chart다.
자 다시 한번 강조하자면 helm chart는 쿠버네티스 리소스를 정의해둔 Yaml파일들의 묶음이다. 실제로 활용해볼 수 있는 helm chart들을 검색해보면 database앱인 mongodb, elasticsearch, monitoring app인 prometheus와 같은 앱들을 쉽게 쿠버네티스 클러스터에 배포할 수 있게 해주는 helm chart들이 public hub에 이미 push돼 있다. 유저들은 그냥 받아서 사용하기만 하면 위와 같은 앱들을 쉽게 쿠버네티스에 배포할 수 있다. 추후 포스팅에서 helm-chart를 설치해서 어플리케이션을 배포하는 예제를 다뤄보도록 하겠다.
2) helm의 기능은 어떤게 있는가?
2-1) template engine
여러개의 microservice들을 개발하고 있다고 해보자. (예: auth server, admin server, database, api servers) 실제로 필자가 현재 근무하고 있는 groundX에서는 25-30개의 microservice들이 쿠버네티스에 배포되어있다. 그리고 위와 같은 microservice들을 배포하는데 사용되는 yaml파일들은 거의 똑같은 구조로 작성되어 리소스들을 정의하고 있다.
만약 helm이 없었다면 각 microservice마다 필요한 object들에 대한 yaml파일들을 개별로 관리해야 한다. 하지만 helm을 사용하면, common한 yaml 구조를 정의해두고(chart를 만들고), 그 구조에 들어가야 하는 value들만 수정해가며 여러개의 microservice들을 배포할 때 재사용할 수 있다.
예를 들어보겠다.
원래 아래처럼 각 microservice마다 아래처럼 yaml파일들을 정의해야 한다면
helm을 사용하면 아래처럼 공통적인 틀을 다루는 template을 만들어두고, 그 안에 값들만 override되게 values.yaml파일을 작성해두어, 각 microservice마다 다른 정보를 입력해 하나의 공통된 차트를 활용할 수 있다. 따라서 여러 개의 yaml파일을 만들지 않고, 1개의 yaml파일만으로 여러개의 microservice들을 관리할 수 있게 되는 것이다.
위와 같은 방식을 value injection이라고 표현한다.
value injection은 values.yaml파일을 만들어서 template에 override하는 방법도 있고, helm으로 실행할 때 --set flag를 cli와 함께 사용할 수도 있다.
yaml을 사용하는 경우
helm install -f myvalues.yaml -f override.yaml myredis ./redis--set flag를 사용하는 경우
helm install --set name=prod myredis ./redis2-2) 하나의 차트로 여러 환경에 손쉽게 배포 가능
microservice들을 구현해두고, 각각 다른 환경에 배포해야 하는 경우에는 하나의 helm-chart를 작성해두면 여러 환경에 배포할 수 있다. 그림 예시는 아래와 같다.
위 그림에 보이는 것처럼, 하나의 차트를 구성해두고 그 안의 values들만 바꿔주면, 손쉽게 각기 다른 환경들에 동일한 어플리케이션을 배포할 수 있다.
2-3) release management & 사라진 Tiller
helm 버전 2와 버전3의 주요 차이점은 Tiller가 삭제됐다는 점이다. releasev3부터 사라진 Tiller를 굳이 언급하는 이유는 release managment의 내용에 대해 다루기 위해서다. Tiller는 helm chart들의 통합 관리와 설치를 위해 활용되는 특별한 pod다. Tiller는 기존에 설치한 Chart들을 통합 관리해주고, 이에 따라 아래와 같은 release managment 기능들을 Tiller를 통해 실행할 수 있도록 해주었다.
아래처럼 Tiller에서 chart 실행과 관련된 history를 보관해두고 있기 때문에,
helm history {RELEASE NAME} -n {NAMESPACE NAME}
#e.g.
helm history wordpress-01 -n richet-dev
위 커맨드로 배포돼왔던 release들의 history를 확인한 뒤
아래처럼 이전의 버전으로 rollback할 수 있다.
helm rollback {RELEASE NAME} {REVISION NUMBER}
#e.g.
helm rollback wordpress-01 1 -n richet-dev
뿐만 아니라 helm upgrade명령어를 통해 helm 차트 변동사항을 release에 적용할 수 있다.
- values.yaml 필드 키 또는 default 값 수정
- helm 차트 내용 수정(Chart.yaml, 템플릿 등)
예를 들어 myvalues.yaml파일의 내용을 변경한다고 했을 때, 기존에 배포된 release에 변경 내용을 적용하고 싶으면 helm upgrade명령어로 적용할 수 있다.
helm upgrade {RELEASE NAME} <차트경로> -n {NAMESPACE NAME}
#e.g.
helm upgrade wordpress-01 --values myvalues.yaml -n richet-dev
참고로 위와 같이 upgrade하게 되면 Release 횟수를 의미하는 REVISON값이 +1이 된다.
하지만 버전 2의 Tiller를 사용하는 방식은 쿠버네티스 버전 1.6부터 적용된 RBAC을 위해 Tiller에 cluster-admin권한을 부여했고, Tiller가 CREATE, UPDATE, DELETE등 너무 많은 권한을 가지게 되면서 보안문제가 발생했다. 따라서 이런 문제를 방지하기 위해 버전 3부터는 Tiller가 아닌 쿠버네티스 API를 통해 설치된 Helm Chart들을 쿠버네티스 그 자체에 저장한다. 또한 Chart를 설치하는 RBAC권한은 사용자가 사용한 kubeconfig를 활용하는 방식으로 수정했다. 따라서 Helm작동 구조가 직관적으로 변할 뿐 아니라, Cluster 관리자들은 Release가 클러스터에 기록되는 동안 유저의 접근 권한을 제한할 수 있고, 나머지의 Helm 기능은 전과 같이 사용하면서 production 환경에서도 더 안심하고 Helm을 사용할 수 있게 됐다.
자 이렇게 쿠버네티스를 좀 더 편리하게 사용할 수 있게 해주는 helm의 개념에 대해서 다루어보았다.
이제는 helm 차트의 구조를 알아보고, 직접 helm을 활용해 쿠버네티스 클러스터에 어플리케이션을 배포해볼 차례다. 물론 지금 포스팅에서 이어서 다루진 않고, 다음 글에서 다뤄보도록 하겠다. 그때까지 helm에 대한 좋은 글들을 더 읽어보고 개념을 익혀보도록 하자!
참고자료
https://nearhome.tistory.com/88
https://kycfeel.github.io/2019/12/25/Helm-v2-에서-v3-로-마이그레이션-하기/
https://medium.com/codex/helm-charts-for-kubernetes-developers-dce5719d4c8c
https://coding-start.tistory.com/310
https://devocean.sk.com/blog/techBoardDetail.do?ID=163262
