Helm

헬름 문서

헬름은 CNCF의 프로젝트 중 하나로, 쿠버네티스용 소프트웨어를 검색, 공유, 사용하기 위한 패키지 관리자이다. 패키지는 파일과 디렉터리를 압축해 아카이브 시켜놓은 것이다. 윈도우에는 보통 C 드라이브의 Program Files에 패키지가 설치되는 경우가 많다.

헬름을 시작하기 전 사전 요구사항은 세 가지가 있다. 다음과 같다.
1. 쿠버네티스 클러스터가 필요하다.
2. 설치에 적용할 보안 구성 결정. (있는 경우)
3. 헬름이 설치되어 있어야 하고, 헬름 구성이 필요하다. 이것이 kubeconfig이다.

지금은 사용하지 않지만, 헬름 V2의 구성은 다음과 같다.

헬름 클라이언트가 V2인 경우, 쿠버네티스 클러스터의 API 서버와 통신하는 Tiller라고 하는 파드와 헬름 클라이언트가 gRPC라는 프로토콜로 통신한다. Tiller라는 파드는 외부에 노출되어 있고, 사용자를 대신해서 패키지를 설치, 즉 리소스 오브젝트 생성을 API 서버에 요청해야 하기 때문에 cluster-admin 권한을 가진다. Tiller에 문제 혹은 보안 구멍이 발생하면 쿠버네티스 클러스터의 보안에 큰 문제가 생길 수 있다. 그래서 헬름 V3때는 Tiller를 사용하지 않게 되었다. 따라서, Tiller가 나오는 자료는 헬름 V3인 지금 사용하지 않기 때문에 참고하지 않아도 된다.

헬름 V3에서는 헬름 클라이언트와 쿠버네티스 API 서버가 https로 직접 통신한다. kubctl과 같다. 따라서 helm 명령어를 사용하기 위해선 인증이 필요하다. helm을 실행하기 위해 kubeconfig가 필요한 이유이다.

helm은 쿠버네티스 대부분의 리소스를 다룰 수 있다.

바이너리 릴리스로 helm 설치

헬름은 소스 또는 미리-빌드된(pre-built) 바이너리 릴리스로 설치할 수 있다. 유닉스 계열에서 바이너리는 실행파일을 의미한다. 즉, 실행파일을 직접 받아 설치하는 방법이다.

cd ~
wget https://get.helm.sh/helm-v3.11.1-linux-amd64.tar.gz
tar xf helm-v3.11.1-amd64.tar.gz
sudo install linux-amd64/helm /usr/local/bin #실행권한을 줘서 적절한 곳에 복사
helm version #버전 확인

helm은 실행 파일 하나로 되어 있다. 이렇게 파일 하나로 빌드하는 형태를 스태틱 빌드라고 한다.

헬름 차트 리포지토리 초기화

헬름의 패키지를 헬름 차트라고 한다. (차트 = 패키지)

helm repo list #no repositories to show라는 오류가 뜸
helm repo add bitnami https://charts.bitnami.com/bitnami #차트 리포지토리 추가
helm repo list #binami 레포를 볼 수 있다.
helm search repo bitnami #리포지토리에서 설치 가능한 패키지를 찾을 수 있다.

차트 버전은 패키지의 버전이고 앱 버전은 어플리케이션의 버전이다. 이 둘은 전혀 다르다.

sudo helm update #apt update처럼 패키지의 목록을 업데이트해준다.
helm install mydb bitnami/mysql #mydb라는 이름으로 bitnami/mysql이라는 차트를 다운로드한다.

mydb를 릴리즈 이름, bitnami/mysql을 차트(패키지) 이름이라고 한다. 차트를 설치하면 릴리즈라고 한다. 릴리즈의 이름을 랜덤으로 만드려면 --generate-name이라는 옵션을 달면 된다.

helm list #릴리즈(=설치된 패키지)의 목록을 본다

kubectl get all

릴리즈가 mydb라는 이름으로 생성된 것을 확인할 수 있다.

helm status 릴리즈명 #릴리즈의 상태를 확인할 수 있다.
helm uninstall mydb #릴리즈 삭제

helm uninstall 후 kubectl get all을 하면 삭제된 릴리즈가 없어진 것을 확인할 수 있다.

스테이트풀셋을 쓰고 있고 PVC를 다이나믹 프로비저닝으로 요청한다. 헬름 차트를 만드는 쪽에선 사용자의 환경을 모르기 때문에 스토리지를 사용해야 하는 경우 보통은 스토리지 클래스의 이름을 사용하지 않는 다이나믹 프로비저닝을 사용한다. 따라서 디폴트 스토리지 클래스를 할당해놓지 않으면 스토리지가 할당되지 않고 스토리지나 파드가 제대로 실행되지 않는다.

kubectl delete pvc data-mydb-mysql-0

스테이트풀셋을 helm uninstall로 삭제한다 해도 스테이트풀셋은 기본적으로 PV와 PVC를 삭제하지 않는다. 따라서 삭제한 후에도 PV와 PVC를 수동으로 삭제해줘야 한다.

helm search

차트를 찾는 방법은 두 가지가 있다.

helm search repo <repo name> #로컬에 추가된 저장소 검색
helm search hub <repo name> #허브에서 찾기

이 중 hub에서 찾는 방법은 Artifact hub에서 차트를 찾는다. 아티팩트 허브는 쿠버네티스 패키지를 공개하고 설치하고 찾는 사이트이다. 도커 허브는 도커 허브에 컨테이너 이미지가 저장되어 있다면, 아티팩트 허브는 사이트 자체에서 패키지를 직접 갖고 있는 것은 아니다. 단지 설치할 수 있도록 검색하게 해 준다. 이를 통해 공개적으로 사용 가능한 차트를 찾을 수 있다.

Customizing the Chart Before Installing

패키지는 기본적으로 동일한 형태로 다운로드되지만, helm의 패키지는 원하는 경우 커스터마이징할 수 있다. 하지만 패키지에서 커스터마이징을 불가능하게 만들었다면 커스터마이징 할 수 없다.

helm show values bitnami/mysql > mysql-param.yaml #yaml 파일로 values 저장

이 값을 ClusterIP에서 NodePort로 바꾼 후 저장하고 다시 install한다.

helm install mydb bitnami/yaml -f mysql-param.yaml

기본값인 ClusterIP에서 NodePort로 바뀐 것을 확인할 수 있다. Artifact Hub 사이트에서 확인할 수 있는 차트의 Parameter들은 커스터마이징 할 수 있는 값들이다.

Bitnami charts project in github 의 bitnami 카테고리 안의 폴더들은 모두 차트 이름이다.

차트 패키지의 필수 항목으로 세 가지가 있다.

• templates
  디렉터리이다. menifests 파일이 위치한다. 중괄호 두개로 시작되는 항목이 보이는데, 이 중괄호 두개로 되어 있는 항목들이 커스터마이징 할 수 있는 항목들이다.
• Chart.yaml
  패키지의 메타데이터이다. 이 패키지의 볼륨, 카테고리, 라이센스 정보, 어플리케이션 정보, 의존성 정보, 이름 등 차트의 정보들이 작성되어 있다.
• values.yaml
  앤서블의 변수 파일과 비슷한 형태이다. 파라미터라고 한다. helm show values 를 했을 때 볼 수 있는 것이 바로 values.yaml 파일이다.

이 파일들의 내용을 커스터마이제이션 할 수 있다. 보통 파일로 리다이렉션 저장해서 수정한다. 혹은 파일을 먼저 만들어 필요한 부분만 설정하고 install 할수도 있다.

vi my-param.yaml

primary:
	service:
    	type: LoadBalancer

helm install mydb bitnami/yaml -f my-param.yaml

이와 같이, helm의 핵심은 바로 커스터마이징 할 수 있다는 점이다.

파라미터를 제공하는 방법은 두 가지가 있다.

• --values (or -f)
  위와 같다.

• --set
  명령줄을 통해 커스터마이제이션 할 수 있다. yaml파일을 만들지 않고 한두줄 정도 수정할 때 용이하다. 하지만 어떻게 커스터마이제이션 했는지 헷갈리기 때문에 yaml 파일을 쓰는 것이 권장된다.

helm install mydb bitnami/mysql --set "primary.service.type=NodePort"

helm upgrade and helm rollback

helm install mydb bitnami/mysql #디폴트 값으로 차트 설치

차트 버전이 업데이트되거나 파라미터를 조정하고 싶을 때가 있다. 예를 들어, VM을 Vagrant로 배포할 때, Vagrantfile을 이용해 배포를 지정하므로 지우는 것도 관리하는 것도 Vagrant를 이용해야 한다. 직접 VM을 수정하면 안 된다. 모든 IaC 개념은 동일하기 때문에 이것은 helm에도 적용된다. helm을 이용해 배포한 리소스는 직접 수정하거나 관리하면 안 되고 helm의 기능을 이용해야 한다. 즉, mydb를 kubectl을 이용해 수정하는 것은 안 되고 helm upgrade 명령어를 이용해야 한다.

helm upgrade mydb bitnami/mysql -f my-param.yaml #업그레이드
helm list

revision이 2로 되어있는 것을 확인할 수 있다. 이것은 delployment와 상관 없는 helm 자체의 버전 관리 기능이다.

이전 상태로 돌아가기 위해서는 helm rollback 명령어를 사용한다.

helm rollback mydb 1 #1은 revision번호

revision이 3으로 바뀌고 원래 상태인 ClusterIP로 바뀐 것을 확인할 수 있다.

helm을 통한 쿠버네티스 대시보드 설치

참조

쿠버네티스를 웹 인터페이스를 통해 리소스를 확인할 수 있는 방법이다. yaml 파일로 배포하기 위한 커맨드는 다음과 같다.

kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.7.0/aio/deploy/recommended.yaml

이를 Artifact helm을 통해 설치해 보자.

helm repo add kubernetes-dashboard https://kubernetes.github.io/dashboard/
helm repo update #권장

ClusterIP 타입으로 만들어지기 때문에 사용자가 접속하지 못한다. 하지만 이것은 관리자를 위한 대시보드이기 때문에 외부에 노출하지는 않는다. 하지만 이번엔 실습을 위해선 LoadBalancer로 커스터마이징 해 보자.

vi dashboard-param.yaml

service:
	type: LoadBalancer

관리목적이므로 다른 네임스페이스에다 만드는 것이 추천된다. -n 옵션을 사용하면 특정 네임스페이스에다 생성할 수 있다.

helm install kubernetes-dashboard kubernetes-dashboard/kubernetes-dashboard -n kube-system
helm upgrade kubernetes-dashboard kubernetes-dashboard/kubernetes-dashboard -n kube-system -f dashboard-param.yaml
helm list -A #모든 곳의 차트 확인

https://192.168.56.200/ 으로 접속하면 다음과 같은 화면을 볼 수 있다.

인증을 받아야 한다. 토큰 방식과 Kubeconfig 방식이 있는데, 웹 브라우저는 윈도우에 있고 kubeconfig는 리눅스에 있으므로 Kubeconfig 형식은 사용할 수 없다. 따라서 토큰 방식을 사용해야 한다.

kubectl get sa -n kube-system kubernetes-dashboard

리눅스에서 확인해 보면, kubernetes-dashboard라는 SA가 만들어진 것을 확인할 수 있다. 파드의 서비스 어카운트는 이것으로 작동하고 있다. 예전에는 SA를 생성하면 SA를 인증할 수 있는 토큰이 자동으로 만들어져 secret에 저장됐지만, 현재 버전에서는 토큰이 자동으로 생성되지 않는다. 이전 버전에서 자동으로 생성된 토큰은 만료되지 않고 영구적으로 유지됐기 때문이다. 따라서, 현재 버전에서는 토큰을 수동으로 생성해주어야 한다.

kubectl create token -n kube-system kubernetes-dashboard

토큰을 명령어를 사용해 생성하면 토큰이 생성되고, 이는 24시간동안 유효하다. 생성된 토큰을 붙여넣으면 관리 페이지에 로그인할 수 있다.

하지만 대시 보드에는 아무것도 뜨지 않고 접근이 불가능하다는 오류밖에 뜨지 않는다.

해결 방안: 클러스터 롤 바인딩 설정

알람들은 권한이 없다는 뜻이다. 적절한 권한이 있어야 접근할 수 있다. 이를 해결하는 가장 간단한 방법은 사용자를 cluster-admin에 바인딩하는 것이다. 대시보드는 모든 리소스를 보고 수정하고 생성/삭제할 수 있기 때문이다.

kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: kubernetes-dashboard
  namespace: kube-system
subjects:
- kind: ServiceAccount
  name: kubernetes-dashboard
  namespace: kube-system
  apiGroup: ""
roleRef:
  kind: ClusterRole
  name: cluster-admin
  apiGroup: "rbac.authorization.k8s.io"

kubectl create -f kubernetes-dashboard.yaml

+기호를 눌러 직접 생성할수도 있지만 한계가 있다.

권한을 부여한 후 확인하면 정상적으로 실행되는 것을 확인할 수 있다. kubernetes-dashboard는 해당 SA에 의해 실행되고, 대시보드를 정상적으로 실행시키기 위해선 cluster-admin 역할과 바인딩하는 것이 중요하다는 것을 알 수 있다. 공식 문서를 항상 체크하는 습관을 들이는 것이 중요하다.