쿠버네티스 패키지 매니저 Helm

현재 쿠버네티스는 가장 많이 사용하고 있는 오픈소스 컨테이너 오케스트레이션 툴이다. 다양한 리소스, 워크로드를 YAML 형태에서 쉽게 정의하여 컨테이너화 된 애플리케이션을 효율적으로 배포 및 운영할 수 있게 도와준다. 이를 통해 변화에 대응하여 신속하게 애플리케이션을 배포하거나 가동 중인 애플리케이션에 대해 스케일 인/아웃을 하는 등 계속되는 변화를 전제로 설계된 높은 유연성과 확장성을 제공하고 있다.

 

그러나 쿠버네티스를 사용하려면 매니페스트를 작성해야 하는데 매니페스트에는 몇 가지 아쉬움이 존재한다.

 

1. 매니페스트에서 개발 환경, 프로덕션 환경에 대해 일부분만 달라도 배포할 때마다 매니페스트를 수정해야 하는가?

2. 여러 개의 매니페스트를 하나의 프로덕트로 제공할(받을) 수 없는가?

3. 가동 중인 매니페스트에 대해 버전 관리를 할 수 없는가?

 

쿠버네티스로 해결할 수 없는 이 아쉬움을 Helm을 통해 해결할 수 있다.

---

"Helm is the best way to find, share, and use software built for Kubernetes."

 

Helm은 쿠버네티스 애플리케이션을 관리할 수 있도록 도와준다.

• 복잡한 쿠버네티스 정의, 설치, 업그레이드를 도와준다.
• 쉽게 만들 수 있고
• 버전 관리를 할 수 있고,
• 공유하고 배포할 수 있다.
• 롤백 → helm rollback을 통해 쉽게 이전 버전으로 릴리스를 할 수 있다.
• 복붙을 하지 말고 이제 Helm을 사용해라!

 

helm의 3가지 핵심 개념

Chart

차트는 헬름 패키지이다. 이것은 클러스터에 있는 서비스를 실행시키기 위해 필요한 모든 리소스를 포함하고 있다.

Repository

차트가 저장되고 공유되는 공간을 의미한다.

Release

쿠버네티스 클러스터 내에서 실행되는 차트의 인스턴스이다. 하나의 차트가 같은 클러스터 내에서 여러 차례 설치된다. 그리고 각각의 설치마다 새로운 릴리스가 생성된다. MySQL 차트 같은 경우 2개의 데이터베이스를 클러스터 내에서 돌린다고 할 때, 각 릴리스는 고유한 릴리스의 이름을 갖는다.

 

즉, Helm은 차트를 설치하고 각 설치에 대하여 클러스터 내에서 새로운 릴리스가 생성된다. 그리고 새로운 차트를 찾기 위해서는 Helm chart 레포지토리에서 찾을 수 있다.

 

 

차트들을 찾아주는 helm search

Helm은 강력한 설치 커맨드를 제공한다. 이것은 2가지의 타입으로 사용된다.

• helm search hub : the Artifact Hub에서 검색을 하는 명령어로 12개의 다른 repository에서 helm chart 리스트를 받아온다.

• helm search repo : 사용자가 추가한 repository들에서 검색을 하는 명령어. 로컬 데이터를 통해 진행되며, 퍼블릭 네트워크 연결이 필요 없다.

helm repo add bitnami
helm repo add brigade https://brigadecore.github.io/charts

helm search repo bitnami # 특정 레포 전체 가져오기
helm search repo wordpress # 레포들에서 특정 차트 가져오기
helm search repo # 모든 차트 가져오기

 

패키지를 설치하는 helm install

새로운 패키지를 설치하기 위해서 사용하는 명령어로 엄청 간단하며 2가지의 인수만 입력하면 된다.

1. 내가 지정할 release 이름 (—generate-name으로 생성할 수도 있다.)
2. 내가 설치할 chart 이름

helm install nemne bitnami/wordpress --version ~~

nemne의 이름으로 새로운 release가 생성된다.

설치되는 동안 helm 클라이언트는 생성할 리소스에 대해 유용한 정보를 출력할 것이다.

또한 추가적인 구성 단계를 수행할 것인지 말 것인지 결정할 수 있다.

 

 

Helm은 모든 리소스가 실행할 때까지 기다리지 않는다.

→ 많은 chart들이 600M 넘는 도커 이미지를 요구하고, 이것은 클러스터에 설치하는데 많은 시간을 소요하기 때문에 끝까지 기다리지 않는다.

→ —wait 명령어를 통해서 기다리게 할 수 있다.

 

이외에도 helm install를 다른 소스에서 설치할 수 있다.

• 차트 저장소
• 로컬 차트 압축 파일
  • helm install foo foo-0.1.1.tgz
• 압축 해제된 차트 디렉터리
  • helm install foo path/to/foo
• URL
  • helm install foo [<https://example.com/charts/foo-1.2.3.tgz>](<https://example.com/charts/foo-1.2.3.tgz>)

 

빌트인 오브젝트를 활용하여 여러 환경에 대응하기

앞서 쿠버네티스 매니페스트의 문제점 중 하나인 여러 환경에 대응하는 매니페스트를 만들 수 없다는 문제점이 있었다. Helm에서는 일종의 변수 역할을 하는 빌트인 오브젝트를 제공하여 해결하고 있다. 매니페스트 내에 자주 변경되는 부분을 빌트인 오브젝트로 채우고 빌트인 오브젝트가 참조하고 있는 파일만 수정해주면 여러 환경에 대응하는 매니페스트를 쉽게 만들 수 있다.

 

Helm에서 제공하고 있는 대표적인 빌트인 오브젝트는 values로 chart 내에서는 values.yaml 형태로 차트에 반영될 값들이 여기에 저장된다.

 

# values.yaml
service:
  name: my-service
  type: NodePort
  port: 80

----- 
# service.yaml
apiVersion: v1
kind: Service
metadata:
  name: {{ .Values.service.name }}
spec:
  type: {{ .Values.service.type }}
  selector:
    app: k8s-app
  ports:
  - protocol: TCP
    port: {{ .Values.service.port }}
    
------
# service.yaml 적용 결과
apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  type: NodePort
  selector:
    app: nginx
  ports:
  - protocol: TCP
    port: 80

차트 내에서 제공하는 values.yaml 자체를 수정하여 반영해도 되지만 일반적으로 dev-values.yaml, prod-values.yaml 등으로 환경에 맞는 yaml를 만들고 install 명령어 실행 시 -f 옵션을 추가하여 기존 values.yaml에 오버라이딩 하는 방식으로 진행한다.

 

release 삭제하기

클러스터에서 releases를 삭제하고 싶을 때 helm uninstall를 통해 삭제할 수 있다.

→ helm uninstall -n <NAMESPACE> <RELEASENAME>

 

helm list를 통해 삭제한 것을 확인할 수 있다.

만약 삭제 release 기록을 보존하고 싶다면 helm uninstall --keep-history를 사용하면 된다.

→ helm list —uninstalled를 사용하면 삭제 release 기록을 확인할 수 있다.

→ helm list —all를 하면 모두 볼 수 있다.

 

예제로 Release와 Rollback 확인하기

실습 소스코드

GitHub - NEM-NE/Playground: 구현 해보고 싶은 것들, 공부 하고 있는 것들에 대해 구현해보고 실험해보

helm install . → helm 경로에 있는 chart를 실행한다.

helm list로 확인 가능

 

kubectl get all로 정상적으로 생성됐는지 확인한다.

helm uninstall nginx-test로 기존에 Release 된 것을 삭제할 수 있다.

 

 

 

이제 Upgrade 명령어는 명령어를 통해 변경할 수 있고 파일 수정으로 변경할 수 있다.

values.yaml에 주석 처리된 repository: dlatqdlatq/my-nginx를 활성화시킨다. (기존 repository는 삭제한다.)

 

helm upgrade nginx-test .를 통해서 업그레이드를 시킨다.

• 업그레이드를 할 때 REVISION 1을 통해서 업그레이드를 하는 것이 아닌 이전 버전 기준으로 업그레이드를 진행한다.

다시 결과를 조회해보면 다음과 같다.

• REVISON 2로 변경
  • helm history nginx-test로 변경점을 확인할 수 있다.
• 기존 파드들은 삭제된다. (RollingUpdate 주의!)
• 변경점이 없는 서비스는 계속 유지된다.

롤백을 하기 전에 이전 버전 이력을 확인하기 위해 helm history로 확인한다.

 

REVISION 1로 변경하기 위해 helm rollback <RELEASE> 1을 한다.

이후 결과를 다시 보면 정상적으로 이전 버전으로 돌아온 것을 확인할 수 있다.