헬름(Helm)이란. 헬름 완벽 가이드

Helm은 구성 파일을 재사용 가능한 단일 패키지로 결합하여 Kubernetes 애플리케이션의 생성, 패키징, 구성 및 배포를 자동화하는 도구이다.

마이크로서비스 아키텍처에서는 애플리케이션이 커짐에 따라 더 많은 마이크로서비스를 생성하므로 관리하기가 점점 더 어려워진다. 오픈 소스 컨테이너 오케스트레이션 기술인 Kubernetes는 여러 마이크로 서비스를 단일 배포로 그룹화하여 프로세스를 단순화한다. 그러나 개발 수명 주기 전반에 걸쳐 Kubernetes 애플리케이션을 관리하는 것은 버전 관리, 리소스 할당, 업데이트 및 롤백을 포함하여 고유한 일련의 문제를 야기한다.

Helm은 이 문제에 가장 접근하기 쉬운 솔루션 중 하나를 제공하여 배포를 보다 일관되고 반복 가능하며 안정적으로 만든다. 이 글에서는 Helm 및 해당 사용 사례와 Kubernetes 프로젝트에 Helm을 채택해야 하는지 여부를 결정하는 방법에 대해 알아보자.

Helm으로 Kubernetes 관리 간소화

컨테이너는 애플리케이션과 해당 종속성을 단일 이미지 파일로 묶는 경량 소프트웨어 구성 요소이다. 컨테이너는 서로 다른 플랫폼 간에 이식 가능하므로 더 빠른 애플리케이션 시작과 손쉬운 확장이 가능하다.

Kubernetes는 YAML 구성 파일을 사용하여 배포한다. 자주 업데이트되는 복잡한 배포의 경우 이러한 파일의 다양한 버전을 모두 추적하기 어려울 수 있다. Helm은 버전 정보가 있는 단일 배포 YAML 파일을 유지 관리하는 편리한 도구이다. 이 파일을 사용하면 몇 가지 명령으로 복잡한 Kubernetes 클러스터를 설정하고 관리할 수 있다. 다음 섹션에서는 Helm의 다양한 구성 요소와 이들이 Kubernetes 관리를 간소화하는 데 어떻게 도움이 되는지 검토한다.

Helm 차트

Helm 차트는 애플리케이션을 Kubernetes 클러스터에 배포하는 데 필요한 모든 리소스가 포함된 패키지이다. 여기에는 애플리케이션의 원하는 상태를 정의하는 배포, 서비스, 비밀 및 구성 맵에 대한 YAML 구성 파일이 포함된다.

Helm 차트는 매개변수화된 값을 기반으로 추가 구성 파일을 생성하는 데 사용할 수 있는 YAML 파일 및 템플릿을 함께 패키징 한다. 이를 통해 다양한 환경에 맞게 구성 파일을 사용자 지정하고 여러 배포에서 사용할 재사용 가능한 구성을 생성할 수 있다. 또한 각 Helm 차트는 독립적으로 버전을 지정하고 관리할 수 있으므로 구성이 다른 여러 버전의 애플리케이션을 쉽게 유지 관리할 수 있다.

구성

구성에는 일반적으로 YAML 파일에 저장하는 애플리케이션 구성이 포함된다. Kubernetes 클러스터의 리소스는 이러한 값을 기반으로 배포된다.

릴리스

실행 중인 차트 인스턴스를 릴리스라고한다. 명령을 실행하면 helm install구성 및 차트 파일을 가져오고 모든 Kubernetes 리소스를 배포한다.

건축학

이제 이러한 Helm 개념을 이해했으므로 Helm의 아키텍처를 살펴보자. Helm의 아키텍처에는 클라이언트와 라이브러리라는 두 가지 주요 구성 요소가 있다.

Helm 클라이언트는 최종 사용자가 로컬 차트 개발을 제어하고 리포지토리 및 릴리스를 관리하기 위한 명령줄 유틸리티이다. MySQL 데이터베이스 클라이언트를 사용하여 MySQL 명령을 실행하는 것과 마찬가지로 Helm 클라이언트를 사용하여 Helm 명령을 실행한다.

Helm 라이브러리는 모든 어려운 작업을 수행한다. 여기에는 Helm 명령에 지정된 작업을 수행하는 실제 코드가 포함되어 있다. 모든 릴리스를 만들기 위한 구성 및 차트 파일의 조합은 Helm 라이브러리에서 처리한다.

Helm 아키텍처는 버전 2와 3 사이에서 크게 개선되었다. 버전 2는 Tiller 서버를 사용하여 Helm 클라이언트와 Kubernetes API 서버 사이를 중재했다. Helm을 사용하여 생성된 모든 리소스를 추적했다. 클라이언트 전용 아키텍처를 위해 버전 3은 Tiller 서버를 제거하고 대신 직접 API 연결을 사용하여 Kubernetes API 서버와 상호 작용한다.

Helm 작동 방식

Helm 애플리케이션 라이브러리는 차트를 사용하여 Kubernetes 애플리케이션을 정의, 생성, 설치 및 업그레이드한다. Helm 차트를 사용하면 Kubernetes 명령줄 인터페이스(CLI)를 사용하거나 클러스터를 제어하기 위한 복잡한 Kubernetes 명령을 기억하지 않고도 Kubernetes 매니페스트를 관리할 수 있다.

Helm이 유용한 실제 시나리오를 고려하십시오. 10개의 복제본이 있는 프로덕션 환경에 애플리케이션을 배포한다고 가정한다. 애플리케이션의 배포 YAML 파일에서 이를 지정하고 kubectl명령을 사용하여 배포를 실행한다.

이제 스테이징 환경에서 동일한 애플리케이션을 실행한다. 스테이징에 3개의 복제본이 필요하고 스테이징 환경에서 내부 애플리케이션 빌드를 실행할 것이라고 가정한다. 이렇게 하려면 image배포 YAML 파일에서 복제본 수와 Docker 태그를 업데이트한 다음 스테이징 Kubernetes 클러스터에서 사용한다.

애플리케이션이 더 복잡해지면 YAML 파일 수가 증가한다. 결국 YAML 파일의 구성 가능한 필드도 증가한다. 곧 여러 YAML 파일을 업데이트하여 서로 다른 환경에서 동일한 앱을 배포하는 것이 관리하기 어려워진다.

Helm을 사용하면 환경에 따라 필드를 매개변수화할 수 있다. 이전 예에서 복제본 및 Docker 이미지에 대한 정적 값을 사용하는 대신 values.yaml 파일에서 이러한 필드의 값을 가져올 수 있다. 

 

 

이제 각각에 대한 적절한 값을 사용하여 각 환경에 대한 값 파일을 유지할 수 있다. Helm은 실제 YAML 구성에서 구성 가능한 필드 값을 분리하는 데 도움이 된다.

 

 

Helm 저장소

Helm 리포지토리는 Helm 차트를 업로드할 수 있는 곳이다. 조직 내에서 차트를 공유하기 위해 개인 리포지토리를 생성할 수도 있다. Artifact Hub는 다양한 용도로 설치할 수 있는 검색 가능한 차트를 제공하는 글로벌 Helm 리포지토리이다. 즉, Artifact Hub는 Docker Hub가 Docker 이미지에 대해 수행하는 작업을 Helm 차트에 대해 수행한다.

 

배포 및 롤백에 Helm 사용

Helm 차트가 생성되면 앱을 쉽게 배포할 수 있다. 모든 Kubernetes 리소스를 배포하려면 Helm 명령 몇 개만 실행하면 된다.

Helm 차트를 사용하여 배포된 Kubernetes 클러스터에서 애플리케이션을 실행하고 있다. 이제 애플리케이션에 대해 Prometheus와 같은 모니터링 솔루션을 구성하려고 한다. 두 가지 옵션이 있다.

• Prometheus 애플리케이션의 모든 배포 및 서비스를 처음부터 만든다. 이것은 시간이 많이 걸리는 작업이다.
• Artifact Hub에서 Prometheus 차트를 검색하고 요구 사항에 따라 구성을 업데이트하고 설치한다. FROM이 프로세스는 Dockerfile의 문 에서 Docker Hub의 기존 Docker 이미지를 사용하는 것과 같다.

다음 단계를 사용하여 모든 Helm 차트를 설치할 수 있다.

 

1) Helm 라이브러리가 Helm 차트를 가져올 위치를 식별하는 데 도움이 되도록 Helm 리포지토리를 로컬로 등록한다.
2) 구성한 리포지토리에서 사용 가능한 모든 Helm 차트를 가져옵니다.
3) 파일을 업데이트하고 values.yaml(필요한 경우) 명령을 사용하여 특정 Helm 차트를 설치한다 helm install. Helm을 사용하는 또 다른 장점은 롤백 프로세스가 쉽다는 것이다.

 

Helm은 애플리케이션 수준에서 작동한다. 즉, 릴리스라고도 하는 실행 중인 애플리케이션의 상태를 유지한다. 예상대로 작동하지 않는 새 버전의 애플리케이션을 배포했다고 가정한다. 명령을 사용하여 helm rollback이전 안정 릴리스로 되돌릴 수 있다. 이 명령은 모든 배포, 서비스 및 Kubernetes 리소스를 롤백한다.

Helm이 없으면 롤백이 어려울 것이다. 각 Kubernetes 리소스에 대해 롤백을 수행해야 하므로 복잡한 애플리케이션을 관리하기 어려울 수 있다.

Helm 및 CI/CD

Helm은 Kubernetes 애플리케이션을 CI/CD(지속적인 통합 및 제공) 파이프라인 에서 더 쉽게 빌드하고 테스트할 수 있도록 만드는 데 중요한 역할을 한다. 모든 환경에서 애플리케이션을 자동으로 배포하고 빌드 시간을 단축할 수 있다. 빌드 및 테스트 환경에서 더 많은 유연성을 얻으려면 파이프라인에 자체 호스팅 실행기를 사용할 수 있다.

CircleCI의 자체 호스팅 러너를 사용 하면 관리하는 환경에서 CI/CD 작업을 실행할 수 있다. 이 환경은 독립 실행형 가상 머신이거나 Kubernetes와 같은 전체 클러스터일 수 있다. Container Runner를 사용하면 Helm 차트를 사용하여 프라이빗 Kubernetes 클러스터에 컨테이너화된 워크로드를 배포하고 모든 수준의 수요를 수용하도록 환경을 확장할 수 있다.

Helm 사용의 장단점

Helm을 사용하는 것이 유익한 시나리오와 Helm이 사용 사례에 적합하지 않은 시나리오가 있다. 이 섹션에서는 Helm이 유용하거나 유용하지 않은 사용 사례를 검토하고 조직이 Helm을 사용하여 이점을 얻을 수 있는 몇 가지 징후를 강조한다.

Helm를 사용하는 경우

Helm은 프로젝트에서 Kubernetes를 사용하여 많은 마이크로서비스가 포함된 복잡한 애플리케이션을 실행할 때 유용한다. Helm을 사용하면 애플리케이션의 배포 및 관리를 쉽게 자동화하여 수동 작업량을 줄이고 시스템의 신뢰성과 안정성을 향상시킬 수 있다. Helm은 또한 사전 구성된 패키지의 광범위한 리포지토리에 대한 액세스를 제공하므로 애플리케이션에 새로운 기능을 쉽게 추가할 수 있다.

응용 프로그램의 구성 요소를 쉽게 설치 및 업그레이드할 수 있는 모듈식 차트로 구성함으로써 Helm은 응용 프로그램 구성 요소 관리 프로세스를 단순화한다. 애플리케이션을 유지 관리하는 데 필요한 수동 작업량을 줄이고 복잡한 시스템을 수동으로 관리할 때 발생할 수 있는 오류와 불일치를 방지할 수 있다.

또한 Helm은 개발, 스테이징 및 프로덕션과 같은 여러 환경에서 컨테이너 배포를 지원하므로 개발 프로세스 전체에서 컨테이너의 수명 주기를 쉽게 관리할 수 있다.

Helm이 유용하지 않을 때

Helm은 단일 컨테이너를 서버에 배포해야 하는 프로젝트에 적합하지 않습니다. 이 경우 Helm을 사용하여 컨테이너 배포를 관리할 필요가 없으며 프로세스가 복잡해질 수도 있다. Helm은 여러 컨테이너 배포를 단일 단위로 관리하도록 설계되었으므로 이 시나리오에서는 도움이 되지 않습니다.

적은 수의 Kubernetes 애플리케이션이 있고 패키지 관리자 없이 수동으로 관리할 수 있는 경우 Helm을 사용해도 큰 이점이 없을 수 있다.

마지막으로 조직에 Helm과 같은 타사 도구 사용을 금지하는 엄격한 보안 정책이 있는 경우 환경에서 Helm을 사용하지 못할 수 있다.

언제 Helm을 도입해야 할까?

프로젝트가 Helm을 사용하여 이점을 얻을 수 있다는 몇 가지 지표가 있다. 예를 들어 프로젝트에 함께 관리하고 배포해야 하는 여러 Kubernetes 애플리케이션이 포함되어 있다고 가정한다. 이 경우 Helm은 이러한 응용 프로그램을 단일 차트로 패키징하여 함께 관리하고 배포하기 쉽게 만들어 도움을 줄 수 있다.

프로젝트에 Kubernetes 애플리케이션의 빈번한 업데이트 및 배포가 포함되는 경우 Helm은 애플리케이션의 수명 주기를 관리하기 위한 도구를 제공하여 도움을 줄 수 있다. 여기에는 배포, 업데이트 및 롤백이 포함된다. 결과적으로 애플리케이션 업데이트를 보다 쉽게 ​​관리하고 배포할 수 있다.

마지막으로 프로젝트에 Kubernetes 애플리케이션의 개발 및 배포에 대해 협업해야 하는 여러 팀 또는 기여자가 포함된 경우 Helm은 차트의 버전 관리 및 공유 기능을 제공하여 도움을 줄 수 있다. 팀이 더 쉽게 협업하고 배포 간에 일관성을 유지할 수 있다.

 

원글 : https://circleci.com/blog/what-is-helm/