Kustomize에서 Helm으로 넘어간 이후, Helm chart 구조 정리

Kustomize를 쓰다가 Helm으로 넘어간 이유를 정리했는데, 막상 Helm을 쓰려고 보니까 구조를 어떻게 잡아야 할지가 제일 고민이었다.
chart를 서비스마다 나눌지, 아니면 하나로 묶을지부터 시작해서 values를 어떻게 분리할지도 생각보다 애매했다.
그래서 실제로 쓰면서 정리한 구조를 남겨본다.

처음에는 서비스마다 chart를 하나씩 만드는 것도 고민했다.

api-server chart

worker-server chart

batch-server chart

이런 식으로. 근데 이건 생각해보니까 결국 Kustomize 때랑 크게 다를 게 없었다.
구조는 비슷한데 chart만 계속 늘어나는 느낌이라 이건 아닌 것 같았다.

그래서 방향을 바꿨다.
결론부터 말하면 구조는 최대한 단순하게 가져갔다.

template은 하나로 두고, 서비스별 차이는 values로만 분리하는 방식이다.

처음에는 chart를 서비스마다 나누는 것도 고민했는데, 그렇게 하면 결국 구조가 계속 복제되는 느낌이라 하나로 묶는 쪽이 더 맞다고 판단했다.

chart 구조

최종적으로는 이런 구조로 잡았다.

helm/
  app/
    Chart.yaml
    values.yaml
    templates/
      deployment.yaml
      service.yaml

핵심은 단순하다.

template은 하나로 두고, values만 바꿔서 여러 서비스를 배포하는 구조다.

deployment 템플릿

deployment는 최대한 공통 구조만 남기고 템플릿으로 만들었다.

여기서는 서비스별 로직을 넣지 않고 어떤 서비스든 공통으로 쓸 수 있는 구조만 남겼다.

# templates/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ .Values.name }}
spec:
  replicas: {{ .Values.replicaCount }}
  selector:
    matchLabels:
      app: {{ .Values.name }}
  template:
    metadata:
      labels:
        app: {{ .Values.name }}
    spec:
      containers:
        - name: {{ .Values.name }}
          image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
          ports:
            - containerPort: {{ .Values.service.port }}

values 분리 전략

처음에는 values.yaml 하나에 다 넣으려고 했는데 이건 금방 복잡해진다.

그래서 서비스별로 values를 아예 분리했다.

서비스를 추가할 때마다 YAML을 만드는 게 아니라, values 파일 하나 추가하는 구조로 바뀐 게 제일 컸다.

# values-api.yaml
name: api-server
replicaCount: 2

image:
  repository: example/api-server
  tag: "1.0.0"

service:
  port: 8080

# values-worker.yaml
name: worker-server
replicaCount: 1

image:
  repository: example/worker-server
  tag: "1.0.0"

service:
  port: 8081

CI/CD에서 사용 방식

CI/CD에서는 이 구조를 그대로 사용했다.

이미지 빌드가 끝나면 서비스별로 values만 바꿔서 배포했다. 이렇게 하면 chart는 그대로 두고 서비스별 설정만 바꿔서 배포할 수 있다.

helm upgrade --install api ./helm/app -f values-api.yaml

쓰면서 느낀 점

이전에는 Kustomize로 배포하면서 YAML을 계속 추가하는 느낌이 강했다.
서비스가 늘어날수록 파일도 같이 늘어나고, 관리 포인트도 같이 늘어났다.

반면 Helm으로 바꾸고 나서는 구조를 하나로 묶고 재사용하는 느낌이 강해졌다.

특히 서비스 추가할 때 차이가 확 느껴졌다.

예전에는

deployment 하나 더 만들고

service 만들고

patch 나누고

이런 흐름이었다면 지금은 values 파일 하나 추가하고 끝 이게 생각보다 훨씬 편했다.

이전에 정리했던 것처럼 Kustomize는 구조가 단순할 때는 편했지만, 서비스가 늘어나기 시작하면서 반복이 많아지는 게 부담이 됐다.

Helm으로 넘어오고 나서는 그 반복되는 부분을 템플릿으로 묶을 수 있어서 지금 구조에서는 훨씬 관리하기 편해졌다.

아직 더 다듬을 부분은 있지만, 적어도 서비스가 늘어나는 상황에서는 이 구조가 더 잘 맞는 느낌이었다.