Kustomize - Patch

앞에서 본 commonLabels, nameSuffix, namespace 같은 Common Transformers는 “모든 리소스에 공통으로 적용”하는 데 최적입니다.
반대로, 특정 오브젝트(또는 일부 오브젝트)의 특정 필드만 바꾸고 싶다면 patches가 더 적합합니다.

예:

• 특정 Deployment만 replicas를 1 → 5로 변경
• 특정 Deployment만 metadata.name을 바꿈
• 특정 리소스에서 특정 label/annotation 제거
• 특정 Pod template에 sidecar container 하나 추가

이런 “정밀 타격”이 patches의 목적입니다.

---

1) Patch의 구성 요소 3가지(개념)

강의가 말한 핵심은 아래 3개입니다.

1. Operation(무슨 동작?)

• add : 새 값을 추가 (예: container 추가)
• remove : 값 제거 (예: label 제거)
• replace : 기존 값을 교체 (예: replicas 교체)

2. Target(어떤 리소스에?)

• kind, apiVersion, name, namespace
• labelSelector, annotationSelector
• 등 조합해서 “딱 그 리소스(들)”만 맞춥니다.

3. Value(무엇으로 바꿀지?)

• replace/add는 새로운 값이 필요
• remove는 삭제라서 value가 보통 필요 없음

---

2) Patch 방식 2가지: JSON 6902 vs Strategic Merge

Kustomize 패치에는 크게 2가지 스타일이 있습니다.

• JSON 6902 Patch: op/path/value로 매우 명확하게 “YAML 트리 경로”를 찍어서 변경
• Strategic Merge Patch: “쿠버네티스 리소스 YAML처럼 생긴 조각”을 원본에 merge해서 변경

둘 다 가능하고, 섞어 써도 됩니다.

---

A. JSON 6902 Patch (inline 예시)

예시 1) Deployment 이름 변경: api-deployment → web-deployment

원본 depl.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-deployment
spec:
  replicas: 1

kustomization.yaml

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

resources:
  - depl.yaml

patches:
  - target:
      kind: Deployment
      name: api-deployment
    patch: |-
      - op: replace
        path: /metadata/name
        value: web-deployment

• target이 “어떤 Deployment를 바꿀지”
• patch가 “어디를(/metadata/name) 무엇으로(web-deployment) 바꿀지”

예시 2) replicas 변경: 1 → 5

patches:
  - target:
      kind: Deployment
      name: api-deployment
    patch: |-
      - op: replace
        path: /spec/replicas
        value: 5

path는 어떻게 잡나?

• metadata.name → /metadata/name
• spec.replicas → /spec/replicas
• 더 깊으면 계속 내려갑니다. (예: /spec/template/spec/containers/0/image)

주의: 리스트(배열) 접근은 containers/0처럼 인덱스를 써야 해서, 사람이 읽기엔 다소 부담이 될 수 있습니다.

---

B. Strategic Merge Patch (가독성 좋은 방식)

강의에서 “원본을 복사해 와서 바꿀 부분만 남기는” 방식이 이겁니다.

예시) replicas 변경(가장 흔한 케이스)

patch-replicas.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-deployment
spec:
  replicas: 5

kustomization.yaml

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

resources:
  - depl.yaml

patchesStrategicMerge:
  - patch-replicas.yaml

장점:

• “쿠버네티스 YAML처럼” 써서 직관적
• path를 외울 필요가 적음
• replicas 같이 단순 필드 변경에 특히 좋음

---

3) 언제 Transformers vs Patches를 쓰나(실전 기준)

Transformers가 맞는 경우(전체 공통)

• 라벨/어노테이션을 전 리소스에 추가
• 네임스페이스를 전 리소스에 지정
• namePrefix/nameSuffix로 전 리소스 네이밍 규칙 통일
• 이미지 태그를 전반적으로 교체(특정 이미지 name 기준)

Patches가 맞는 경우(정밀 타격)

• 특정 Deployment만 replicas 변경
• 특정 리소스 1~2개만 다른 설정 적용
• 특정 container에만 env/volume 추가
• 특정 리소스에서 특정 필드 제거

---

4) 적용 전에 결과 확인(필수 습관)

패치는 실수하면 “원치 않는 리소스가 변경”될 수 있으니, 항상 렌더링 결과를 먼저 보는 게 안전합니다.

kubectl kustomize ./k8s | less

또는 변경점만:

kubectl diff -k ./k8s

---

5) 개인적으로 추천하는 운영 패턴

• base/에는 가능한 “공통”만 둔다
• 환경별 overlays/에서
  • 공통은 transformers로 처리 (namespace, nameSuffix, commonLabels)
  • 특정 리소스의 차이는 patches로 처리 (replicas, resources, env 등)

이렇게 가면 “한눈에” 유지보수가 됩니다.

---

정리

• Patches는 transformers보다 정밀하게 특정 리소스/필드만 수정하는 기능
• Patch 구성: op(add/remove/replace) + target + value(필요 시)
• 방식 2개:
  • JSON 6902: op/path/value로 정확하지만 리스트 경로가 읽기 어려울 수 있음
  • Strategic Merge: Kubernetes YAML처럼 작성해 가독성이 좋음(실무 선호 많음)