導入：なぜKustomizeが必要なのか？
Kubernetesでアプリケーションを運用する際、開発環境、ステージング環境、本番環境など、複数の環境を管理する必要があります。しかし、環境ごとにYAMLファイルを丸ごとコピーして修正していると、「修正漏れ」や「設定ミス」が頻発します。Kustomizeを使えば、共通のベース設定はそのままに、環境ごとに変えたい値だけを「パッチ」として適用できるため、管理の手間とリスクを劇的に減らすことができます。
基礎知識：Kustomizeの仕組み
Kustomizeは、Kubernetesの標準コマンドである「kubectl -k」で実行できる、宣言的な設定管理ツールです。
主な概念は「ベース（Base）」と「オーバーレイ（Overlay）」です。
・ベース：すべての環境で共通する基本のYAMLファイル群。
・オーバーレイ：環境ごとの差分（パッチ）を定義するディレクトリ。
これらを「kustomization.yaml」という設定ファイルで束ねることで、最終的なYAMLを生成します。テンプレートエンジンを使わず、標準のYAMLとして記述できるのが最大の魅力です。
実装：ディレクトリ構造と設定手順
まずは以下のようなディレクトリ構成を作成します。
base/ (共通設定)
overlays/
production/ (本番環境の差分)
各ディレクトリにkustomization.yamlを配置し、ベースを読み込んでパッチを適用する設定を記述するだけで準備は完了です。
サンプルプログラム：本番環境でレプリカ数を増やす例
まずは、共通のベースとなる「deployment.yaml」です。
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app
spec:
replicas: 1 # 基本は1台
template:
spec:
containers:
- name: app
image: my-app:latest
次に、本番環境でレプリカ数を3に増やすためのパッチ用YAMLです。
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app
spec:
replicas: 3 # ここで上書きします
最後に、これらを紐付ける「kustomization.yaml」です。
resources:
- ../../base/deployment.yaml # ベースの読み込み
patches:
- target:
kind: Deployment
name: my-app
patch: |-
- op: replace
path: /spec/replicas
value: 3 # 本番環境では3台に増やす
この状態で「kubectl kustomize overlays/production/」を実行すると、パッチが適用されたYAMLが出力されます。
応用・注意点：現場で役立つアドバイス
1. Strategic Merge Patchの活用：単純な上書きだけでなく、コンテナの環境変数追加など、既存のリストを維持したまま一部だけ変更したい場合は「Strategic Merge Patch」が便利です。YAMLの構造をそのまま書くだけで自動的にマージしてくれます。
2. 変更内容の確認：いきなりデプロイせず、必ず「kubectl kustomize [ディレクトリ名] > result.yaml」のように出力結果をファイルに保存し、意図した通りに変更されているか確認する癖をつけましょう。
3. 複雑化の回避：パッチを重ねすぎると、最終的な設定が追いづらくなります。共通設定と環境固有設定の境界線を明確に保つことが、長期的な運用には不可欠です。
コメント