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

bocopile·2025년 12월 27일

쿠버네티스 패턴

목록 보기

19/28

안녕하세요.

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

Kubernetes v1.35 기준 최신 기능과 실무 적용까지 하나의 흐름으로 정리해 보겠습니다.

이 글은 단순 요약이 아니라

문제 제시 → 이론적 해결책 → Kubernetes 최신 기능 → 실무 도구 적용

이라는 구조로 Immutable Configuration을 깊이 이해하는 것을 목표로 합니다.

1. Immutable Configuration 패턴의 배경과 문제 정의

Kubernetes 환경에서 애플리케이션 설정(configuration)은 코드만큼이나 중요한 자산입니다.

전통적으로 설정은 다음과 같은 방식으로 관리되어 왔습니다.

환경 변수(Environment Variables)
ConfigMap
Secret

하지만 이러한 방식은 구조적인 한계를 가지고 있습니다.

1.1 Mutable Configuration과 Configuration Drift

ConfigMap과 Secret은 기본적으로 변경 가능(mutable) 한 리소스입니다.

이로 인해 운영 환경에서는 다음과 같은 문제가 반복적으로 발생합니다.

실행 중인 Pod가 참조하는 설정이 의도치 않게 변경
변경 이력 추적이 어려움
환경(dev / staging / prod) 간 설정 차이로 인한 장애 재현 불가
롤백 시 애플리케이션 이미지와 설정 간 버전 불일치

책에서는 이러한 현상을 Configuration Drift라고 정의합니다.

Configuration Drift란

Git에 선언된 설정 상태와 실제 클러스터에 적용된 설정 상태가 점점 어긋나는 현상을 의미합니다.

Immutable Configuration 패턴은

이 Drift를 구조적으로 방지하기 위한 설계 원칙입니다.

2. Immutable Configuration 패턴의 핵심 개념

Immutable Configuration의 핵심 철학은 다음 한 문장으로 요약할 수 있습니다.

애플리케이션 설정은 수정(Edit)되지 않고, 항상 교체(Replace)되어야 합니다.

이 원칙을 따르면 다음과 같은 이점을 얻을 수 있습니다.

설정 변경 이력이 명확하게 남음
배포 단위(image + config)의 일관성 확보
장애 발생 시 빠르고 안전한 롤백 가능
Git 선언 상태와 클러스터 실제 상태의 일치

3. 책에서 설명하는 Immutable Configuration 구현 방식

3.1 버전 관리형 ConfigMap / Secret 방식

개념

설정 변경 시 기존 리소스를 수정하지 않고,

항상 새로운 ConfigMap 또는 Secret을 생성합니다.

app-config-v1
app-config-v2

Deployment는 항상 특정 버전의 설정을 명시적으로 참조합니다.

장점

Kubernetes 기본 기능만으로 구현 가능
GitOps와 매우 잘 어울림
구조가 단순하고 명확

한계

ConfigMap/Secret 크기 제한(약 1MB)
복잡한 디렉터리 구조나 대규모 설정에는 부적합

3.2 Data Container(설정 전용 이미지) 방식

개념

설정을 컨테이너 이미지로 패키징하여

Init Container 또는 Sidecar Container를 통해 전달하는 방식입니다.

장점

설정 크기 제한 없음
이미지 자체가 불변이므로 완전한 Immutable 보장
컨테이너 레지스트리를 통한 감사 가능

단점

운영 복잡도 증가
이미지 빌드/배포 파이프라인 필요

4. Immutable Configuration 워크플로우 한눈에 보기

흐름 요약

설정 변경은 항상 새 리소스 생성
Deployment 참조 변경 → ReplicaSet 교체
Pod는 롤링 업데이트로 안전하게 전환

5. Kubernetes v1.35 기준 최신 기능과의 연결

Immutable Configuration은 더 이상 운영자의 규칙에 의존하지 않습니다.

Kubernetes는 이 패턴을 플랫폼 차원에서 직접 강제하기 시작했습니다.

5.1 Immutable ConfigMap / Secret (v1.21+ 공식 지원)

immutable: true

이 옵션을 활성화하면 다음이 보장됩니다.

실수 방지 (Human Error Protection)

kubectl edit, patch 시도 시 API 서버에서 즉시 거부
“설정은 새 리소스로만 변경한다”는 규칙을 시스템이 강제

성능 최적화

불변 리소스는 watch 대상에서 제외
대규모 클러스터에서 Control Plane 부하 감소

5.2 Native Sidecar Containers (v1.29 GA)

Native Sidecar는 책의 Data Container 패턴의 현대적 진화형입니다.

기존 Init Container 방식의 한계

초기 설정 복사에는 적합
실행 중 설정 감시/갱신에는 부적합

Native Sidecar의 장점

설정 로더 전용 컨테이너 분리
메인 컨테이너와 생명주기 공유
Vault, External Secrets 등 외부 변경사항 감시 가능

이를 통해 애플리케이션 코드와 설정 관리 로직의 완벽한 분리가 가능해집니다.

5.3 CEL(Common Expression Language) 기반 유효성 검사 (상세 예시)

“검증된(Validated) 설정만 불변(Immutable) 상태로 배포한다”

immutable: true는 수정만 막을 뿐, 설정 값 자체의 옳음까지 보장하지는 않습니다.

이를 해결하는 것이 ValidatingAdmissionPolicy + CEL 입니다.

실제 사례: 데이터베이스 설정 ConfigMap 검증

운영팀은 다음 규칙을 강제하고 싶습니다.

포트 번호는 1024 ~ 65535 사이
환경 값은 prod, staging, dev 중 하나

1) CEL 기반 유효성 검사 정책 정의

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata:
  name: force-config-standards
spec:
  failurePolicy: Fail
  matchConstraints:
    resourceRules:
    - apiGroups: [""]
      apiVersions: ["v1"]
      operations: ["CREATE", "UPDATE"]
      resources: ["configmaps"]
  validations:
    - expression: "int(object.data.db_port) >= 1024 && int(object.data.db_port) <= 65535"
      message: "db_port는 1024에서 65535 사이의 숫자여야 합니다."
    - expression: "object.data.env in ['prod', 'staging', 'dev']"
      message: "env 값은 prod, staging, dev 중 하나여야 합니다."

2) 잘못된 ConfigMap 배포 시도

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config-v2
data:
  db_port: "80"
  env: "local-test"

결과

The configmaps "app-config-v2" is invalid: db_port는 1024에서 65535 사이의 숫자여야 합니다. (and 1 other error)

이 예시가 Immutable 패턴에 중요한 이유

무결성 결합: 새 버전 생성 시 CEL이 먼저 검증
안전한 고정: 검증 통과 후 immutable: true 적용
장애 예방: 잘못된 설정으로 인한 CrashLoopBackOff 사전 차단

즉,

Validated → Immutable

흐름이 완성될 때 21장에서 말하는 신뢰할 수 있는 설정 관리가 구현됩니다.

6. 실무 보강: Kustomize 활용

실무에서 Immutable Configuration을 가장 현실적으로 구현하는 도구는

Kustomize의 configMapGenerator 입니다.

configMapGenerator:
- name: app-config
  files:
  - application.yaml

파일 내용 변경 시 이름 뒤 해시 자동 변경
수동 버전 관리 불필요
GitOps 환경에서 사실상 표준

7. 언제 Immutable Configuration을 사용해야 할까?

권장

운영 안정성이 중요한 서비스
GitOps 기반 환경
규제 산업(금융, 공공)

비권장

빠른 실험 단계
단기 PoC

참고 자료 (책 외)

bocopile

DevOps Engineer

이전 포스트

# [쿠버네티스 패턴 19장 & 20장] EnvVar Configuration & Configuration Resource

다음 포스트

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