[쿠버네티스 패턴] 22장 Configuration Template

bocopile·2025년 12월 27일

쿠버네티스 패턴

목록 보기

20/28

안녕하세요.

이번 글에서는 Kubernetes Patterns 책의 22장 Configuration Template 패턴을 중심으로,

Kubernetes v1.35 기준 최신 트렌드와 실무 패턴까지 포함하여 하나의 흐름으로 정리해 보겠습니다.

21장 Immutable Configuration이

“시간에 따라 변경되는 설정을 어떻게 안전하게 관리할 것인가”

에 대한 이야기였다면,

22장 Configuration Template는 다음 질문에 답합니다.

“같은 애플리케이션을 서로 다른 환경(dev / staging / prod)에
어떻게 중복 없이, 그리고 일관되게 배포할 것인가?”

1. Configuration Template 패턴의 배경과 문제 정의 (Why)

Kubernetes 환경에서는 동일한 애플리케이션을 여러 환경에 배포하는 것이 일반적입니다.

하지만 환경이 늘어날수록 설정 관리는 급격히 어려워집니다.

1.1 설정 복사의 함정

많은 팀이 처음에는 다음과 같은 방식으로 시작합니다.

dev, staging, prod YAML 파일을 복사해서 관리
환경별 차이를 반영하기 위해 파일을 개별 수정
급한 수정은 특정 환경에만 반영

그 결과:

어떤 설정이 왜 다른지 추적하기 어려워지고
특정 환경에서만 발생하는 장애가 늘어나며
변경 사항을 모든 환경에 동일하게 반영하기가 점점 어려워집니다.

2. Configuration Drift의 또 다른 형태

21장에서의 Configuration Drift는 Git과 클러스터 상태의 불일치였습니다.

22장에서 다루는 Drift는 다음과 같습니다.

환경 간 Configuration Drift

즉, dev와 prod의 설정 차이가

의도된 차이인지
실수로 누락된 차이인지

구분할 수 없는 상태입니다.

Configuration Template 패턴은 이 환경 간 Drift를 구조적으로 예방하기 위한 접근입니다.

3. Configuration Template 패턴의 핵심 개념 (How)

Configuration Template 패턴의 핵심은 다음 한 문장으로 요약됩니다.

공통 설정은 하나의 템플릿으로 유지하고, 환경별 차이(Variance)만 외부에서 주입한다.

이를 통해 다음을 달성합니다.

YAML 중복 제거
환경별 차이의 명시화
변경 범위 최소화
리뷰와 테스트 용이성 향상

4. 책에서 설명하는 Configuration Template 구현 방식

4.1 Placeholder 기반 템플릿

가장 단순한 방식은 YAML 내부에 placeholder를 두는 것입니다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: {{REPLICAS}}

배포 시점에 스크립트나 CI/CD 파이프라인에서 값을 치환합니다.

장점

이해하기 쉬움
도구 의존성 낮음

단점

타입 검증 불가
템플릿 오류를 배포 전까지 알기 어려움
규모가 커질수록 유지보수 어려움

4.2 Helm 기반 Configuration Template

Helm은 Kubernetes에서 가장 널리 사용되는 템플릿 엔진입니다.

replicaCount: 3
image:
  tag: "1.0.0"

장점

강력한 템플릿 기능 (조건문, 반복문)
패키징과 버전 관리에 강점
외부 사용자에게 배포하기에 적합

단점

Go Template 문법 학습 필요
로직이 많아질수록 가독성 저하
렌더링 결과를 보기 전까지 실제 리소스 파악이 어려움

4.3 Kustomize 기반 Configuration Template

Kustomize는 “YAML을 그대로 유지하면서 차이만 덧붙인다”는 철학을 가집니다.

base/
  deployment.yaml
overlays/
  dev/
  staging/
  prod/

장점

원본 YAML 유지
Git diff가 매우 명확
선언적이며 GitOps 친화적

단점

복잡한 로직 표현에는 한계
Helm만큼의 유연성은 없음

5. Helm vs Kustomize: 경쟁이 아닌 역할 분담 (Tools)

실무에서는 Helm과 Kustomize를 배타적 선택이 아니라 상호 보완적 도구로 봅니다.

관점별 비교

구분	Helm	Kustomize
철학	템플릿 엔진	오버레이 엔진
강점	패키징, 복잡한 로직	가독성, 선언성
주 사용처	남에게 배포할 때	내가 운영할 때
Git Diff	불리	매우 유리

하이브리드 패턴 (Inflate & Patch)

최근 가장 많이 사용되는 패턴은 다음과 같습니다.

Helm으로 외부 벤더 차트를 렌더링 (helm template)
Kustomize로 우리 팀의 설정만 덮어쓰기 (patches)

이 방식은 두 도구의 장점만 취하는 현실적인 전략입니다.

6. Kubernetes v1.35 기준: 템플릿 관리의 진화

6.1 Helm OCI Registry (Artifact로서의 차트)

Helm v3.8+부터 차트는 OCI Artifact로 표준화되었습니다.

helm package my-chart
helm push my-chart-0.1.0.tgz oci://public.ecr.aws/my-org/

컨테이너 이미지와 동일한 Registry(ECR, Harbor 등)에 저장
동일한 보안 정책과 접근 제어 적용
마치 docker push 하듯이 차트를 관리할 수 있습니다.

이는 21장의 Immutable Configuration에서 말한 Artifact 중심 관리 철학과 자연스럽게 연결됩니다.

6.2 ArgoCD ApplicationSet (대규모 환경 관리)

환경이 3개가 아니라 50개, 100개라면 Kustomize 오버레이 폴더를 모두 만들어야 할까요?

ArgoCD ApplicationSet은 이 문제를 해결합니다.

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
spec:
  generators:
  - list:
      elements:
      - cluster: engineering-dev
        url: <https://1.2.3.4>
      - cluster: engineering-prod
        url: <https://5.6.7.8>
  template:
    metadata:
      name: '{{cluster}}-guestbook'
    spec:
      destination:
        server: '{{url}}'

이 설정 하나로 수십 개의 클러스터 배포를 한 번에 자동화할 수 있습니다.

ApplicationSet은 Configuration Template 패턴의 자동화된 최종 형태라 할 수 있습니다.

6.3 Helm + Kustomize 하이브리드 패턴 (시각화)

Helm: 복잡한 외부 차트 처리
Kustomize: 내부 정책 반영
GitOps: 배포 자동화

도구를 고르는 것이 아니라, 조합하는 시대입니다.

6.4 CUE (Configure, Unify, Execute) – 타입 기반 Configuration Template

6.4.1 CUE가 해결하려는 문제 (Why CUE?)

기존 템플릿 도구는 다음과 같은 한계를 가집니다.

Helm: 텍스트 치환 → 문법/들여쓰기 오류에 취약
Kustomize: 단순 패치 → 복잡한 로직 표현 어려움

YAML은 사람이 읽기 쉽지만, 기계가 검증하기엔 너무 유연합니다.

port: "8080"   # 문자열
port: 8080     # 숫자

이 차이는 실행 시점에서야 장애로 드러납니다.

CUE는 이를 “프로그래밍 언어 수준의 타입 시스템”으로 해결합니다.

타입(Schema)이 곧 값(Value)이고, 값(Value) 또한 타입(Type)이다.

정의와 검증이 동시에 수행됩니다.

6.4.2 핵심 기능: 타입 기반 템플릿 (Type-safe Templating)

Helm처럼 텍스트 템플릿을 사용하지 않고,

JSON 상위 집합 문법으로 구조화된 설정을 정의합니다.

예시 시나리오

모든 Deployment는 app 레이블 필수
replicas는 최소 1 이상

CUE 코드 예시 (`deployment.cue`)

// 1. 스키마 정의 (템플릿 역할)
#MyDeployment: {
    apiVersion: "apps/v1"
    kind:       "Deployment"

    metadata: {
        name: string
        labels: {
            app: name
            tier: "frontend" | "backend"
        }
    }

    spec: {
        replicas: int & >=1
        template: {
            spec: {
                containers: [...{
                    name:  metadata.name
                    image: string
                }]
            }
        }
    }
}

// 2. 실제 데이터 주입
prod: #MyDeployment & {
    metadata: name: "payment-service"
    metadata: labels: tier: "backend"
    spec: replicas: 3
    spec: template: spec: containers: [{image: "pay-v1"}]
}

dev: #MyDeployment & {
    metadata: name: "payment-service-dev"
    metadata: labels: tier: "backend"
    spec: replicas: 1
    spec: template: spec: containers: [{image: "pay-dev"}]
}

오타 → 즉시 에러
replicas: 0 → 즉시 에러

6.4.3 CUE의 출력 (Export)

cue export deployment.cue --out yaml

검증 통과 시에만 YAML/JSON 생성
검증과 생성이 동시에 일어남

6.4.4 기존 도구와의 비교

구분	Helm	Kustomize	CUE
방식	문자열 치환	파일 패치	제약 병합
안전성	낮음	중간	매우 높음
중복 제거	values.yaml	base 공유	구조체 조합

7. 언제 Configuration Template 패턴을 사용해야 할까?

적극 추천

여러 환경 운영
GitOps 기반 조직
팀 단위 협업이 많은 경우

과도할 수 있는 경우

단일 환경
단기 PoC

참고 자료 (책 외)

bocopile

DevOps Engineer

이전 포스트

[쿠버네티스 패턴] 21장 Immutable Configuration

다음 포스트

[쿠버네티스 패턴] 22장 Configuration Template