helm을 배워보자 3일차 - 설치와 시작

놀고 싶은데, 왜 다들 공부하는거야·2024년 7월 9일
helm
0

helm

목록 보기
3/8

Charts

helm에서의 package 단위는 chart이다. chart는 kubernetes application이 설치되어야 할 방법을 보여준다.

chart는 일련의 file과 directory들로 구성되어있는데 이들은 kubernetes에 설치되어야 할 resource들을 설명하는 chart 사양을 준수한다. 이후에 chart의 구조에 대해서 자세히 알아볼 예정이고, 몇 가지 상위 level concept들을 알아보도록 하자.

chart는 chart를 설명하는 Chart.yaml 파일을 가진다. 여기에는 chart에 대한 chart version, name, description, 저작자 등이 적혀있다.

chart는 또한 templates directory를 포함하는데, 여기에는 kubernetes manifests들이 있다. 이 kubernetes manifest들은 golang template문법으로 여러 data들이 annotate되어있다.

chart는 또한 values.yaml file을 가질 수 있다. 이 file은 default configuration 값들을 제공하는데, 이 configuration값들을 parameter로 하여 template directory에 있는 kubernetes manifest들을 설치할 수 있다. 즉, kubernetes manifest에 있는 template문법에서 value를 요구하면 values.yaml의 값이 거기 들어가게되고, override된다.

정리하자면 helm의 package인 chart는 하나의 directory로 Chart.yaml, value.yaml, file과 templates directory로 이루어져 있는 것이다. 단지, 이 file과 directory를 tar로 묶고 gzip으로 압축한 것이 전부인 것이다.

chart들은 chart repositories에 저장된다. 이는 추후에 다시 알아보도록 하자. helm은 이러한 repository로부터 chart들을 다운받고 설치하는 방법을 알고 있는 것이다.

Resources, Installations and Releases

helm chart를 이용해 kubernetes object를 설치한다고 할 때, 다음의 과정을 거치게 된다.

  1. helm이 chart를 읽는다. (필요하면 다운로드까지 실행)
  2. value들을 template로 보내어 kubernetes manifest를 완성한다.
  3. manifest들이 kubernetes에 전달된다.
  4. kubernetes은 cluster에 kubernetes object를 만들어낸다.

즉, helm chart가 kubernetes에 설치되면 kubernetes resource들에 대한 definition이 만들어지고, 이 definition을 kubernetes에 전달하여 kubernetes resource들을 만들어내는 것이다. 동일한 chart를 매번 다른 이름으로 여러번 설치할 수 있다. 따라서 동일한 kubernetes resource를 여러 개 가질 수 있는 것처럼 동일한 chart에 여러 installation이 있을 수 있다.

helm에서 chart를 설치하고 helm upgrade를 사용하면 이제 해당 installation에 대해서 두 release가 있게된다. 즉, helm을 사용하여 installation을 할 때마다 새로운 installation release가 생기는 것이다.

한 가지 조심해야할 것은 helm과 helm chart버전은 다르다. 이들은 다르게 버저닝이 되는데, 대부분 helm version3와 helm chart version2로 사용한다.

helm 설치와 시작

helm은 helm이라는 CLI tool을 통해서 chart에 대한 추가, 삭제 등의 기본 동작을 수행할 수 있다. 따라서, helm을 시작하기 전에 먼저 helm CLI를 설치하는 것이 먼저이다.

https://github.com/helm/helm/releases

다음의 helm release page에 가서 다운로드 후에 실행을 시켜주도록 하자.

tar -zxf ./helm-release.tar.gz
chmod helm +x

위의 명령어를 실행시켜주면 helm CLI를 설치하여 설정까지 해줄 수 있다.

다음은, script를 통해 설치하는 방법이다.

curl -fsSL -o get_helm.sh \
https://raw.githubusercontent.com/helm/helm/master/scripts/get-helm-3
chmod 700 get_helm.sh
./get_helm.sh

get_helm.sh script를 실행하면 가장 최신 helm3 version을 찾아 설치를 진행해준다.

helm은 kubectl과 동일한 매커니즘으로 kubernetes cluster와 연결하기 위해 시도한다. $KUBECONFIG 환경변수를 읽어 kubernetes cluster를 찾으려고하고, 만약 설정되어 있지않다면 kubectl이 확인하는 경로인 $HOME/.kube/config를 확인하여 cluster에 연결한다. 또한, 환경변수인 HELM_KUBECONTEXT와 command-line flags인 `--kube-context-를 사용하여 cluster에 연결하려고 한다.

이제 helm을 본격적으로 시작하기 위해서, 가장 많이 사용되는 workflow를 준비해보도록 하자.
1. chart repository 추가
2. 설치할 chart 찾기
3. helm chart 설치
4. 설치된 것들의 list 보기
5. installation upgrade하기
6. installation 삭제하기

Chart Repository 추가하기

helm의 chart는 개별적인 package로 사용자의 kubernetes cluster에 설치된다. 그런데, 누군가 만든 chart를 공유하는 것은 어떻게할 수 있을까?? helm에서는 helm chart를 공유하고, 인덱싱하기 위한 standard format을 제공하는데, 이것이 바로 helm chart repository이다. chart repository는 간단한 file들로 network를 통해 접근이 가능하며 package들을 인덱싱하는 helm 스펙을 따른다. 즉, chart repository는 여러 chart들을 하나로 묶어 쉽게 제공해주기 위한 하나의 registry와 같다.

수 많은 회사들이 chart repository를 제공한다. helm chart repository도 docker hub처럼 온라인으로 다양한 사업자들이 제공하는 사이트가 있다. https://artifacthub.io/ 해당 page에서 수천개의 helm chart를 볼 수 있을 것이다. 각 chart들은 적절한 repository에 의해 호스팅되고 있다. 즉, https://artifacthub.io/ 사이트에서는 helm chart들이 제공되어있고, 이 helm chart들은 잘보면 각 repository에 따라 다르게 제공되고 있는 것을 볼 수 있다.

chart repository에 대해서 알아보기 위해서 drupal content management system을 사용해보도록 하자. https://www.drupal.org/ 해당 chart에는 여러 kubernetes type들이 존재하여 example로 배우기 좋다. https://artifacthub.io/packages/helm/bitnami/drupal

명확하게 해야할 것은 drupal은 chart로 bitnami라는 chart repository에 있는 chart 중 하나인 것이다. 따라서, 해당 drupal chart를 설치하기 위해서는 bitnami repository를 먼저 설치해야한다.

  • local helm에 repository 추가하기
helm repo add bitnami https://charts.bitnami.com/bitnami
"bitnami" has been added to your repositories

helm repo add 명령어로 bitnami라는 repository를 https://charts.bitnami.com/bitnami로 부터 local helm에 끌고 온 것이다.

  • local helm에 설치된 repositry들 확인하기
helm repo list
NAME            URL
bitnami         https://charts.bitnami.com/bitnami

그런데 어떤 chart가 어떤 chart repository에 있는 지 알 수 있을까??

Chart Repository

artifacthub에서 chart를 검색해봐서 어떤 repository에 있는 지 볼 수 있지만, cli를 통해 검색할 수도 있다.

  • drupal이라는 chart가 있는 repository찾기
helm search repo drupal
NAME            CHART VERSION   APP VERSION     DESCRIPTION
bitnami/drupal  18.21.12        10.3.0          Drupal is one of the most versatile open source...

솔직히 cli문법이 이상하긴하다.

만약, chart의 version들을 모두 보고싶다면 --versions를 붙이면 된다.

helm search repo drupal --versions
NAME            CHART VERSION   APP VERSION     DESCRIPTION
bitnami/drupal  18.21.12        10.3.0          Drupal is one of the most versatile open source...
bitnami/drupal  18.21.11        10.3.0          Drupal is one of the most versatile open source...
bitnami/drupal  18.21.10        10.2.7          Drupal is one of the most versatile open source...
bitnami/drupal  18.21.9         10.2.7          Drupal is one of the most versatile open source...
bitnami/drupal  18.21.8         10.2.7          Drupal is one of the most versatile open source...
...

단, 주의할 것은 chart version과 app version은 다르다는 것이다. app version은 말 그대로 application version이고 chart version은 application 뿐만 아니라 chart에 대한 업데이트도 있을 수 있다.

Package 설치

helm은 package관리를 chart로 한다고 했다. 따라서, package를 설치하는 것은 helm chart를 설치하는 것과 같다. helm chart를 설치하는 것은 두 가지 정보가 필요한데, 하나는 설치하려는 대상의 이름, 두번째는 설치하려는 chart이다.

helm chart를 설치하는데 '이름'이 필요한 이유가 궁금할 것이다. 일반적으로 host computer에 같은 program을 두 번 설치하지 않는다. 설령 두 번 설치한다해도 두 번 실행하지 않는다. 가령 host에서 mysql database server 두 개를 따로따로 실행하지 않는다는 것이다. 그러나 kubernetes에서는 이러한 일이 가능하다. 똑같은 설정에, 똑같은 image이고, 똑같은 version이지만 이름만 다르게 하여 서로 다른 두 개의 pod를 만들어낼 수 있다.

따라서, helm chart역시도 똑같은 chart이지만 이름을 달리하여, 여러 object들을 생성해낼 수 있는 것이다.

이는 helm에서 같은 chart에서 서로 다른 인스턴스를 가지는 이들 끼리의 구분을 위해 이름을 부여하는 것을 의미한다. 즉, chart 설치는 특정한 chart 인스턴스를 만들어내는 것과 같은 것이고, 하나의 chart는 여러 installation(설치)이 있을 수 있는 것이다. helm install 명령어를 사용하여 chart에 대한 instance를 만들 때, 설치되는 chart 인스턴스에 대한 이름이 필요한 이유도 바로 여기있는 것이다.

helm install mysite bitnami/drupal
NAME: mysite
LAST DEPLOYED: Tue Jul  2 12:30:35 2024
NAMESPACE: default
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
CHART NAME: drupal
CHART VERSION: 18.21.12
APP VERSION: 10.3.0** Please be patient while the chart is being deployed **

1. Get the Drupal URL:

  NOTE: It may take a few minutes for the LoadBalancer IP to be available.
        Watch the status with: 'kubectl get svc --namespace default -w mysite-drupal'

  export SERVICE_IP=$(kubectl get svc --namespace default mysite-drupal --template "{{ range (index .status.loadBalancer.ingress 0) }}{{ . }}{{ end }}")
  echo "Drupal URL: http://$SERVICE_IP/"

2. Get your Drupal login credentials by running:

  echo Username: user
  echo Password: $(kubectl get secret --namespace default mysite-drupal -o jsonpath="{.data.drupal-password}" | base64 -d)

위의 명령어로 bitnami/drupal chart에 대한 인스턴스를 생성하고, 인스턴스 이름을 mysite로 지어놓은 것이다.

kubectl명령어로 잘 배포되었는 지 확인해보도록 하자.

kubectl get po
...
default         mysite-drupal-5b9d968694-v9q6v                              0/1     Pending     0          5m47s
default         mysite-mariadb-0                                            0/1     Pending     0          5m47s

Pending이 되어있는 것은 PV를 엮어주지 않아서 그런 것이다.

helm3부터는 namespace마다 이름을 같게 해주어도 문제가 없도록 되었다.

kubectl create ns first
kubectl create ns second
helm install --namespace first mysite bitnami/drupal
helm install --namespace second mysite bitnami/drupal

다음과 같이 mysite라는 chart instance이름은 같지만 namespace가 다르기 때문에 이들은 서로 다른 instance라고 구분이 가능한 것이다. 참고로 --namespace는 -n와 같다.

installation(또는 인스턴스) 설정

helm에서 약간 헷갈리게 개념을 잡은 것이 있는데, helm chart를 통해 설치한 인스턴스를 helm에서는 installation이라고 한다. 따라서, 필자는 일반적인 chart '설치'와 chart 설치 후 배포된 인스턴스를 installation으로 구분하겠다.

대부분의 chart들은 configuration들을 제공한다. https://artifacthub.io/packages/helm/bitnami/drupal drupal 역시도 parameter들을 제공하여 configuration에 용이함을 제공해준다. 가령 drupal admin account의 username을 설정하고 싶다면 drupalUsername 값을 설정하면 된다.

configuration을 설정하는 여러 방법들이 있지만, 가장 좋은 방법은 configuration을 설정하는 yaml파일을 만들어 제공하는 것이다.

  • values.yaml
drupalUsername: admin
drupalEmail: admin@example.com

이전에 chart는 configuration을 담고있는 values.yaml 파일이 함게 있다고 했다. 위의 values.yaml이 바로 chart에 대한 configuration data를 담고 있는 파일인 것이다. 위의 경우 drupalUsername와 drupalEmail을 설정하는 것이다.

해당 values.yaml 파일을 helm install시에 넘겨주기만 하면 되는 것이다.

helm install mysite bitnami/drupal --values values.yaml

이러한 configuration file은 구조화된 형식을 가질 수 있다. 가령, drupal에는 mariadb에 관련된 configuration이 있을 수 있는데, 이것이 drupal application에 관한 configuration과 섞이면 헷갈릴 수 있다. 따라서, 이들을 구분하도록 나누는 방법으로 구조화된 형식의 설정값을 쓰는 것이다.

drupalUsername: admin
drupalEmail: admin@example.com
mariadb:
  db:
    name: "my-database"

mariadb.db.name을 보도록 하자. 해당 data는 mariadb의 하위 configuration data라는 것이 눈에 들어온다. 이처럼, configuration value yaml파일은 구조화된 data를 가질 수 있는 것이다.

configuration을 설정하는 방법 중, 하나는 --set flag를 사용하는 방법이다. 이는 보통 values.yaml파일로 만들기에는 적은 내용의 수정이 필요할 때 사용한다.

helm install mysite bitnami/drupal --set drupalUsername=admin

위의 명령어는 단 하나의 parameter인 drupalUsername을 설정한 것이다. flag로 간단하게 key=value 형식을 지키기만하면 된다.

만약 mariadb.db.name과 같이 구조화된 configuration value에 접근하고 싶다면 --set mariadb.db.name=my-database에 접근하면 된다.

installations 목록

현재까지 설치한 helm chart 인스턴스(또는 installtions)를 보고 싶다면 helm list를 확인하면 된다.

helm list
NAME    NAMESPACE       REVISION        UPDATED                                 STATUS          CHART           APP VERSION
mysite  default         1               2024-07-02 12:30:35.838966423 +0900 KST deployed        drupal-18.21.12 10.3.0

조심해야할 것은 helm list도 namespace에 민감하게 반응한다는 것이다. 따라서 아무것도 안적어주면 default namespace로 나오게 된다. 만약 모든 namespace가 나오게 하고싶다면 --all-namespaces flag를 사용하면 된다. 또는 단축어로 -A를 사용하면 된다. 

helm list --all-namespaces
NAME    NAMESPACE  REVISION  UPDATED        STATUS     CHART         APP VERSION
mysite  default    1         2020-06-14...  deployed   drupal-7.0.0  9.0.0
mysite  first      1         2020-06-14...  deployed   drupal-7.0.0  9.0.0
mysite  second     1         2020-06-14...  deployed   drupal-7.0.0  9.0.0

Installation 삭제

Installation을 삭제하는 명령어는 간단하다.

helm uninstall mysite
release "mysite" uninstalled

helm uninstall시에 installation 이름만 필요하다는 것에 집중하도록 하자. 즉 chart에 대한 정보는 필요가 없다.

단, helm uninstall도 namespace의 영향을 받으므로 --namespace flag를 적용해야한다.

helm uninstall mysite --namespace first
release "mysite" uninstalled

Installation 업그레이드

위에서 helm은 helm chart를 통해서 배포된 인스턴스를 installation이라고 했다. installation은 cluster에 배포된 chart의 인스턴스이다. helm install을 사용하여 chart를 cluster에 설치하여 인스턴스인 installation을 만들 수 있는데, 만약 수정하고 싶다면 helm upgrade를 사용하면 된다.

installation을 업데이트하는 것은 두 가지 기준으로 구분될 수 있다.
1. chart의 version을 upgrade하기
2. installation의 설정을 upgrade하기

이 둘 중 하나라도 변한다면 upgrade된 것이다. 그러나 이 두 가지는 상호 배타적이지 않는데, 이 둘을 동시에 할 수 있다는 것이다. helm chart가 upgrade된 것을 release라고 한다. release는 installation의 configuration과 chart version 조합인 것이다.

첫번째 chart에 대한 installation을 release1이라고 하고, upgrade를 실행하고 나면 release2가 되는 것이다. upgrade가 된 사유가 version 때문인지 configuration 때문인지 둘 다 때문인지는 상관없다. upgrade만되면 release가 올라간다.

이제 upgrade를 사용해보도록 하자.

먼저 ingress 기능이 꺼진 version으로 설치해보도록 하자.

helm install mysite bitnami/drupal --set ingress.enabled=false

이제 ingress.enabled을 설정하기 위해서 helm upgrade를 실행해보도록 하자. 

helm upgrade mysite bitnami/drupal --set ingress.enabled=true

위의 upgrade 명령어로 configuration을 바꾼 것 뿐이다.

내부적으로 helm은 helm upgrade 시에 해당하는 configuration을 반영한 chart를 load하고 chart에 대한 kubernetes object를 만든다. 그리고서는 이전 version chart의 kubernetes object와 diff를 비교하고, 변화된 부분만 kubernetes에게 전달하여, 업데이트하도록 한다. 즉, upgrade했다고해서 안바뀐 부분도 또 업데이트하고 그런 것은 아니다.

만약, chart repository에서 특정 chart에 대한 새로운 version이 나온다면, 이를 받아서 upgrade하고 싶을 것이다. 이 두 과정을 cli로 보여준다.

helm repo update
ang tight while we grab the latest from your chart repositories...
...Successfully got an update from the "bitnami" chart repository
Update Complete. ⎈ Happy Helming!⎈

helm upgrade mysite bitnami/drupal
  1. helm repo update을 통해서 chart repository에서 최신 chart package를 다운받는다. 즉, 새로운 chart version이 추가된다.
  2. helm upgrade mysite bitnami/drupal을 통해서 mysite chart instance의 release를 최신 version으로 업데이트해준다.

만약 특정 version으로 바꾸고 싶다면, 다음과 같이 --version을 설정해주어 upgrade해주면 된다.

helm upgrade mysite bitnami/drupal --version 6.2.22

이 경우 새로운 version이 bitnami/drupal에 추가되어도 6.2.22가 설치된다.

upgrade시에 한 가지 조심해야할 점이 있는데, upgrade시에도 configuration value를 제공하여 default 설정값을 해치지 않는 것이 좋다.

helm install mysite bitnami/drupal --values values.yaml
helm upgrade mysite bitnami/drupal

처음에 install할 때 --values를 통해서 values.yaml 파일을 제공하였다. 이 values.yaml 파일 기준으로 configuration값들이 설정될 것이다. 문제는 helm upgrade를 실행하면서 새로운 version이 설치되고, 이전에 설정했던 values.yaml 설정이 적용되지 않는다는 것이다. 즉, 이전에 helm install 시에 적용했던 --values values.yaml이 적용되지 않는다는 것이다.

따라서, helm upgrade할 때도 --values values.yaml을 제공하는 것이 좋다.

helm install mysite bitnami/drupal --values values.yaml
helm upgrade mysite bitnami/drupal --values values.yaml

아래와 같은 helm upgrade에 --values values.yaml을 적용해도 새로운 version의 chart가 설치되고 values.yaml도 적용된다.

그런데 만약 --set으로만 configuration을 바꾸었다고 하자. 어떻게 이전에 적용했던 --set key-value값들을 다시 입력할 수 있을까?? 매우 귀찮은 일이다. 이를 위해서 helm에서는 이전 version의 configuration을 새로운 version에 자동 적용 시킬 수 있도록 하는 명령어가 있다.

helm upgrade mysite bitnami/drupal --reuse-values

--reuse-values flag는 helm에게 현재의 configuration values들에 대한 복사본을 만들어주고 이를 upgrade하는데 사용해달라는 것이다. 단, --reuse-values flag를 사용할 때는 반드시 --set이나 --values처럼 configuration을 바꾸는 명령어를 함께 써서는 안된다. 이는 원치 않은 버그나 configuration 충돌을 만들 수 있기 때문이다.

어떻게 helm은 release 정보를 저장할까?

우리가 helm install mysite bitnami/drupal을 만들었을 때 helm에서는 release 정보를 담은 특별한 record를 만들어내어 kubernetes secret에 저장해준다.

kubectl get secret으로 확인해보면 다음과 같다.

kubectl get secret
NAME                           TYPE                                  DATA   AGE
default-token-vjhx2            kubernetes.io/service-account-token   3      58m
mysite-drupal                  Opaque                                1      13m
mysite-mariadb                 Opaque                                2      13m
sh.helm.release.v1.mysite.v1   helm.sh/release.v1                    1      13m
sh.helm.release.v1.mysite.v2   helm.sh/release.v1                    1      13m
sh.helm.release.v1.mysite.v3   helm.sh/release.v1                    1      7m53s
sh.helm.release.v1.mysite.v4   helm.sh/release.v1                    1      5m30s

release 정보가 담긴 secret들이 생성된 것을 볼 수 있다. 이 release정보들은 helm install과 helm upgrade로 생성된 것들이다.

만약 helm uninstall mysite 명령어를 실행하면, 가장 최근 release를 받아와서 kubernetes object들을 만들고, 이를 cluster에서 삭제한다. 이 다음 모든 reelase record들을 삭제한다.

helm uninstall mysite
release "mysite" uninstalled

이후에 helm list 명령어로 mysite가 더 이상 없는 것을 볼 수 있다.

helm list
NAME    NAMESPACE       REVISION        UPDATED STATUS  CHART   APP VERSION

kubectl get secrets로 release를 확인해도 없는 것을 볼 수 있다.

kubectl get secrets
NAME                  TYPE                                  DATA   AGE
default-token-vjhx2   kubernetes.io/service-account-token   3      65m

이후에 helm rollback을 통해서 이전 release를 복구하는 것에 대해서 배우게 될 것이다. 그런데 secret이 모두 삭제되면 release들이 없으므로 helm rollback이 불가능하다. 따라서, helm uninstall시에 relase를 삭제하지 않도록 --keep-history flag를 추가할 수 있다. 

helm uninstall --keep-history
profile
놀고 싶은데, 왜 다들 공부하는거야
R3의 망령
이전 포스트

helm을 배워보자 2일차 - Charts 기본

다음 포스트

helm을 배워보자 4일차 - 디버깅과 release, rollback

0개의 댓글