Helm3 Chart 커스터마이징

"Helm Chart를 활용하여 MSA 기반의 복잡하고 많은 yaml 파일들을 관리하는 것은 당연하면서도 필수적인 방법이다. 이를 통해 유연한 변경관리, 버전관리, 즉각 대응, 가독성 향상, 불필요한 설정 파일 최소화 등 많은 이점을 가져갈 수 있다."

앞선 포스팅에서는 Helm3를 이용한 다양한 CLI 명령어 활용법과 Kubernetes에 배포하는 방법에 대해 알아보았다. 다시한번 확인하고 할 경우 다음을 참조한다.

 

Helm3 기본 명령어 확인 및 Kubernetes deploy

 

이번 포스팅에서는 Helm 기반 실제 프로젝트 환경에서 chart를 관리하는 과정에 대해 본격적으로 살펴보도록 하자.

 helm chart 생성 

chart를 생성하는 방법은 크게 2가지 방법이 있다.

하나는 helm create를 이용하는 방법과 직접 파일을 작성하는 방법이다. 개인적으로는 helm create로 기본 template 형태를 만들고 deployment.yaml 파일을 작성한 후 이를 기반으로 chart에 덮어쓰는 형태를 선호한다.

그럼 본격적으로 chart를 생성해 보자.

1) helm create

[root@kubemaster helm]# helm create son-helm-chart
Creating son-helm-chart
[root@kubemaster helm]# cd son-helm-chart/
[root@kubemaster son-helm-chart]# ls
charts  Chart.yaml  templates  values.yaml
[root@kubemaster son-helm-chart]#

위와 같이 helm create [chart_name] 형태로 helm chart를 생성한다. chart를 초기 생성하면 기본 Template 형태의 구조를 제공하며, 위와 같이 chart 디렉토리와 Chart.yaml 파일 templates 디렉토리와 values.yaml 파일로 구성된다.

각 디렉토리는 다음과 같은 역할을 한다.

 

- chart_template : 최상위 디렉토리로 실제 chart의 단위가 되는 디렉토리이다.

- templates : templates 하위에 deployement.yaml, service.yaml과 같은 실제 배포에 사용할 yaml 파일을 저장한다. Origin 그대로의 파일이 아닌 변수처리가 되어 있어야 values.yaml에서 처리할 수 있다.

- Chart.yaml : helm chart에 대한 version, writer, description, chart name 등을 정의하는 meta 파일이다.

- values.yaml : templates 디렉토리 하위의 yaml 파일들이 참조하여 template을 실제 yaml 파일 형태로 생성하는데 사용되는 parameter를 저장하는 yaml 파일이다.

 

2) templates/deployment.yaml 작성

다음으로 실제 배포하기 위해 작성한 deployment.yaml 파일을 작성해 보도록 하자.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ .Values.name}}-deployment
  labels:
    app: {{ .Values.label}}
spec:
  replicas: {{ .Values.replicas}}
  selector:
    matchLabels:
      app: {{ .Values.label}}
  template:
    metadata:
      labels:
        app: {{ .Values.label}}
    spec:
      containers:
      - name: wildfly
        image: {{ .Values.image}}
        imagePullPolicy: Always
        ports:
        - containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
  name: {{ .Values.name}}
spec:
  selector:
    app: {{ .Values.label}}
  ports:
    - protocol: TCP
      port: 8080
      targetPort: 8080
  type: ClusterIP
---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: {{ .Values.name}}-ingress
  namespace: default
spec:
  rules:
  - host: {{ .Values.name}}.godnr.co.kr
    http:
      paths:
      - backend:
          serviceName: {{ .Values.name}}
          servicePort: 8080
        path: /

파일은 deployment 하나로 관리되거나, (--- 로 구분) deployment.yaml, service.yaml, ingress.yaml로 구분하여 파일을 정의할 수도 있다.

위 파일은 deployment / service / ingress가 함께 정의되어 있는 배포를 위한 yaml이다.

위 파일의 특징을 보자면 바로 {{ .Values.xxxx}} 형태의 변수처리라 할 수 있다. 해당 정보는 values.xml 파일과 매칭되어 실제 배포 시점에 하나의 yaml이 완성되도록 구현된다.

위에는 크게 4개의 변수가 지정되어 있다.

- {{ .Values.name}} : Service Name을 위한 변수

- {{ .Values.label}} : Node 배치를 위한 Selector, Label 변수

- {{ .Values.replicas}} : Replicas를 위한 변수

- {{ .Values.image}} : Image를 위한 변수

위 4가지 변수는 다음과 같이 values.yaml 파일에서 정의된다.

 

3) values.yaml

name: "hellohelm"
replicas: 2
label: wildfly
image: "192.168.1.100:13000/godnr/wildfly:latest"

앞서 살펴본 templates/deployment.yaml에 정의된 4가지 변수가 다음과 같의 처리되도록 구성한다.

이와 같이 구성 후 정상적으로 사용 가능한 상태인지 점검하는 두가지 스탭을 진행하게 된다.

 helm chart 검증 

검증 과정은 두가지 스탭으로 관리되며, 첫번째 chart를 lint로 검사하는 단계와 chart의 template을 눈으로 확인하는 단계이다.

1) helm lint

먼저 Chart.yaml 파일이 위치하는 디렉토리로 이동 후 helm lint를 입력한다.

[root@kubemaster chart_template]# helm lint
==> Linting .
[INFO] Chart.yaml: icon is recommended

1 chart(s) linted, 0 chart(s) failed
[root@kubemaster chart_template]# 

helm lint를 통해 template의 상태를 검증하고 Chart를 생성할 준비가 완료되었는지 검증한다.

다음은 Chart.yaml 파일이 존재하지 않을 경우 발생하는 오류의 예시이다.

[root@kubemaster chart_template]# helm lint
==> Linting .
Error unable to check Chart.yaml file in chart: stat Chart.yaml: no such file or directory

Error: 1 chart(s) linted, 1 chart(s) failed
[root@kubemaster chart_template]#

2) helm template

helm template은 templates/deployment.yaml과 values.yaml 파일의 조합으로 실제 생성하고자 했던 yaml 파일이 정상적으로 구성되는지 검증하는 단계이다.

[root@kubemaster ~]# helm template ./son-helm-chart/
---
# Source: son-helm-chart/templates/service.yaml
apiVersion: v1
kind: Service
metadata:
  name: hellohelm
spec:
  selector:
    app: wildfly
  ports:
    - protocol: TCP
      port: 8080
      targetPort: 8080
  type: ClusterIP

---
# Source: son-helm-chart/templates/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: hellohelm-deployment
  labels:
    app: wildfly
spec:
  replicas: 2
  selector:
    matchLabels:
      app: wildfly
  template:
    metadata:
      labels:
        app: wildfly
    spec:
      containers:
      - name: wildfly
        image: 192.168.1.100:13000/godnr/wildfly:latest
        imagePullPolicy: Always
        ports:
        - containerPort: 8080

---
# Source: son-helm-chart/templates/ingress.yaml
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: hellohelm-ingress
  namespace: default
spec:
  rules:
  - host: hellohelm.godnr.co.kr
    http:
      paths:
      - backend:
          serviceName: hellohelm
          servicePort: 8080
        path: /

[root@kubemaster ~]# 

위와 같이 출력되면 deployment 파일이 정상적으로 생성되었음을 알 수 있다.

 helm chart multi service 관리 

현재까지 helm chart를 커스터마이징하여 나만의 Chart를 생성할 수 있도록 구성해 보았다.

지금부터 알아 볼 내용은 helm chart 하나를 여러 서비스에서 사용하고자 할 경우 어떻게 적용할 것인지에 대한 내용이다.

사실 Chart라는 단위가 비슷한 형태의 yaml 파일을 여러 군데 두지 않고 template을 생성하여 관리하자는 의미에서 생성되었으며, 비슷한 서비스가 Naming이나 docker image url 정보만 바뀌는 수준에서 재사용 되고 있다면 그 서비스들을 하나의 Chart로 묶어 관리할 수 있다.

먼저 생성한 Chart를 기반으로 install을 진행해 보고 그 다음 multi service 환경을 구성해 보도록 하자.

1) helm install

앞선 포스팅에서는 기 구성되어 있는 helm repo / helm hub를 통해 install을 진행했지만, 이번에는 직접 구성한 helm repo를 install 해보도록 핮자.

사실 크게 다른 점은 없다.

[root@kubemaster helm]# helm install hellohelm ./chart_template
NAME: hellohelm
LAST DEPLOYED: Wed Jul 22 21:18:42 2020
NAMESPACE: default
STATUS: deployed
REVISION: 1
TEST SUITE: None
[root@kubemaster helm]# helm ls
NAME    NAMESPACE       REVISION        UPDATED                                 STATUS          CHART           APP VERSION
hellohelm     default         1               2020-07-22 21:18:42.414202661 +0900 KST deployed        hellohelm-chart-0.1.0 1.16.0
[root@kubemaster helm]# 

위와 같이 생성한 chart_template을 기반으로 install을 진행한다. 성공적으로 install되면 helm ls에서 조회가 가능하며, 다음과 같이 kubernetes 환경에서 deploy 된것을 확인할 수 있다.

[root@kubemaster helm]# kubectl get pods
NAME                                        READY   STATUS    RESTARTS   AGE
hellohelm-deployment-6f9d955df5-4tz8k             1/1     Running   0          15m
hellohelm-deployment-6f9d955df5-qv5ww             1/1     Running   0          15m
[root@kubemaster helm]#

2) multi service 구성 방안

마지막으로 살펴볼 내용은 multi service에서 과연 어떻게 관리할 것인가에 대해 알아보도록 하자.

거창하게 말했지만, values.yaml 파일을 여러개로 분할하여 관리하는 수준으로 손쉽게 서비스 환경을 추가할 수 있다.

개인적으로 사용하는 디렉토리 구조는 다음과 같다.

 

바로 위와 같이 chart_template이라는 heml chart와 동일한 경로에 values.yaml 파일을 각 서비스 name을 포함한 naming으로 각각 추가하여 관리하는 것이다.

각각의 values.yaml 파일은 다음과 같은 형태가 될 것이다.

[hellohelm-values.yaml]
name: "hellohelm"
replicas: 2
label: wildfly
image: "192.168.1.100:13000/godnr/wildfly:latest"

[hihelm-values.yaml]
name: "hihelm"
replicas: 2
label: wildfly
image: "192.168.1.100:13000/godnr/wildfly-hihelm:latest"

위와 같이 values.yaml이 구성되면 두개의 서비스에서 각각 templates/deployment.yaml 파일에 value를 대입하여 deploy 하기 위한 개별의 yaml 파일이 생성되는 형태이다.이렇게 value.yaml 파일의 naming을 변경하여 관리할 경우에는 다음과 같이 -f 옵션을 함께 사용한다.

[root@kubemaster helm]# helm install -f hellohelm-values.yaml hellohelm chart_template/
NAME: hellohelm
LAST DEPLOYED: Wed Jul 22 22:36:06 2020
NAMESPACE: default
STATUS: deployed
REVISION: 1
TEST SUITE: None
[root@kubemaster helm]# helm install -f hihelm-values.yaml hihelm chart_template/
NAME: hihelm
LAST DEPLOYED: Wed Jul 22 22:36:34 2020
NAMESPACE: default
STATUS: deployed
REVISION: 1
TEST SUITE: None
[root@kubemaster helm]# 

위와 같이 배포된 서비스는 다음과 같이 확인할 수 있다.

[root@kubemaster chart]# helm ls
NAME    NAMESPACE       REVISION        UPDATED                                 STATUS          CHART           APP VERSION
hellohelm     default         1               2020-07-22 22:36:06.690434987 +0900 KST deployed        hellohelm-chart-0.1.0 1.16.0
hihelm     default         1               2020-07-22 22:36:34.243361296 +0900 KST deployed        hellohelm-chart-0.1.0 1.16.0
[root@kubemaster chart]# kubectl get pods
NAME                                        READY   STATUS             RESTARTS   AGE
hellohelm-deployment-66c5659d4d-kpl7h             1/1     Running                0          32s
hellohelm-deployment-66c5659d4d-wnbzp             1/1     Running                0          32s
hihelm-deployment-5fc7f66d5d-4sg5t             1/1     Running                0          12s
hihelm-deployment-5fc7f66d5d-wwz8q             1/1     Running                0          12s
[root@kubemaster chart]#

3) 서비스 upgrade 방안

Helm을 사용할 경우 편의성을 두가지로 들자면 그 중 하나가 yaml 파일 커스터마이징 용이성과 바로 Revision 관리의 용이성을 들 수 있다.

yaml 파일의 변경 시 기존에는 revision을 관리하기 위해 파일 백업하거나 git history를 기반으로 하나하나 확인해서 적용해야 했지만, heml은 이와 같은 과정을 간편화할 수 있도록 기능을 제공한다.

바로 helm history 기능과 helm upgrade 기능의 조합으로 구현할 수 있다.

[root@kubemaster chart]# helm install -f hellohelm-values.yaml hellohelm chart_template/
NAME: hellohelm
LAST DEPLOYED: Thu Jul 23 23:28:45 2020
NAMESPACE: default
STATUS: deployed
REVISION: 1
TEST SUITE: None
[root@kubemaster chart]# helm ls
NAME    NAMESPACE       REVISION        UPDATED                                 STATUS          CHART                   APP VERSION
hellohelm     default         1               2020-07-23 23:28:45.175318798 +0900 KST deployed        wildfly-chart-0.1.0     1.16.0
[root@kubemaster chart]# helm history hellohelm
REVISION        UPDATED                         STATUS          CHART                   APP VERSION     DESCRIPTION
1               Thu Jul 23 23:28:45 2020        deployed        wildfly-chart-0.1.0     1.16.0          Install complete
[root@kubemaster chart]# kubectl get pods
NAME                                            READY   STATUS    RESTARTS   AGE
hellohelm-deployment-6f9d955df5-jrrmm                 1/1     Running   0          56s
hellohelm-deployment-6f9d955df5-zp2ld                 1/1     Running   0          56s
[root@kubemaster chart]# 

먼저 위와 같이 다시한번 heml install을 통해 hellohelm을 배포해 보도록 하자. hellohelm을 배포하면 몇가지 info 성 정보가 출력되는 이때 초기 배포 정보는 revision 1로 표출되는 것을 확인할 수 있다. helm history hellohelm을 입력하면 revision의 세부항목을 확인할 수 있다.

다음으로 hellohelm-values.yaml 파일의 replica를 기존 2에서 4로 변경한다.

name: "hellohelm"
replicas: 4
label: wildfly
image: "192.168.1.100:13000/godnr/wildfly:latest"

위와 같이 변경 후 helm upgrade 명령어를 통해 hellmhelm chart를 upgrade 해 보도록 하자.

helm upgrade의 형식은 다음과 같다.

[helm upgrade -f [values_file_name] [chart_name] [chart_templae_path] --description [description_text]]

[root@kubemaster chart]# helm upgrade -f hellohelm-values.yaml hellohelm chart_template --description replicas4
Release "hellohelm" has been upgraded. Happy Helming!
NAME: hellohelm
LAST DEPLOYED: Thu Jul 23 23:30:36 2020
NAMESPACE: default
STATUS: deployed
REVISION: 2
TEST SUITE: None
[root@kubemaster chart]# helm history hellohelm
REVISION        UPDATED                         STATUS          CHART                   APP VERSION     DESCRIPTION
1               Thu Jul 23 23:28:45 2020        superseded      wildfly-chart-0.1.0     1.16.0          Install complete
2               Thu Jul 23 23:30:36 2020        deployed        wildfly-chart-0.1.0     1.16.0          replicas4
[root@kubemaster chart]#

위와 같이 helm upgrade를 진행하면 변경된 value 정보로 chart가 수정 반영되며, revision 2로 기록된다. 이때 이후 rollback 반영 정보를 확인하기 위해 반드시 description을 기입해 주는 것을 권고한다.

다음과 같이 실제 kubernetes 상에도 변경된 chart의 정보가 반영된다.

[root@kubemaster chart]# kubectl get pods
NAME                                            READY   STATUS    RESTARTS   AGE
hellohelm-deployment-6f9d955df5-597z7                 1/1     Running   0          16s
hellohelm-deployment-6f9d955df5-b8xkg                 1/1     Running   0          16s
hellohelm-deployment-6f9d955df5-jrrmm                 1/1     Running   0          2m7s
hellohelm-deployment-6f9d955df5-zp2ld                 1/1     Running   0          2m7s
[root@kubemaster chart]# 

위와 같이 4개의 pod가 기동된 것을 확인할 수 있다.

4) 서비스 rollback 방안

다음으로 변경된 상태를 이전으로 rollback하는 과정을 살펴보자. rollback 역시 helm history와 helm rollback의 조합으로 실행할 수 있다.

앞서 살펴본 revision 1, 2를 기반으로 현재 revision 2가 반영되어 총 4개의 pod가 적용되어 있는 상태이다.

먼저 revision 정보를 다시한번 살펴보자.

[root@kubemaster chart]# helm history hellohelm
REVISION        UPDATED                         STATUS          CHART                   APP VERSION     DESCRIPTION
1               Thu Jul 23 23:28:45 2020        superseded      wildfly-chart-0.1.0     1.16.0          Install complete
2               Thu Jul 23 23:30:36 2020        deployed        wildfly-chart-0.1.0     1.16.0          replicas4
[root@kubemaster chart]#

위와 같이 총 2개의 revision이 관리되고 있다.

rollback을 위한 helm rollback은 다음과 같은 형태로 동작한다.

[helm rollback [chart_name] [revision_number]]

[root@kubemaster chart]# helm rollback hellohelm 1
Rollback was a success! Happy Helming!
[root@kubemaster chart]#

위와 같은 Rollback aws a success! Happy Helming! 메시지와 함께 revision에 따른 rollback이 진행된다.

[root@kubemaster chart]# helm history hellohelm
REVISION        UPDATED                         STATUS          CHART                   APP VERSION     DESCRIPTION
1               Thu Jul 23 23:28:45 2020        superseded      wildfly-chart-0.1.0     1.16.0          Install complete
2               Thu Jul 23 23:30:36 2020        superseded      wildfly-chart-0.1.0     1.16.0          replicas4
3               Thu Jul 23 23:32:47 2020        deployed        wildfly-chart-0.1.0     1.16.0          Rollback to 1
[root@kubemaster chart]# kubectl get pods
NAME                                            READY   STATUS        RESTARTS   AGE
hellohelm-deployment-6f9d955df5-597z7                 1/1     Running       0          2m25s
hellohelm-deployment-6f9d955df5-b8xkg                 1/1     Terminating   0          2m25s
hellohelm-deployment-6f9d955df5-jrrmm                 1/1     Running       0          4m16s
hellohelm-deployment-6f9d955df5-zp2ld                 1/1     Terminating   0          4m16s
[root@kubemaster chart]#

rollback 역시 하나의 revision으로 관리되어 3번으로 추가되었으며, rollback은 실행 즉시 동작하여, 위와 같이 Pod가 4개에서 2개가 Teminating 되는 것을 확인할 수 있다.

"Helm Chart를 활용하여 중복되는 deployment를 하나의 template 형태로 관리할 수 있으며, 그 용도에 따라 values.yaml 파일 만을 정의하여 손쉽게 추가 제거 할 수 있다. 이와 같은 chart를 저장하는 저장소 역시 필요시 추가하여 관리되어야 하며, 이는 이후 포스팅에서 다시 살펴보도록 하자."