Helm vs Terraform: Kubernetes 관리를 위한 올바른 도구 선택하기

컨테이너화 채택이 증가하면서 Kubernetes(K8s 또는 kube) 클러스터를 효율적으로 관리, 스케줄링, 제어해야 할 필요성이 대두되었습니다. 시장은 K8s 환경과 인터페이스하기 위한 다양한 도구를 제공하지만, Helm과 Terraform보다 더 많은 기능을 제공하는 옵션은 많지 않습니다.

이 기사는 Helm과 Terraform의 정면 비교입니다. 두 프로비저닝 도구의 장단점을 분석하고, K8s 설정 관리에서의 기능을 설명하며, 개발 팀에 적합한 옵션을 식별하는 데 도움을 줍니다.

Terraform: 주요 기능

Terraform은 팀이 인프라, 플랫폼, 서비스를 관리하고 자동화할 수 있게 해주는 오픈 소스 IaC(Infrastructure as Code) 도구입니다. 이 도구는 코드를 통해 인프라를 구축, 변경, 버전 관리할 수 있게 하여 엔지니어가 빠르고 쉽게 다음을 수행할 수 있게 합니다:

• 가상 머신 및 컨테이너 실행
• 서버 설정
• 보안 체계 및 제어 생성
• 사용자 추가/제거 및 권한 설정
• 클라우드 리소스 관리
• Docker 컨테이너 설치 및 관리

2017년, Terraform의 제작사 HashiCorp는 Kubernetes 프로바이더 출시를 발표했습니다. 그 결과, 필요한 만큼 많은 클라우드 공급업체 전반에서 K8s 클러스터를 관리하는 기능을 얻게 되었습니다.

Terraform은 인프라 프로비저닝 또는 Kubernetes 관리 시 선언적 언어(declarative language)에 의존합니다. 엔지니어는 인프라 설정의 모든 단계를 정의할 필요가 없습니다. 대신 개발자는 설정의 원하는 최종 상태를 제공하고, 도구가 환경을 프로비저닝하는 방법을 계획합니다. 예를 들어, VM, K8s 클러스터, VPC, 특정 방화벽에 대한 인수 세트를 작성할 수 있으며 프로비저닝 지침을 제공하지 않아도 됩니다.

선언적 구성 파일은 팀이 다음을 수행할 수 있게 하여 유용합니다:

• 지침 편집 없이 인프라 변경에 맞춰 파일 쉽게 조정
• 파일을 깔끔하고 간결하게 유지
• 설정 빠르게 편집
• 구성 파일만 보고 현재 구성이 무엇인지 파악

엔지니어가 프로비저닝을 요청하면 terraform plan 명령어가 도구에 기존 설정(또는 첫날 아무것도 없는 상태)을 원하는 인프라를 설정하는 방법과 비교하여 계획하도록 지시합니다. terraform apply 명령어는 클라우드 공급업체의 API를 통해 리소스를 실행합니다.

Terraform은 엔지니어가 CI/CD 파이프라인 전반에서 환경을 빠르게 실행하고 편집할 수 있게 해주기 때문에 데브옵스 팀 사이에서 인기 있는 선택입니다.

Terraform의 주요 기능

• 인프라와 배포를 단일 도구로 관리할 수 있게 하는 Kubernetes 프로바이더
• 선언적 언어 사용
• 인프라를 다른 코드처럼 설명, 처리, 버전 관리할 수 있는 IaC 접근 방식
• 클라우드 공급업체 API와 설정하여 원활하고 효과적이며 안전한 프로비저닝 가능
• 퍼블릭, 인하우스 프라이빗, 하이브리드, 멀티 클라우드 등 모든 클라우드 기반 설정과 작동
• 서버를 변경하는 대신 교체하는 불변 인프라(이 접근 방식은 운영 단순화, 오류/위협/구성 드리프트 감소로 이어짐)
• changesets를 인프라에 자동 적용하여 리소스 절약 및 오류 방지
• 현재 상태와 원하는 상태의 차이를 항상 보여주는 고급 드리프트 감지 기능
• 플러그인 설계로 팀이 설정을 커스터마이징하고 기능 추가 가능
• 도구가 리소스 간 관계를 이해하여 스케줄링에 도움이 되고 버그를 최소화함. 모든 리소스의 그래프 구축 가능

Helm: 주요 기능

Helm은 클러스터에 반복 가능한 앱과 서비스를 배포하기에 이상적인 Kubernetes 패키지 관리자입니다. 이 도구를 사용하면 Helm 차트(Charts)를 통해 앱을 관리할 수 있으며, 이는 K8s 환경 정의, 설치, 업그레이드를 단순화합니다.

Helm 차트는 Kubernetes 매니페스트 파일로 변환되는 파일과 템플릿의 패키지입니다. 차트는 재사용 가능하며 다음의 YAML 기반 템플릿을 포함할 수 있습니다:

• 다양한 배포
• ConfigMaps
• 서비스

또한 의존성으로 차트를 정의하거나 더 많은 유연성을 위해 차트를 중첩할 수 있습니다. 차트 관리는 단일 명령줄 인터페이스(CLI)를 통해 이루어지며, 이는 운영을 단순화하는 기능입니다. 대부분의 차트는 공개되어 있지만, 기업은 종종 독점적인 사내 사용을 위해 맞춤 차트를 작성합니다.

Helm은 클라이언트와 인클러스터 Tiller 서버로 구성된 단순한 아키텍처를 가집니다:

• Helm 클라이언트: 사용자가 Helm 차트로 작업하고 Tiller 서버와 상호작용할 수 있는 CLI 제공. 클라이언트를 통해 차트 설치, 업그레이드, 롤백 등 다양한 작업 수행 가능
• Tiller 서버: 클러스터 내에서 작동하며 K8s API 서버와 상호작용하여 Kubernetes 리소스 설치, 업그레이드, 제거

Helm에는 다음을 포함한 많은 이점이 있습니다:

• 다른 환경에서 K8s 매니페스트 배포 및 관리
• 복잡한 애플리케이션을 함께 패키징
• 여러 오브젝트를 함께 롤백 또는 업그레이드
• 설정 매개변수 빠르게 변경
• 단일 명령으로 여러 환경에 배포

Helm과 그 템플릿 엔진은 K8s 리소스에 의존하는 CI/CD 프로세스에 이상적입니다. 각 마이크로서비스별로 파일을 편집하는 대신, 엔지니어는 표준 청사진을 정의하고 동적 값 자리에 플레이스홀더를 사용할 수 있습니다. 팀은 차트를 생성하고 한 명령어로 다른 클러스터에 동일한 앱을 재배포할 수 있습니다.

Helm의 주요 기능

• 빠른 인프라 프로비저닝과 Kubernetes 리소스 관리를 위한 재사용 가능한 템플릿인 Helm 차트 사용
• 애플리케이션 의존성 처리와 인스턴스 배포를 쉽게 만드는 단순한 클러스터 관리
• 클러스터 내에 설치되는 Tiller 서버로 사용자가 Kubernetes API와 직접 인터페이스 가능
• 연속 릴리스 추적 가능
• 여러 오브젝트를 함께 롤백 또는 업그레이드하는 기능
• 차트의 단순 업그레이드 및 제거 프로세스
• 프라이빗, 퍼블릭, 하이브리드 클라우드에서 컨테이너 관리 가능

Terraform과 Kubernetes: 장단점

Terraform의 Kubernetes 프로바이더는 많은 이점을 제공하지만, Helm에 비해 이 기능은 여전히 비교적 새롭습니다. 간헐적인 버그와 일부 기능 부재로 인해 몇 가지 과제가 있습니다.

Terraform 장점

• 인프라와 클러스터 관리에 동일한 도구와 코드베이스 사용 가능
• 개발자가 Kubernetes 아키텍처 프로비저닝과 클러스터 내 앱 배포에 동일한 언어 사용 가능
• 리소스 스케줄러를 프로바이더로 설정 가능
• 변경 적용 전 행동 결과를 볼 수 있는 계획 단계 보유
• Terraform의 Kubernetes 프로바이더는 강력한 커뮤니티 지원을 받음. K8s 문제 해결은 일반적으로 몇 번의 구글 검색으로 해결
• Terraform에 익숙한 팀이 Kubernetes 클러스터 관리를 쉽고 빠르게 배울 수 있음

Terraform 단점

• Terraform의 Kubernetes 프로바이더는 여전히 비교적 새롭음
• 베타 오브젝트 지원 부족으로 K8s 클러스터 내 앱과 리소스 관리 복잡. 베타 리소스(daemonset, statefulset 등) 작업 시 Terraform 채택 어려움
• 여러 모듈이 프로바이더 기반 의존성을 가질 경우 관리 어려움
• Google Kubernetes Engine(GKE) 완전 지원 안 함
• K8s 클러스터 내에 어떤 컴포넌트도 설치하지 않으므로 실행 중인 파드의 실시간 관리 불가

Terraform과 Kubernetes 및 그 차이점에 대한 자세한 내용은 'Terraform vs Kubernetes' 기사를 참조하세요.

Helm과 Kubernetes: 장단점

Terraform과 마찬가지로 Helm도 많은 K8s 이점을 제공하지만, 이 도구의 Kubernetes 기능은 이미 잘 확립되어 있습니다. 그러나 기업은 Helm 사용의 몇 가지 단점도 고려해야 합니다.

Helm 장점

• Helm의 K8s 지원은 성숙하고 기능이 풍부하여 도구 채택이 원활한 과정
• 다양한 앱과 서비스에 유용한 사전 구축된 방대한 차트 저장소
• 재사용 가능한 차트, 인플레이스 업그레이드, 업데이트를 위한 커스텀 훅으로 복잡한 앱 관리 단순화
• Tiller 서버가 K8s 클러스터 내에서 작동하며 직접 API 호출을 통해
• Tiller로 런타임 리소스 효율적 관리
• 롤백이 단순하고 다루기 쉬움
• 고급 구성(플로우 제어, 파이프라인 등)으로 유연한 배포 템플릿 가능
• 변수 정의 및 다른 환경과 클러스터에 앱 배포 가능
• Helm 차트의 유연성으로 팀이 Kubernetes에서 템플릿 표준화 가능
• 풍부한 사용자 커뮤니티와 업계 거물(Microsoft, Google, Bitnami)의 지원

Helm 단점

• Helm은 Terraform보다 관리하기 더 복잡하며 K8s 설정에서 상당한 책임이 됨
• 도구에 대한 사전 경험이 없는 팀이 Helm 사용법을 배우는 데 시간이 걸릴 수 있음
• 팀은 프로젝트마다 새 이미지를 구성해야 명령 실행 시 혼란 방지 가능
• VM 용량이 컨테이너 확장성에 중요

Helm vs Terraform: 비교표

Helm과 Terraform은 두 오픈 소스 도구 모두 엔지니어가 다음을 수행할 수 있게 한다는 점에서 많은 유사점을 가집니다:

• K8s 오브젝트를 코드로 설명하고 유지
• 다양한 수준과 환경에서 변수 사용 및 덮어쓰기
• 로컬 디렉터리 및 git 리포지토리 등 여러 소스에서 설치
• 액션 실행 전 결과를 볼 수 있는 드라이런 설정(Helm은 --dry-run 플래그, Terraform은 plan 서브명령어)
• 큐레이팅된 패키지 목록 액세스
• 활성 사용자 커뮤니티 도움 요청
• 모든 주요 클라우드 공급업체 지원

유사하지만, 두 도구는 서로 다른 사용 사례에 더 적합하게 만드는 차이점이 있습니다. 아래 표는 Terraform과 Helm의 주요 차이점을 보여줍니다.

Terraform	Helm
비교적 새로운 Kubernetes 프로바이더(하지만 빠르게 개선 중)	검증된 K8s 기능을 갖춘 성숙한 도구
Kubernetes 클러스터 내에 아무것도 설치하지 않음	클러스터 내에 Tiller 서버를 설치하고 K8s API와 연결
Kubernetes 클러스터 설치 가능	Kubernetes 클러스터 설치 불가
모듈로 모듈성 구현	서브 차트로 모듈성 구현
JSON/HCL 파일 형식으로 Kubernetes 오브젝트 설명 및 유지	표준 K8s 매니페스트와 Go 템플릿으로 K8s 오브젝트 설명 및 유지
베타 리소스 지원 부족으로 이미 설정된 환경에서 Terraform 전환 복잡	K8s 지원이 훨씬 성숙하여 도구 채택이 더 간단
런타임 시 제한된 옵션	Tiller가 런타임에 많은 기능 제공
환경 변수 지원	환경 변수 옵션 제한적
레지스트리에 Kubernetes에서 작동하는 Terraform 모듈 없음	안정 및 인큐베이터 차트가 풍부한 패키지 세트 제공
Kubernetes 프로바이더가 아직 커스텀 리소스 처리 안 함	커스텀 리소스 관리 가능
복잡한 롤백이지만 리소스 적게 필요	롤백이 더 쉽지만 더 많은 리소스 필요

Helm과 Terraform: 함께 사용하기

Helm과 Terraform은 상호 배타적이지 않으며, 동일한 K8s 설정에서 두 도구를 모두 사용할 수 있습니다. 두 플랫폼 모두 광범위한 기능을 가지므로 엔지니어는 다음을 수행할 수 있습니다:

• Terraform을 사용하여 Helm 리소스 생성 및 관리
• Terraform 내에서 Helm을 사용하여 클러스터 관련 애플리케이션 배포
• Terraform으로 사전 프로비저닝된 Kubernetes 클러스터에 Helm 차트 배포

두 도구에 모두 의존하는 대부분의 팀은 Terraform으로 K8s 클러스터를 처리하고 Helm으로 클러스터에 들어가는 리소스를 관리하는 경향이 있습니다. 그러나 두 플랫폼을 모두 사용하면 프로젝트가 복잡해지므로, 멀티 툴 환경을 설정하기 전에 한 플랫폼에 의존하는 것을 고려하세요.

Helm vs Terraform: K8s 툴체인의 두 가지 강력한 옵션

Terraform과 Helm 모두 Kubernetes 관리를 더 쉽고 빠르고 안정적으로 만드는 견고한 도구입니다. 그러나 위에서 강조한 뉘앙스로 인해 각 플랫폼은 서로 다른 사용 사례에 더 적합하므로, 팀과 프로젝트에 더 잘 맞는 것을 선택하세요.

IaC 도구와 그것들이 서로 어떻게 비교되는지에 대해 계속 배우려면 Ansible, Terraform, Puppet 비교 기사를 확인하세요.