Helm을 왜 사용해야하는지와 개념에 대해 간단하게 알아보겠습니다.
Helm 왜 써야 할까 ?
저희는 Kubernetes 환경에 원하는 Container App을 배포하기 위해서는 yaml 파일을 만들고 그 yaml 파일을 kubectl 명령어를 통해서 생성해줘야 합니다. 하지만 아래와 같이 형태는 동일하게 가져가지만 배포 환경에 따라 특정 인자들이 달라져야 하는 상황이 올 수 있습니다.
(이미지 출처: 이론과 실습 - 대세는 쿠버네티스 Helm편)
위와 같이 yaml파일은 정적파일이며 많은 리소스에 대해서 매번 yaml파일을 유지보수하기가 까다롭습니다. 리소스가 많아짐에 따라 동일한 형태를 같은 환경에 대해 동적으로 생성해주는 Tool이 필요하게 됩니다. 이 Tool이 Helm입니다.
(이미지 출처: 이론과 실습 - 대세는 쿠버네티스 Helm편)
예를 들어 위 이미지를 보면 dev환경과 qa 환경, App1, 2 2개, Pod의 종류는 Service, Pod, ConfigMap가 있습니다.
이를 위해 관리해야하는 yaml의 종류는 총 2 x 2 x 3 = 12개가 됩니다.
그렇게 되면 위에 보이는 것과 변수를 관리해주어야 하고 명령어도 12번을 사용해야하며 이는 곧 유지보수 비용이 늘어나게 됨을 의미합니다.
(이미지 출처: 이론과 실습 - 대세는 쿠버네티스 Helm편)
하지만 Helm을 사용하게 되면 위와 같이 명령어를 4번만 사용하면 됩니다.
중요한 것은 안에 내용이 변수와 같이 동적으로 추가가 되어 유지보수하기게 매우 편리해진다는 점입니다.
(이미지 출처: 이론과 실습 - 대세는 쿠버네티스 Helm편)
만약 app이 하나 더 추가가 된다면 yaml 6개를 추가로 만들필요 없이 명령어만 수정해서 생성해주면 된다는 점입니다.
(이미지 출처: 이론과 실습 - 대세는 쿠버네티스 Helm편)
그리고 Helm을 사용하면 OpenSource를 매우 편리하게 사용할 수 있습니다.
현재 Kubernetes 환경에서 동작할 수 있는 OpenSource들이 매우 많아지고 있습니다. 앞으로 이러한 흐름은 계속 유지될 것 같아요.
Helm Plugins에는 매우 다양한 오픈소스들이 들어가있으며 여기서 저희가 원하는 내용들에 대해서만 Kubernetes 오브젝트로 배포를 할 수 있습니다.
각 OpenSouce 회사들은 개발자가 어떤 내용들이 필요할지 모르기 때문에 그에 대해 Module화를 해놓으며 저희는 필요한 내용들을 명령어로 편하게 Kubernetes 오브젝트로 배포를 할 수 있습니다.
그래서 Helm을 사용하는 2가지 큰 이유는
- 내 업무 환경별로 배포 관리를 편하게 하기 위해서
- 오픈소스를 쉽게 설치하기 위해서
Helm 동작원리
Helm 이 동작하는 원리에 대해 간단하게 알아보겠습니다.
Helm과 kubectl툴은 유사하게 동작합니다.
kubectl의 동작을 간단하게 설명해보겠습니다.
(이미지 출처: 이론과 실습 - 대세는 쿠버네티스 Helm편)
kubectl 툴은 사용자에게 shell 명령어를 받아서 kube-api server에게 pod를 생성해달라는 api를 요청합니다. 그럼 이 kubectl은 어떻게 kube-apiserver와 통신을 할까요 ?
저희가 kubernetes를 설치를 하면 /etc/kubernetes의 admin.conf 파일이 생성됩니다. 이 파일에는 kube-apiserver와 통신할 수 있는 ip 인증서가 들어있습니다. 그리고 kubectl 툴을 설치할 때 이 admin.conf 파일을 /root/.kube 폴더에 config라는 이름으로 복사하게 됩니다. 그러면 kubectl은 기본적으로 이 path에 있는 파일을 읽어서 통신을 할 수 있게 됩니다. 그래서 사용자가 root로 접속하여 kubectl 명령어를 사용했을 때 kubernetes와 통신을 할 수 있었던 것입니다.
그래서 외부 pc에서도 이 config 파일만 있으면 해당 kube-apiserver에 명령어를 입력할 수 있습니다.
(이미지 출처: 이론과 실습 - 대세는 쿠버네티스 Helm편)
Helm도 동일하게 동작합니다. Helm을 설치하면 Helm도 /root/.kube path에 있는 config 파일의 내용을 읽어와서 kube-apiserver로 통신을 하는 것 입니다.
Helm의 전체적인 구성을 간략하게 살펴보면
Helm Site는 Helm 공식문서, 커뮤니티, 블로그 등이 있는 홈페이지입니다.
Artifact Hub는 다양한 공개된 Helm 차트를 발견하고 검색하는 곳입니다.
Helm Chart Repository는 Helm 차트를 저장하고 배포하기 위한 저장소입니다.
(이미지 출처: 이론과 실습 - 대세는 쿠버네티스 Helm편)
사용자가 helm을 통해 repo add를 하게 되면 Helm Chart Repository에서 해당 Repository에 대한 내용을 Kubernetes에 추가하게 됩니다. 그리고 install을 하게 되면 Cluster에 service와 pod가 생성이 되며 배포가 진행됩니다. 이때 container의 이미지의 이름은 따로 명시해주어야 합니다.
아래 흐름으로 다시 이해해보면
- 사용할 내용을 Artifact Hub 에서 검색
- 추가할 Chart Repository를 확인
- helm repo add [name][url]을 통해 repository를 추가
- helm install [name][chart] [flags]를 통해 배포 진행
- service, pod 생성
출처
