Kustomize
Guides
Introduction
Configuration Management
Resource Printing
Container Debugging
App Deployment
Extending Kubectl
Extending Kustomize
Examples
GPT-4.icon
宣言的な方法で設定の追加・上書き・削除が可能
環境ごとの差分管理
共通設定
環境固有の設定
同じアプリを dev / prod 環境でデプロイする例
例
dev: レプリカ数 1、imageはapp:dev
prod: レプリカ数 3、imageはapp:latest
❌ Kustomizeを使わない場合（Before）
環境ごとにファイルを 完全コピーして差分を持たせるしかない：
code:_
manifests/
├── dev/
│ └── deployment.yaml
├── prod/
│ └── deployment.yaml
dev/deployment.yaml
code:yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app
spec:
replicas: 1
template:
spec:
containers:
- name: app
image: app:dev
prod/deployment.yaml
code:yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app
spec:
replicas: 3
template:
spec:
containers:
- name: app
image: app:latest
問題点
ファイルが丸ごと重複し、保守が面倒（同じところも差分も管理がつらい）
差分を明示的に表現できない（レビューしにくい）
Kustomizeを使う場合（After）
Kustomizeの「ベースとオーバーレイ」という構成にするとこうなる：
code:_
kustomize/
├── base/
│ ├── deployment.yaml # 環境に共通なもの
│ └── kustomization.yaml
├── overlays/
│ ├── dev/
│ │ ├── kustomization.yaml
│ │ └── patch.yaml # dev用の差分
│ └── prod/
│ ├── kustomization.yaml
│ └── patch.yaml # prod用の差分
code:base/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app
spec:
replicas: 1 # default（あとでpatchで上書き）
template:
spec:
containers:
- name: app
image: app:latest # default
code:`overlays/dev/patch.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app
spec:
replicas: 1
template:
spec:
containers:
- name: app
image: app:dev
code:overlays/prod/patch.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app
spec:
replicas: 3
code:overlays/dev/kustomization.yaml
resources:
- ../../base
patchesStrategicMerge:
- patch.yaml
💡 何が嬉しいか？
table:_
ポイント Kustomize前 Kustomize後
差分管理 手動コピー patchで明示的に管理できる
重複 多い baseに集約して減らせる
拡張性 低い 環境追加が簡単（overlays/stagingなど）
読みやすさ 低い 差分が明示的でレビューしやすい
🛠️ 基本的なコマンド
マニフェストのビルド（確認）:
$ kubectl kustomize overlays/dev
マニフェストの適用:
$ kubectl apply -k overlays/dev
差分の確認:
$ kubectl diff -k overlays/dev
これらのコマンドにより、環境ごとの設定差分を効率的に管理できます。 (Zenn) 🔧 具体的なユースケース
環境ごとの設定変更: 開発・ステージング・本番など、各環境で異なる設定（例：replica数、リソース制限）を適用できます。
共通設定の再利用: baseディレクトリに共通設定をまとめることで、設定の重複を避け、保守性を向上させます。