13. 헬름

하나 이상의 클러스터를 운영하다 보면 같은 어플리케이션을 여러 클러스터에 배포해야 하는 경우가 발생한다.
이럴 때 배포 환경에 따라 달라지는 설정값들때문에 문제점들이 많이 발생한다.

그래서 배포 환경에 따라 달라지는 설정값만 정의해 둔 다음 이에 따라 배포하는 메커니즘이 필요했는데 이를 해결한것이 바로 헬름이다.
헬름은 쿠버네티스 차트를 관리하기 위한 도구이다. 차트는 사전 구성된 쿠버네티스 리소스의 패키지다. 즉 헬름은 패키지 관리도구이며, 차트가 리소스를 하나로 묶은 패키지에 해당한다.

  1. 헬름 : 차트를 관리
  2. 차트(매니패스트 템플릿으로 구성) : 차트를 사용하여 매니페스트 파일 생성
  3. 매니페스트 파일 : 매니페스트 파일에 기초한 쿠버네티스 리소스 관리
  4. 쿠버네티스

헬름으로 차트를 관리하는 목적은 번잡해지기 쉬운 매니페스트 파일을 관리하기 쉽게하기 위한것이다. 헬름은 단순한 패키지 관리자가 아니라, 차트를 중심으로 하는 쿠버네티스 개발 업무의 종합 관리도구이다.

실무에서는 여러 환경에 배포해야 하는 어플리케이션은 모두 차트로 패키징해 kubectl 대신 헬름으로 배포 및 없데이트를 수행한다.

헬름 설치

1
2
3
$ curl -LO https://git.io/get_helm.sh
$ chmod 700 get_helm.sh
$ ./get_helm.sh

헬름 초기화
틸러라는 서버 어플리케이션이 kube-system 네임스페이스에 배포된다. 틸러는 helm 명령에따라 설치 등의 작업을 담당한다.

1
$ helm init

잘 만들어졌나 확인해보자

1
$ kubectl -n kube-system get service,deployment,pod --selector app=helm

버전을 확인해보자.

1
$ helm version

여러 클러스터를 다룰 때는 클라이언트/서버의 버전을 일치시키는것이 좋다. 이를 위해 다음을 입력하여 업그레이드하자.

1
$ helm init --upgrade

헬름?

헬름은 클라이언트(cli)와 서버(쿠버네티스 클러스터에 설치되는 틸러)로 구성된다. 클라이언트는 서버를 대상으로 명령을 지시하고 서버는 클라이언트에서 전달받은 명령에 따라 쿠버네티스 클러스터에 패키지 설치, 업데이트, 삭제 등의 작업을 수행한다.

쿠버네티스는 서비스나 디플로이먼트, 인그레스 같은 리소스를 생성하고 매니페스트 파일을 적용하는 방식으로 어플리케이션을 배포한다. 이 매니패스트 파일을 생성하는 템플릿을 여러 개 패키징한것이 차트이다. 차트는 헬름 레파지토리에 tgz 파일로 저장되며 틸러가 매니페스트를 생성하는데 사용한다.

리포지토리

헬름의 리포지토리는 다음과 같은 종류가 있다.

local : 헬름 클라이언트가 설치된 로컬 리포지토리. 로컬에서 생성한 패키지가 존재
stable : 안정버전의 차트가 존재하는 리포지토리.
incubator : 아직 stable 하지는 못하지만 곧 stable로 넘어갈 예정인 차트

stable 리포지토리는 기본값으로 사용되며 깃허브 github.com/helm/charts에 저장된다.(궁금하면 참고해보자)

차트의 구성

차트는 다음과 같은 디렉터리 구성을 갖는다.

1
2
3
4
5
6
7
8
9
chart_name/ --- templates/ 매니페스트 파일 템플릿 디렉터리
| |- xxxx.yaml 각종 쿠버네티스 리소스의 매니페스트 템플릿
| |-_helper_tpl 매니페스트 랜더링에 사용되는 템플릿 헬퍼
| |-NOTE.txt 차트 사용법 등의 참조 문서 템플릿
|
|-chart/ 이 차트가 의존한느 차트의 디렉토리
|-Chart.yaml 차트 정보가 정의된 파일
|-values.yaml 차트 기본값 value 파일

차트는 어플리케이션의 동작을 제어하는 설정의 기본값을 values.yaml 파일에 정의한다.

차트를 이용해 어플리케이션을 설치하려면 helm install 명령을 사용한다. 어플리케이션을 업데이트,삭제하기 위해서는 릴리즈 네임이 필요한데 –name 옵션으로 붙여준다. 이는 해당 클러스터 안에서 유일한 값이어야 한다.

1
$ helm install [--name 릴리스_네임] 차트_리포지토리/차트명

helm install 명령을 실행하면 차트에 포함된 기본값 value 파일에 정의된 설정값으로 어플리케이션이 설치된다.그러나 기본값 value파일을 사용하는 경우는 드물며 일부 기본값을 수정한 커스텀 value 파일을 주로 사용한다. 이를 위해 각 리포지토리에서 제공하는 참고문서를 참고하자.

레드마인 설치 예제

문서에 규정된 설정값에 따라 커스텀 value 파일을 작성한다. 이를 redmine.yaml파일로 정의한다. 내용은 다음과 같다.
yaml파일에는 기본값에서 수정할 항목만 포함하면 된다.

1
2
3
4
5
redmineUsername: sangheon
redminePassword: sangheon
redmineLanguage: en

serviceType: NodePort

-f 옵션으로 커스텀 value 파일을 지정해서 레드마인을 설치한다.

1
2

$ helm install -f redmine.yaml --name redmine stable/redmine --version 4.0.0

에러발생시

namespaces "default" is forbidden: User "system:serviceaccount:kube-system:default" cannot get resource "namespaces" in API group "" in the namespace "default"

helm list라고 입력했을때
Error: configmaps is forbidden: User "system:serviceaccount:kube-system:default" cannot list resource "configmaps" in API group "" in the namespace "kube-system" 라는 에러 발생시 해결방법

rbac-config.yaml 파일로 다음과 같이 생성한다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
apiVersion: v1
kind: ServiceAccount
metadata:
name: tiller
namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: tiller
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: cluster-admin
subjects:
- kind: ServiceAccount
name: tiller
namespace: kube-system

다음을 순서대로 입력

1
2
$ kubectl create -f rbac-config.yaml
$ helm init --service-account tiller --history-max 200 --upgrade

다시 다음을 입력하여 설치하면 될것이다.

1
$ helm install -f redmine.yaml --name redmine stable/redmine --version 4.0.0

다음을 입력해서 설치한것을 확인할 수 있다.

1
2
$ helm ls
$ kubectl get service,deployment --selector release=redmine

설치한것을 다시 삭제해보자

1
$ helm delete redmine

헬름에서 제공하는 롤백기능 사용해보자

1
2
$ helm ls --all
$ helm rollback redmine 1 #리비전 숫자 입력하기

리비전 기록을 남기지 않고 제거하기

1
$ helm del --purge redmine

RBAC를 지원하는 어플리케이션 설치

공개된 차트 중에는 RBAC를 활성화할 수 있는 어플리케션도 있다. RBAC를 활성화한 어플리케이션을 설치하려면 실제 설치 작업을 수행할 틸러에 cluster-admin이라는 롤(ClusterRole)이 부여돼야 한다. 다음과 같이 cluster-admin 롤을 갖는 서비스 계정을 생성한 다음, 이 계정을 실행중인 틸러의 서비스 계정으로 설정한다.

1
2
3
$ kubectl create serviceaccount --namespace kube-system tiller
$ kubectl create clusterrolebinding tiller-cluster-rule --clusterrole=cluster-admin --serviceaccount=kube-system:tiller
$ kubectl patch deploy --namespace kube-system tiller-deploy -p '{"spec":{"template":{"spec":{"serviceAccount":"tiller"}}}}'
Share