[쿠어클#12] Helm과 Kustomize 비교하며 사용하기 (1/2)

Sprint2 추가 강의가 업로드 됐어요! 이번 강의는 Helm과 Kustomize 비교하며 사용하기라는 주제 입니다.

지금까지 kubectl을 잘 쓰고 있었는데, Helm이랑 Kustomize를 꼭 써야 되나요? 라고 질문을 하시는 분들께 저는 무조건 그래야 한다고 말씀을 드려요. 왜 그런지는 아래 그림을 보면서 말씀 드릴께요!

먼저 이렇게 배포툴(Jenkins, argo)이 있어요. 지금까지 젠킨스를 배포툴로 써왔는 데, 다음시간에는 argoCD를 배포툴로 쓸꺼고요. 그리고 이 배포툴에서 kubectl을 써서 쿠버네티스로 배포를 해왔었죠.

이 kubectl은 단지 커맨드라인 도구인 CLI인 거고, 이 명령중에서 create나 apply 명령으로 쿠버네티스에 자원을 생성했었는데, 그건 그냥 CLI 명령중에 하나를 사용한거지, 배포를 위한 부가 기능은 없어요. 그리고 실무에서는 이 kubectl을 배포한 쿠버네티스 자원을 조회하거나 급한 수정을 해야 될 때 주로 쓰지, 정작 자원을 생성할 때는 잘 쓰지 않습니다.

실제 자원 생성은 주로 Helm이랑 Kustomize를 통해서 해요. kubectl이랑 같은 위치로 들어가고요. 얘네들을 패키지 매니저라고 부릅니다. 똑같은 구조처럼 보이지만 차이가 있는데요.

결국 kube-apiserver한테는 똑같이 6번에 API를 날려주지만, 작업자의 입장에서는 이 yaml 파일들을 명령어 한번으로 배포할 수 있게 해줘요. 어차피 App 하나를 구성하는데 여러 yaml 파일들이 사용되기 때문에, 이 yaml 파일들을 패키지 형태로 관리 할 수 있게 필요하기도 했거든요. 그런 니즈에 잘 마춰 졌고, 그렇기 때문에 이번 수업을 통해서 패키지 매니저인 Helm과 Kustomize에 대해서 잘 알고 있어야 합니다.

Helm vs Kustomize 비교 - 최종 정리

공통점을 말씀드리면, 바로 사용 목적입니다. 배포를 하기 위해 만들어야 되는 yaml 파일들에 대해서 중복관리하는 걸 최소화 하기 위한 거죠. 이전 시간에 한번 말씀드릴 적 있죠? 이젠 마이크로 서비스 아키텍처를 많이 쓰다 보니까, App을 잘게 쪼개게 되고, 그래서 App 종류가 많아졌어요. 그리고 기존부터 그랬던 부분인 다양한 환경에 배포를 해야되서 그렇고요.

그리고 두 번째 공통점으로 이 두 패키지 매니저는 다양한 배포툴에서 지원을 합니다. 지원한다는 의미는 이 툴 에서 helm이나 Kustomize를 더 편하게 쓸 수 있도록 부가적인 기능들을 제공한다는 거죠.

이제 다음으로 차이점인데, 지금부터 내용은 그냥 그렇구나 정도로만 알고 넘어가 주세요. 해보지 않은건 크게 와닿지가 않거든요. 이걸 외울 필요도 없고요. 그냥 이번 강의를 쭉 듣다보면 자연스럽게 알게되는 내용들이기도 해요.

먼저 배포 편의기능이 Helm은 200개 정도 되는 거에 비해 kustomize는 10개 정도 밖에 안됩니다. 딱 그렇다는게 아니라 상대적인 비교예요. 근데 “그래서 Helm이 더 좋아요”라고 말할려는 게 아니라, Kustomize는 심플 쓸 수 있다는 장점이 있는 거거든요. “지금 파이프라인을 구축하는데 많은 기능이 필요 없고 빨리 공부해서 구축을 해야 되” 라고 했을 때는 kustomize를 써야 되는 건 거죠.

그리고 다음으로 각각에 패키지 매니저를 이용해서 하나에 패키지를 만들어 었을 때, 그 패키지를 활용 할 수 있는 범위인데 (이건 제가 권고 사항이고요) Helm은 한 패키지를 만들어서 마이크로 서비스 목적이랑 이 다양한 환경으로 배포까지 하는데까지 사용 해도 좋아요. 패키지를 구성할 때 이 두 목적을 모두 챙기면서 만들 수 있다는 거고요.

Kustomize는 OR이에요. 둘 중 한 목적만 선택해서 패키지를 구성하는게 좋습니다. 불가능 한건 아닌데, 활용 범위를 늘릴 수록 점점 패키지 내부에 파일량이 많아지는 구조라서 그래요. 그럼 또 이 파일들을 관리하는 게 복잡해지기 시작합니다.

다음으로 사용 목적입니다. Kustomize는 딱 내 프로젝트에 App을 패키지화 시켜서 배포하는 목적으로 쓰이고, Helm은 그거 받고, 기업용 제품을 패키지 하는데 쓰여요. 대부분에 오픈소스들은 여러가지 설치 방법들을 제공하잖아요? 그중에 하나로 꼭 들어가는 설치 방법이 Helm인 거죠. 보통 오픈소스를 설치하는 사람들이 각자 환경이 다르고, 설치하고 싶은 구성이 조금씩 다를 수가 있잖아요? Helm은 그런 상황에 따라서 각자, 자신의 환경에 따라 조절할 수 있도록 패키지를 만들 수 있습니다.

그래서 유즈케이스를 보면, Helm은 App이 5개 이상있고, 주로 대형 프로젝트를 할 때 많이 쓰고요. Kustomize는 App 종류가 5개 미만에 간단한 프로젝트를 할 때 쓴다고 볼 수가 있어요.

Helm vs Kustomize 비교 - 설치 구성

kustomize를 보면, 자체적으로 kustomize를 관리하는 사이트가 있고, 다운을 받거나 Release를 관리 하는 Github도 있어요. 근데 이게 1.14버전부터는 Kubectl에 통합이 됐거든요. 그래서 현재 우리가 쿠버네티스 레파지토리에서 kubectl을 받아서 설치했는데, 현재 kubectl는 1.27버전 이기 때문에 kustomize가 포함이 돼있고 바로 사용할 수 있다고 보시면 됩니다.

Helm도 마찬가지로 Helm 사이트가 있고, Github에서 Helm을 다운 받아서 설치 합니다. 그리고 kubectl이랑 마찬가지로 이렇게 인증서가 있어야지 kube-apiserver로 통신을 할 수 가 있는 거고요.

그래서 이렇게 설치되는 방식은 좀 다르지만, 구성은 결국 비슷하죠?

이렇게 패키지를 만들면 Helm은 helm으로 시작하는 명령어를 날려서 API가 보내지는 거고, Kustomize는 kubectl에 포함이 됐기 때문에 kubectl 명령에 -k가 kustomize를 쓴다는 옵션이예요.

그래서 여기까지보면 둘 다 구성이 비슷해 보일 수는 있는데..

여기서 Helm은 좀더 큰 생태계를 가지고 있어요. Artifact Hub라고 해서 Helm 패키지들을 저장하는 저장소가 있습니다.

Github나 DockerHub 같은 곳이라고 보면 되는데, 이렇게 많은 오픈소스 기업들에서 자신들에 제품들을 Helm 패키지로 설치할 수 있도록 패키지들을 올려놓습니다.

그래서 이중에서 설치하고 싶은 게 있으면, Helm 명령어로 필요한 패키지를 다운 받을 수 있는 거죠. 그래서 이렇게 패키지가 받아지고, 내 환경에 맞게 좀 수정해야 되는데, 그건 이걸 올려놓은 기업에서 설치 가이드도 자세히 제공하고 있고요.

그래서 이렇게 더 큰 생태계가 있으니까 그만큼 Helm에서 제공해줘야 하는 기능이 많을 수 밖에 없어 보이죠?

그럼 이번 블로그는 여기까지고요, 해당 강의에서는 실습과 더불어 추가적으로 아래 내용들에 대해서 더 다룹니다 😀