Kustomize（カスタマイズ）

2025年11月6日

Kustomize（カスタマイズ）

英語表記: Kustomize

概要

Kustomizeは、Kubernetesの構成ファイル（マニフェスト）を、環境に応じて柔軟にカスタマイズするためのネイティブなツールです。特に、基本的な設定を共通化しつつ、開発環境、ステージング環境、本番環境といった特定の目的に合わせて微調整を行う際に非常に役立ちます。Kubernetesの宣言的インフラを実現する上で欠かせない存在であり、ベースとなるYAMLファイルを直接変更することなく、差分（パッチ）を適用して最終的なマニフェストを生成する仕組みを提供しています。

詳細解説

Kustomizeは、「オーケストレーション（Kubernetes, OpenShift）におけるGitOpsと宣言的運用」を支える重要な技術要素です。その目的、動作原理、そして主要な構成要素について詳しく見ていきましょう。

目的：環境に応じた設定の「宣言的」な管理

Kubernetesでアプリケーションを運用する際、共通のアプリケーションコードを使用していても、環境ごとに異なる設定が必要になることがよくあります。たとえば、本番環境ではレプリカ数を5にしたいが、開発環境ではコスト削減のために1で十分、といった具合です。

従来のテンプレートエンジン（例えばHelm）では、設定の変更のために複雑なテンプレート言語を習得する必要がありましたが、Kustomizeは「生のYAML」をそのまま利用することを重視しています。これにより、ユーザーはテンプレートのロジックではなく、純粋に望ましいインフラの状態を宣言することに集中できます。これはまさに、宣言的インフラの理想を追求するアプローチだと言えますね。

動作原理：パッチ適用による非破壊的な変更

Kustomizeの最も特徴的な点は、ベースとなるマニフェストをコピーしたり、テンプレート変数に置き換えたりするのではなく、「パッチ（差分）」として変更を適用する点です。

Base（ベース）: 共通のアプリケーション設定を定義したオリジナルのYAML群です。これはどの環境でも共通して使用される「土台」となります。
Overlay（オーバーレイ）: 特定の環境（例：本番）向けに、Baseに対してどのような変更を加えたいかを定義する設定群です。このOverlayこそが、Kustomizeの心臓部であり、変更内容（パッチ）を記述します。
kustomization.yaml: Kustomizeの設定ファイルです。どのBaseを使用し、どのOverlay（パッチ、追加リソース、命名規則など）を適用するかを宣言的に記述します。

Kustomizeは、このkustomization.yamlを読み込み、BaseのYAMLに対してOverlayで指定されたパッチを適用し、最終的なデプロイ用YAMLを出力します。このプロセスは非破壊的であり、オリジナルのBaseファイルは常にクリーンな状態に保たれます。これにより、設定の変更履歴（GitOpsの文脈では特に重要です！）が非常に追いやすくなるのです。

GitOpsとの連携

Kustomizeは、GitOpsと宣言的運用の文脈で非常に強力な役割を果たします。GitOpsでは、Gitリポジトリが「信頼できる唯一の情報源（Single Source of Truth）」です。

もし環境ごとに設定ファイルを手動で編集していたら、Gitリポジトリには環境ごとの差異が散乱し、管理が難しくなります。しかし、Kustomizeを使えば、Gitリポジトリには以下の情報のみを保持できます。

共通のBaseマニフェスト。
環境ごとのOverlay（変更点）を記述したkustomization.yaml。

そして、Argo CDやFluxといったGitOpsツールが、デプロイ時にこのkustomization.yamlを読み込み、その場でKustomizeの処理を実行して「最終的なデプロイ用YAML」を生成し、Kubernetesクラスターに適用します。これにより、インフラの望ましい状態がGit上で完全に宣言され、自動化された運用が可能になります。これは、手動操作を排除し、監査可能性を高めるというGitOpsの核心を突いていますね。

宣言的インフラとしての価値

Kustomizeが提供するYAMLパッチの機能は、インフラ管理を真に宣言的にします。Kustomizeは、設定を「どのように変更するか」という手続き（Imperative）ではなく、「最終的にどのような状態になってほしいか」という宣言（Declarative）として記述することを可能にします。

テンプレートエンジンが「プログラミング的なロジック」を必要とするのに対し、Kustomizeは「最終的なYAMLの構造」に焦点を当てます。このシンプルさが、Kubernetesの哲学と非常に高い親和性を持っていると言えるでしょう。

具体例・活用シーン

Kustomizeの柔軟なカスタマイズ能力を理解するために、具体的な利用シーンと、初心者にも分かりやすい類推を見てみましょう。

活用シーン：環境別設定の分離

あるWebアプリケーションを開発していると仮定します。

Baseの設定（共通）: Deployment、Service、ConfigMapなど、アプリケーションの基本的な設定を定義します。例えば、コンテナイメージのバージョンは共通で、レプリカ数はデフォルトで1とします。
開発環境（Dev Overlay）: Baseを使用し、特に変更は加えないか、あるいはリソース要求を最小限に抑えます。
本番環境（Prod Overlay）:
- パッチの適用: kustomization.yamlで、レプリカ数を1から5に変更するパッチを適用します。
- ConfigMapの差し替え: 本番環境用のデータベース接続情報を持つConfigMapを追加し、既存のConfigMapを上書き（差し替え）します。
- ネームスペースの指定: すべてのリソースをproduction-appネームスペースにデプロイするように指定します。

このように、Baseのファイルを一切汚染することなく、環境固有の設定をOverlayとして追加・変更できるため、管理が非常にクリーンになります。

初心者向けのアナロジー：料理のレシピとトッピング

Kustomizeの動作を、料理のレシピに例えてみましょう。

あなたは「基本のハンバーガー」のレシピ（Base）を持っています。このレシピは、パン、パティ、レタスという共通の要素を定義しています。

次に、あなたは「プレミアムハンバーガー」（Overlay）を作りたいとします。

Baseの指定: まず、基本のハンバーガーレシピを参照します。
パッチの適用: レシピ自体（Base）を書き換えるのではなく、追加の指示（パッチ）を付け加えます。「パティをダブルにする」「チーズを追加する」といった指示です。
kustomization.yaml: これが「今日の調理指示書」にあたります。これには、「基本レシピを参照し、この追加トッピング（パッチ）を適用せよ」と書いてあります。

Kustomizeは、この指示書に従って、基本レシピ（YAML）にトッピング（パッチ）を適用し、最終的な「プレミアムハンバーガー（デプロイ用YAML）」を生成するのです。基本レシピは常に変わらないため、いつでも「基本のハンバーガー」に戻ることも、「スパイシーハンバーガー」のOverlayを適用することも簡単にできます。これが、宣言的で管理しやすい設定管理の仕組みなのですね。