kustomize vs helm

현재 관리하는 클러스터 내 오브젝트 중에는 모니터링을 위한 loki, prometheus, grafana가 있고 데이터베이스로는 redis, kafka, rabbitmq, 매니페스트 암호화 및 복호화에 사용하는 sealed-secrets, 개발환경에서 latest 이미지 태그를 고정해두고 digest로 최신 이미지로 업데이트를 도와주는 keel, 그리고 배포에 사용하는 argocd 등이 있다. 데이터베이스의 경우 클러스터로 구성하거나 레플리카 구조로 만들기 때문에 직접 helm 차트를 구성하거나 manifest를 만들게 된다면 상당한 시간이 소요되기 때문에 이미 잘 만들어져 있는 helm 차트를 참고해서 각각의 오브젝트를 생성하고 있다.

하지만 로드밸런서의 경우 클라우드마다 어노테이션등이 조금씩 다르기 때문에 사용중인 클라우드 벤더에 맞춰서 어노테이션 등을 수정해줘야 하므로 helm 차트를 그대로 사용할 수 없다. 그래도 몇몇 helm 차트는 확장성 있게 spec에 여러 옵션이 들어갈 수 있도록 되어있는 경우도 있고 values.yaml에 값만 넣어서 해결가능한 경우도 있지만 그렇지 않은 경우도 있고 공통으로 사용될 수 있게 잘 만들어진 helm 차트는 그만큼 복잡하기도 했다.

그래서 가장 먼저 helm repo를 로컬에 pull 받고나서 values.yaml을 모두 훑어본 뒤에 필요한 값을 잘 넣어서 변경해주고 helm template 명령을 사용해서 output 폴더에 매니페스트로 뽑아준다. 이렇게 뽑아준 매니페스트를 클러스터의 각 오브젝트로 관리해주고 있다. 하지만 각각의 오브젝트들을 yaml 파일로 그대로 관리하기에는 다소 아쉬운 부분이 있었는데 공통적으로 사용하는 부분은 그대로 두되 변경가능한 부분만 바꿔서 사용하고 싶었다.

그래서 이 yaml들을 다시 helm 차트로 만들어서 관리하는 방법도 생각해보았다. 하지만 helm으로 만들어 쉽게 컴포넌트를 구성할 수 있지만 내 환경에 맞게 커스텀하여 차트를 변경하는 것은 까다롭고 차트의 구조를 파악하고 있어야 하며 이는 다소 관리 용이성이 떨어질 수 있으며 기존 템플릿을 변경할 시에 ArgoCD와 연동이 되지 않는 등 새로 helm repo를 추가해야만 하는 복잡성을 느껴 더 간단하게 관리할 수 있는 방법은 없을까 고민하다 kustomize를 발견하였다.

kustomize는 기존 yaml 파일로 관리되며 base yaml 파일을 정의하고 이 base yaml 파일을 상속받아 일부 리소스를 변경하는 식으로 관리되며 동일한 base에 여러 버전을 관리할 수 있으므로 앞으로 추가로 클러스터를 구성할 때 하나의 컴포넌트를 기준으로 여러 환경에 맞게 관리할 수 있는게 장점으로 보이고 무엇보다 러닝커브가 높지 않아 보였다.

하지만 유의점이 있는데 오버레이 패치를 작성하여 서비스의 포트 번호를 바꾸게 될 경우 포트가 변경되는 것이 아니라 포트가 추가되어버리기 때문에 오버레이가 아니라 추가가 되는 merge가 발생한다고 한다. 이를 미루어보았을 때 서비스의 포트는 배열로 선언되어 있고 이 배열의 리소스가 바뀌게 될 경우는 추가가 되는게 아닐까 하고 생각되어지며 이런 유의점을 잘 생각하여 Kustomize를 작성할 필요가 있다.