導入：なぜマニフェスト管理が必要なのか
Kubernetes（K8s）でアプリケーションを運用していると、必ず直面するのが「環境ごとの設定管理」という課題です。開発（Dev）、ステージング（Stg）、本番（Prd）で、レプリカ数や環境変数、リソース制限を微妙に変える必要があります。これらを個別にYAMLファイルとしてコピー＆ペーストで管理すると、修正漏れや設定ミスが多発します。これを防ぎ、DRY原則（Don’t Repeat Yourself）を遵守するために、HelmやKustomizeといったツールによる自動化が不可欠です。
基礎知識：HelmとKustomizeの違い
Helmは、K8sの「パッケージマネージャ」です。YAMLをテンプレート化し、値を外部ファイル（values.yaml）から注入する方式をとります。複雑なアプリケーションを配布・再利用するのに適しています。
一方、Kustomizeは「ネイティブなYAMLの差分管理」ツールです。ベースとなるYAMLに対し、環境ごとの差分（パッチ）を重ね合わせる（オーバーレイ）という直感的なアプローチをとります。K8sに標準統合されており、導入のハードルが低いのが特徴です。
実装・解決策：Kustomizeによる構成管理
Kustomizeでは、共通設定を記述したbaseディレクトリと、環境ごとの差分を記述したoverlaysディレクトリを分けます。これにより、ベースとなる構成を汚さずに柔軟な環境切り替えが可能になります。
サンプルプログラム：Kustomizeによる環境別設定
以下は、Deploymentのレプリカ数を環境ごとに変更するシンプルな構成例です。
1. ベースディレクトリ (base/deployment.yaml)
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app
spec:
replicas: 1
template:
spec:
containers:
- name: app
image: my-app:latest
2. 本番用オーバーレイ (overlays/prd/kustomization.yaml)
resources:
- ../../base
patches:
- target:
kind: Deployment
name: my-app
patch: |-
- op: replace
path: /spec/replicas
value: 3 # 本番は3台にスケールさせる
応用・注意点：現場での使い分け
現場での選定基準として、以下を意識してみてください。
・Helmを選択すべきケース：
サードパーティ製のツール（Ingress Controllerや監視ツールなど）をインストールする場合や、複雑な条件分岐（if文など）が必要な場合。
・Kustomizeを選択すべきケース：
自社開発のアプリケーション管理。YAMLの可読性を保ちたい場合や、Helmの複雑なテンプレート構文を学習コストとして避けたい場合。
注意点：
特にKustomizeを使用する場合、パッチを当てすぎてディレクトリ構造が深くなると、どこで何が定義されているか追いにくくなる「設定の迷宮化」に注意してください。可能な限り共通化は最小限に留め、環境ごとの差分は視覚的に分かりやすい構造を維持するのが運用のコツです。
コメント