Kustomize와 Helm의 차이점은 무엇인가요?

Kubernetes 애플리케이션을 관리하고 배포할 때 Kustomize와 Helm이라는 두 가지 도구가 꾸준히 돋보입니다. 둘 다 Kubernetes 배포의 복잡성을 단순화하지만 동일한 문제를 해결하기 위해 근본적으로 다른 접근 방식을 취합니다.

Helm 은 Kubernetes를 위한 패키지 관리자로, 애플리케이션에 필요한 모든 것을 Helm 차트라는 단일 재사용 가능 패키지로 묶습니다. Kubernetes 네이티브 도구인 Kustomize는 패치 및 오버레이를 사용하여 템플릿 언어를 사용해야 하는 기본 구성을 수정하는 선언적 접근 방식을 사용합니다.

이러한 도구 중 하나를 선택하는 것은 단순한 기술적 선호도가 아니라 개발 팀의 생산성, 운영 비용 및 애플리케이션을 안정적으로 확장할 수 있는 능력에 직접적인 영향을 미칩니다. 많은 조직이 두 도구를 함께 사용함으로써 상당한 가치를 발견하지만, 효과적이고 확장 가능한 Kubernetes 배포 및 관리 전략을 구축하려면 각 접근 방식을 선택해야 하는 시기와 이유를 이해하는 것이 필수적입니다.

Helm과 Kustomize를 살펴보기 전에 최신 클라우드 네이티브 애플리케이션의 기반이 되는 컨테이너화를 이해하면 도움이 됩니다.

컨테이너화는 코드, 라이브러리, 구성 등 실행에 필요한 모든 것이 포함된 애플리케이션을 컨테이너라는 경량의 이식 가능한 단위로 패키징하며, 일반적으로 Linux 기반 시스템에서 실행됩니다. 이러한 프로세스를 통해 개발자 노트북부터 프로덕션 클라우드 인프라에 이르기까지 다양한 환경에서 소프트웨어를 일관되게 실행할 수 있습니다.

k8s 또는 kube라고도 하는 Kubernetes는 여러 머신 클러스터에서 배포, 확장 및 리소스 관리를 자동화하여 컨테이너(일반적으로 Docker 기반)를 대규모로 오케스트레이션합니다.

클라우드 네이티브 컴퓨팅 재단(CNCF)의 2024년 설문조사에 따르면 설문조사에 참여한 조직 중 클라우드 네이티브 채택률이 89%로 사상 최고치를 기록했으며, 조직의 93%가 Kubernetes를 사용, 파일럿 또는 평가하고 있습니다.¹

조직이 단순한 애플리케이션에서 복잡한 멀티 서비스 아키텍처로 전환함에 따라 Kubernetes 배포를 관리하는 데 필요한 구성 파일이 점점 더 복잡해지고 있습니다. 일반적인 엔터프라이즈 애플리케이션은 수십 개의 구성 파일을 필요로 하며, 각 구성 파일은 개발, 스테이징 및 프로덕션 등 다양한 환경에 대한 사용자 지정이 필요합니다.

 이러한 복잡성으로 인해 다음과 같은 여러 비즈니스 과제에 직면하게 됩니다.

• 환경 전반에서 일관성 유지의 어려움

• 더 높은 운영 비용

• 배포 자동화의 부재로 인한 수동 오류 발생

• 신기능 출시 지연

Kustomize와 Helm은 모두 이러한 문제를 해결하기 위해 만들어졌지만 접근 방식은 완전히 다릅니다. Helm은 Deis(이후 Microsoft에 인수됨)가 Kubernetes 애플리케이션 관리를 간소화하도록 설계된 최초의 도구 중 하나로 이를 도입하면서 시장에 처음 진출했습니다. 이 프로젝트는 2018년 Deis가 CNCF에 기증하면서 더욱 신뢰를 얻었고 2020년에 완전한 CNCF 졸업 상태를 달성했습니다.

한편, Kubernetes는 2019년 Kubernetes 1.14의 출시와 함께 Kustomize를 kubectl 명령줄 인터페이스(CLI)에 직접 통합함으로써 다른 길을 택했습니다.

Kustomize는 선언적 구성 관리 접근 방식을 사용합니다. DevOps와 다른 팀은 특정 상태를 달성하는 방법을 스크립팅하는 대신 최종 구성이 어떻게 생겼으면 하는지를 설명합니다. 

이 도구는 '기본 및 오버레이' 방법론을 사용합니다. 팀은 애플리케이션의 핵심 특성을 캡처하는 표준 기본 구성으로 유지 관리합니다. 그런 다음 각 환경 또는 변형에 대해 해당 특정 컨텍스트에 필요한 차이점만 지정하는 오버레이를 만듭니다.

표준 리소스 요구 사항과 기본 네트워킹 설정이 있는 웹 애플리케이션을 정의하는 기본 구성을 생각해 보세요. 개발 오버레이는 리소스 제한과 복제본을 줄여 비용을 절감할 수 있으며, 프로덕션 오버레이는 보안 설정을 강화하고 모니터링 구성 요소를 추가할 수 있습니다. Kustomize는 이러한 구성을 병합하여 Kubernetes 리소스의 원하는 상태를 설명하는 최종 배포 Kubernetes 매니페스트(YAML 또는 JSON 파일)를 생성합니다.

Kustomize는 apiVersion과 같은 표준 Kubernetes 필드가 포함되어 있는 네이티브 YAML 매니페스트 파일(예: deployment.yaml)과 직접 연동됩니다. 이 접근 방식은 템플릿 언어가 필요하지 않으므로, 팀이 표준 Kustomize YAML 구성 이상의 코딩 구문을 배우지 않고도 더 쉽게 채택할 수 있습니다. 따라서 팀은 이미 알고 있는 익숙한 Kubernetes YAML 구문을 사용하여 작업하면서 정교한 구성 관리를 신속하게 구현할 수 있습니다.

시장에서 가장 인기 있는 Kubernetes 패키지 관리자인 Helm은 기본적으로 Kubernetes 애플리케이션용 앱 스토어 역할을 하며, 사전 패키징된 애플리케이션을 쉽게 관리하고 설치할 수 있습니다. 최근 CNCF 설문 조사에 따르면, Helm은 Kubernetes를 운영하는 조직에서 75%의 채택률을 기록하며 선호하는 Kubernetes 패키지 관리자 1위를 차지했습니다.²

Helm은 애플리케이션을 팀이 단일 단위로 설치, 업그레이드 및 관리할 수 있는 사전 구성된 Kubernetes 리소스 모음인 'Helm 차트'로 패키징합니다. 각 차트에는 구성 파일(예: chart.yaml)이 포함되어 있으며 Go 템플릿을 사용하여 입력 값을 기반으로 동적 구성을 활성화합니다.

Helm의 장점은 템플릿 엔진 및 패키지 관리 기능에 있습니다. Helm을 사용하면 유사한 구성의 여러 버전을 유지하는 대신 팀에서 자리 표시자가 있는 차트를 만들고 별도의 값 파일(예: values.yaml)을 사용할 수 있습니다 배포하는 동안 해당 자리 표시자를 채울 수 있습니다. 팀은 Kubernetes 클러스터에 적용하기 전에 helm 템플릿을 사용하여 최종 렌더링된 구성을 미리 볼 수 있습니다.  

템플릿 외에도 Helm은 배포 롤백, 릴리스 관리, 배포 기록 추적 등의 포괄적인 라이프사이클 관리 기능을 제공합니다. 이러한 기능으로 인해 Helm은 오케스트레이션 및 롤백 기능이 중요한 복잡한 애플리케이션 포트폴리오를 관리하는 조직에 유용합니다.

예를 들어 전자 상거래 회사는 온라인 스토어에 차트 하나를 사용하면서 별도의 구성 파일을 만들지 않고도 다양한 환경(테스트용 서버 수, 운영 서버 수)에 맞게 차트를 사용자 지정할 수 있습니다.

이러한 차트를 배포하기 위해 팀은 Kubernetes 애플리케이션 프로그래밍 인터페이스(API)를 통해 대상 Kubernetes 클러스터에 모든 리소스를 자동으로 적용하는 Helm 설치를 사용합니다. Helm은 버전 관리 및 종속성 관리를 자동으로 처리하여 일관되고 안정적인 배포를 보장합니다

Kustomize와 Helm 중 어떤 것을 선택할지는 특정 배포 과제와 비즈니스 목표에 따라 달라집니다. 동일한 애플리케이션을 다양한 환경에 맞게 사용자 지정하는 조직은 일반적으로 Kustomize를 통해 가장 큰 이점을 누릴 수 있습니다. 다수의 애플리케이션을 관리하거나 정교한 배포 제어가 필요한 사용자에게는 Helm이 더 적합합니다.

다음 섹션에서는 각 솔루션의 가장 적합한 사용 시기에 대해 자세히 살펴봅니다.

대부분의 조직은 미묘하지만 중요한 차이가 있는 개발, 스테이징 및 프로덕션 환경에 동일한 애플리케이션을 배포해야 합니다. Kustomize는 팀이 환경별 수정 사항을 적용하면서 신뢰할 수 있는 단일 소스를 유지할 수 있도록 지원하기 때문에 이러한 시나리오에서 탁월합니다.

개발 환경에서는 비용 절감을 위해 리소스 제한을 줄여야 할 수 있는 반면, 프로덕션 환경에서는 향상된 보안 설정, 다양한 ConfigMap 및 모니터링 구성 요소가 필요합니다. Kustomize를 사용하면 조직에서 전체 구성 파일을 복제하지 않고도 이러한 차이점을 정의할 수 있습니다.

배포 상황에 따라 다른 보안 정책 또는 규정 준수 조치가 필요한 경우가 많습니다. Kustomize를 사용하면 팀이 완전히 별도의 구성 집합을 만들지 않고도 이러한 요구 사항을 기본 구성에 계층화할 수 있습니다. 이 기능은 다양한 규제 요구 사항을 가진 여러 지역 또는 산업에 걸쳐 운영되는 조직에 유용합니다.

대규모 애플리케이션 포트폴리오에 구성 변경 사항을 롤아웃할 때 팀은 Kustomize를 사용하여 전체 구성 구조를 중단하지 않고도 점진적으로 수정할 수 있습니다. 이러한 접근 방식을 사용하면 위험을 줄이고 잘못된 구성이나 배포 실패와 같은 문제를 더 쉽게 식별하고 해결할 수 있습니다.

Helm의 주요 장점 중 하나는 기능으로, 특히 플랫폼을 구축하거나 팀 간에 애플리케이션 배포를 표준화하려는 조직에 도움이 됩니다.

팀은 모범 사례와 조직 표준을 캡처하는 재사용 가능한 차트를 만들고 전사적으로 배포할 수 있습니다.

다단계 롤아웃, 종속성 관리 및 롤백 기능 같은 정교한 배포 오케스트레이션이 필요한 애플리케이션은 Helm의 릴리스 관리 기능에 매우 적합합니다. 문제가 발생하면 Helm은 즉시 이전 작업 버전으로 되돌릴 수 있으므로, 사용자에게 미치는 영향이 줄어듭니다.

Helm의 광범위한 차트 저장소(chart repo)는 널리 사용되는 오픈 소스 애플리케이션 또는 공급업체 솔루션을 통합할 때 구현 시간을 크게 단축할 수 있는 사전 빌드된 패키지를 제공합니다.

팀은 구성을 처음부터 구축하기보다는, 데이터베이스, 모니터링 시스템, 지속적 통합 및 지속적 배포(CI/CD) 파이프라인, 기타 표준 IT 인프라 구성 요소를 위한 커뮤니티 관리 차트를 활용할 수 있습니다.

SaaS 플랫폼은 종종 Helm을 사용하여 고객별 애플리케이션 배포를 관리하고, 동일한 애플리케이션을 서로 다른 구성으로 별도의 네임스페이스에 여러 번 배포합니다. 이러한 접근 방식은 멀티테넌트 아키텍처에 필요한 격리 및 사용자 정의를 제공합니다.

Kustomize는 Kubernetes 구성 관리에 다음과 같은 여러 가지 이점을 제공합니다.

조직은 이러한 이점을 위해 Helm을 선택합니다.

많은 조직은 Kustomize와 Helm을 경쟁 솔루션으로 여기기보다는, 두 도구를 함께 사용하는 것에서 가치를 발견합니다. 이러한 하이브리드 접근 방식은 각 도구의 장점을 활용하면서 제약 사항을 완화합니다.

다음은 몇 가지 인기 있는 사용 사례입니다.

• 초기 배포 및 환경 사용자 지정

• 사용자 지정 구성을 사용하는 타사 애플리케이션

• 다중 팀 환경

일반적인 공동 사용 패턴에는 초기 애플리케이션 패키징 및 배포를 위해 Helm을 구현한 다음 Kustomize를 사용하여 환경별 사용자 지정을 적용하는 것이 포함됩니다. 이 접근 방식은 Kustomize의 단순성과 투명성을 유지하면서도 Helm의 패키지 관리 및 릴리스 기능의 이점을 제공하여 지속적인 구성 관리를 가능하게 합니다.

예를 들어, 조직은 Helm 차트를 사용하여 모든 종속성이 포함된 마이크로서비스 애플리케이션을 배포할 수 있습니다. 다음 단계는 Kustomize 오버레이를 사용하여 프로덕션에 대한 보안 정책을 추가하거나 스테이징을 위한 다양한 Kubernetes Ingress 규칙을 구성하는 것입니다.

조직은 Helm의 방대한 차트 저장소에서 타사 애플리케이션을 배포하는 경우에는 Helm을 사용할 때가 많고, 구성 관리를 보다 직접적으로 제어하고자 하려는 경우에는 Kustomize를 사용자 지정 애플리케이션에 사용합니다.

이 조합을 통해 팀은 모니터링 시스템이나 메시지 대기열과 같은 인기 있는 도구에 대해 커뮤니티에서 유지 관리하는 차트를 사용하는 동시에 독점 애플리케이션에 대한 완전한 제어를 유지할 수 있습니다.

여러 개발 팀이 있는 대규모 조직에서 플랫폼 팀은 조직의 모범 사례 및 규정 준수 요구 사항이 포함된 표준화된 Helm 차트를 만드는 경우가 많습니다. 이러한 차트는 Terraform과 같은 코드형 인프라(IaC) 도구와 함께 작동하여 전체 배포 파이프라인을 관리합니다.

그런 다음 개별 개발 팀은 Kustomize를 사용하여 기본 차트를 수정하지 않고 특정 애플리케이션 및 환경에 맞게 이러한 차트를 사용자 지정합니다. 이러한 접근 방식은 자동화된 배포 워크플로를 위해 ArgoCD와 같은 GitOps 도구와 원활하게 통합되는 명확한 분리 구조를 만듭니다.

효과적인 Kubernetes 구성 관리를 위해서는 진화하는 애플리케이션 요구 사항에 적응하는 유연한 전략이 필요합니다.

Helm과 Kustomize의 차이점을 이해하고 효과적으로 통합하는 방법을 알면 복잡성을 줄이고 일관성을 유지할 수 있습니다. 이러한 전략적 조합은 궁극적으로 유지 관리가 가능하고 확장 가능한 Kubernetes 환경으로 이어집니다.