Kustomize로 버티다가 Helm으로 갈아탄 이유

처음에 Kubernetes 배포를 잡을 때는 최대한 단순하게 가고 싶어서 Kustomize를 썼다.

멀티모듈 구조긴 했는데 실제로 배포하는 건 몇 개 안 됐고, 환경도 dev / prod 정도만 나누면 충분한 상황이었다.

이미 deployment.yaml, service.yaml 같은 기본 리소스도 다 있었어서 base 만들어두고 overlays에서 replica나 env, image만 바꿔주면 끝이었다.

이때는 진짜 별 생각 없었다.
이 정도면 충분히 깔끔하고, 굳이 Helm까지 써야 할 이유가 없다고 느꼈다.

예를 들어 초반에는 이런 식이면 충분했다.

# base/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-server
spec:
  replicas: 1
  selector:
    matchLabels:
      app: app-server
  template:
    metadata:
      labels:
        app: app-server
    spec:
      containers:
        - name: app-server
          image: example/app-server:latest
          ports:
            - containerPort: 8080

그리고 prod에서는 필요한 것만 patch로 바꿨다.

# overlays/prod/replica-patch.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-server
spec:
  replicas: 3

이 단계에서는 이게 제일 편했다.

근데 프로젝트 진행하면서 상황이 조금씩 바뀌기 시작했다.

모니터링도 붙여야 하고, 나중에 서비스도 더 늘어날 것 같고, 구조도 점점 커질 느낌이 들었다.

처음에는 그냥 “그때 가서 생각하면 되지” 이 정도였다.

근데 실제로 서비스 하나씩 추가하는 걸 생각해보니까 느낌이 달라졌다.

예를 들어 이런 식으로 늘어난다고 하면

api-server

worker-server

batch-server

notification-server

결국 deployment를 또 만들어야 한다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-server
spec:
  replicas: 1
  selector:
    matchLabels:
      app: api-server
  template:
    metadata:
      labels:
        app: api-server
    spec:
      containers:
        - name: api-server
          image: example/api-server:latest
          ports:
            - containerPort: 8080

apiVersion: apps/v1
kind: Deployment
metadata:
  name: worker-server
spec:
  replicas: 1
  selector:
    matchLabels:
      app: worker-server
  template:
    metadata:
      labels:
        app: worker-server
    spec:
      containers:
        - name: worker-server
          image: example/worker-server:latest
          ports:
            - containerPort: 8081

처음에는 그냥 이렇게 추가하면 되는 줄 알았다.

근데 몇 개 쌓이고 나니까 보이더라. 구조는 거의 똑같은데 이걸 계속 복붙하면서 만들고 있는 게 맞나 싶었다.

Kustomize로도 물론 관리가 되긴 한다. base 나누고 patch 잘 쪼개면 된다.

근데 근본적으로는 서비스가 늘어날수록 YAML도 같이 늘어난다.

이건 피할 수가 없었다.

여기서 생각이 조금 바뀌었다.

처음에는 Kustomize가 편해서 쓴 건데, 지금 구조에서는 그 편함이 오히려 한계처럼 느껴졌다.

그래서 이걸 해결할 방법이 없을까 싶어서 Helm을 다시 봤다.

Helm은 아예 접근 방식이 달랐다.

기존처럼 YAML을 들고 가는 게 아니라, 템플릿 하나 만들어두고 값만 바꿔서 찍어내는 구조였다.

예를 들면 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만 따로 주면 된다.

name: api-server
replicaCount: 2

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

service:
  port: 8080

이걸 보고 나니까 지금 내가 하고 있는 방식이랑 비교가 확 됐다.

아예 템플릿 하나로 구조를 잡고 값만 바꿔서 쓰는 방식이라 지금 상황에는 이게 더 맞는 구조라는 생각이 들었다.

그래서 바꿨다기보다, 그냥 지금 구조에서는 Helm 쓰는 게 더 자연스럽다는 느낌이었다.

정리해보면 내가 느낀 차이는 이거였다.

Kustomize는 이미 있는 YAML을 기준으로 필요한 부분만 바꿔가면서 쓰는 방식이라 구조가 단순하고, 환경만 나눌 때는 진짜 편하다.

반면 Helm은 아예 템플릿을 만들어두고 값만 바꿔서 찍어내는 방식이라 같은 구조의 서비스가 계속 늘어나는 상황에서 훨씬 편하다.

그래서 지금 기준에서는 Kustomize로 계속 버티는 것보다 Helm으로 정리하는 게 훨씬 편한 구조였다.

결국 지금 상황에서는 Helm이 더 맞는 선택이었다.