実際のアプリケーションは、レプリカ数、ホスト名、設定値など、わずかな点が異なる複数の環境で動作します。Flux はプレーンな YAML や Kustomize のオーバーレイを適用し、フォルダーがどちらを使っているかを検出します。このガイドでは、Kustomize で複数の環境のためにリポジトリを構成する方法、各環境を Flux に伝える方法、そして設定変更で陥りやすい落とし穴を説明します。これまでのガイドの webapp の例を基にしています。

構成を選ぶ：ブランチではなくフォルダ

環境を長期間存続するブランチ（dev、staging、main）としてモデル化することもできますが、そうするとプロモーションはマージ作業になり、環境間の差異が広がりやすくなります。環境ごとにフォルダを持つ単一ブランチのほうが理解しやすく、すべての環境を並べて確認でき、1 つの環境への変更も通常の diff になります。

Flux のドキュメントは、一般的なリポジトリ戦略を 3 つ説明しています。

• モノレポ。 すべてのクラスター、アプリケーション、インフラを 1 つのリポジトリに置きます。始めるのが最も簡単で、ここで使うものです。
• 環境ごとのリポジトリ。 たとえば、staging 用と本番用に 1 つずつで、アクセスルールを別にします。
• チームごと、またはアプリケーションごとのリポジトリ。 強い分離があり、各チームのリポジトリを登録する、プラットフォームのリポジトリを持ちます。

典型的なモノレポは次のようになります。

fleet-infra/
├── clusters/
│   ├── dev/                 # dev クラスター用の Flux の Kustomization
│   └── production/          # 本番クラスター用の Flux の Kustomization
├── infrastructure/          # ingress コントローラー、cert-manager、モニタリング
└── apps/
    ├── base/webapp/         # 共有のマニフェスト
    ├── dev/                 # dev 用のオーバーレイ
    └── production/          # 本番用のオーバーレイ

Kustomize の base とオーバーレイを構築する

apps/base/webapp/kustomization.yaml は、共有のリソースを列挙します。

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
  - deployment.yaml
  - service.yaml

apps/base/webapp/deployment.yaml では、各オーバーレイが生成する ConfigMap から設定を読み込むようにコンテナを構成します（オーバーレイが設定するため、base では namespace フィールドを省略します）。

          envFrom:
            - configMapRef:
                name: webapp-config

apps/dev/kustomization.yaml:

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
namespace: webapp-dev
resources:
  - namespace.yaml
  - ../base/webapp
replicas:
  - name: webapp
    count: 2
configMapGenerator:
  - name: webapp-config
    literals:
      - HEADER=Hello from dev

webapp-dev を作成する namespace.yaml とともに使います。apps/production/kustomization.yaml も同様で、namespace: webapp-prod、count: 4、独自の namespace マニフェスト、独自の HEADER の値を設定します。commit する前に、オーバーレイが何をレンダリングするかを確認できます。

kustomize build apps/dev
# または、kustomize を別途インストールせずに：
kubectl kustomize apps/dev

各オーバーレイに Flux の Kustomization を向ける

Flux は、パス内の kustomization.yaml を検出し、自動的にビルドします。各クラスターのフォルダーに、環境ごとに 1 つの Flux の Kustomization を追加します。clusters/dev/apps.yaml:

apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: apps
  namespace: flux-system
spec:
  interval: 10m
  sourceRef:
    kind: GitRepository
    name: flux-system
  path: ./apps/dev
  prune: true
  wait: true
  timeout: 3m

本番クラスターでは、clusters/production/apps.yaml が path: ./apps/production を使います。各クラスターは、独自の --path で bootstrap されたため、各クラスターは自分のフォルダーだけを見ます。

本番を意図的なものにする

手動の同期ボタンを持つツールとは異なり、Flux は自動的に適用するため、本番は Git を通じて制御します。強力なパターンの 1 つは、dev にブランチを追跡させ、本番にはリリースのタグを追跡させることです。本番クラスターの source で：

apiVersion: source.toolkit.fluxcd.io/v1
kind: GitRepository
metadata:
  name: fleet-releases
  namespace: flux-system
spec:
  interval: 5m
  url: https://github.com/your-org/fleet-infra
  ref:
    semver: ">=1.0.0"

こうすると、本番は、リリースにタグを付けたときだけ変わります。メインブランチでのプルリクエストの承認が、もう 1 つの一般的なゲートです。

設定変更を意図的に扱う

ある環境の HEADER の値を変更して、何が起こるかを確認します。Kustomize は、生成された ConfigMap の名前に内容のハッシュを付加します。新しい値は新しい ConfigMap（webapp-config-<hash>）を生成し、Deployment の参照を更新するため、Pod のロールアウトが発生します。古い ConfigMap は孤立し、prune: true なら Flux がそれを削除します。この動作はまさに望ましいものです。設定変更が Pod を再起動します。

手書きの通常の ConfigMap は異なります。Deployment が envFrom を通じて読み取る ConfigMap を編集しても、Deployment の spec は変わらないため、稼働中の Pod は古い値を保持したままです。変更時にワークロードを再起動すべきものには、configMapGenerator を使ってください。Helm チャートには同等の手法があり、Helm のガイドで説明します。

クラスターごとの値を置換する

ときどき、値がクラスターごとに異なるものの、そのために完全なオーバーレイは欲しくないことがあります。たとえばドメイン名です。Flux の Kustomization は、ビルド後に変数を置換できます。

spec:
  postBuild:
    substitute:
      cluster_domain: dev.example.com
    substituteFrom:
      - kind: ConfigMap
        name: cluster-vars

マニフェスト内のすべての ${cluster_domain} が、適用時に置き換えられます。オーバーレイのほうがレビューしやすいため、控えめに使ってください。

環境間で変更をプロモートする

この構成では、プロモーションは通常の commit の連続になります。まず dev のオーバーレイを変更し（たとえば apps/dev で kustomize edit set image nginx=nginx:1.26 を実行してイメージを更新）、Flux に適用させて、確認します。次に、承認を必須とするプルリクエストで、apps/production に同じ変更を加えます。CI パイプラインで dev の commit を自動化し、レビュアーが本番の commit を制御できます。Flux のイメージ自動化も、dev のステップを代わりに行えます。これはイメージ自動化のガイドで説明します。