Flux は、各クラスターで 1 組のコントローラーを実行し、すべてが同じ Git リポジトリの異なるパスを追跡することで、多くのクラスターにスケールします。クラスターを登録する中央のハブはありません。このガイドでは、staging と本番のために単一のリポジトリを構成し、各クラスターを bootstrap し、インフラをアプリケーションより前に配置し、代わりにリモートクラスターの構成をいつ使うかを説明します。

1 つのリポジトリ、クラスターごとに 1 つのパス

Flux は単純なルールに従います。すべてのクラスターは、clusters/ 配下の自分専用のフォルダーに対して bootstrap されます。2 つのクラスターに対応するリポジトリは次のようになります。

fleet-infra/
├── clusters/
│   ├── staging/
│   │   ├── flux-system/        # bootstrap によって作成
│   │   ├── infrastructure.yaml
│   │   └── apps.yaml
│   └── production/
│       ├── flux-system/
│       ├── infrastructure.yaml
│       └── apps.yaml
├── infrastructure/
│   ├── base/                   # 共有：ingress、cert-manager、モニタリング
│   ├── staging/
│   └── production/
└── apps/
    ├── base/
    ├── staging/
    └── production/

共有の定義は base/ フォルダーに置かれ、各環境のフォルダーには、異なる部分の Kustomize オーバーレイが入ります（オーバーレイのガイドを参照）。

各クラスターを bootstrap する

kubectl のコンテキストを各クラスターに順に切り替え、異なるパスで同じリポジトリに対して bootstrap します。

kubectl config use-context staging
flux bootstrap github --owner=<user> --repository=fleet-infra \
  --branch=main --path=clusters/staging --personal

kubectl config use-context production
flux bootstrap github --owner=<user> --repository=fleet-infra \
  --branch=main --path=clusters/production --personal

各クラスターに、独自の Flux のインストールと、Git 内の独自の flux-system フォルダーができました。後で 3 つ目のクラスターを追加するには、新しいパスで bootstrap コマンドをもう 1 つ実行するだけです。

各クラスターを独自のオーバーレイに向ける

clusters/production/apps.yaml は、本番のオーバーレイを適用します。

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

clusters/staging/apps.yaml は、path: ./apps/staging を除いて同一です。infrastructure の Kustomization も、同じ方法で ./infrastructure/<env> を指し、アプリケーションが、ingress コントローラー、証明書マネージャー、同様のコンポーネントが準備完了になってから起動するように、wait: true を持っています。その順序を強制するのが dependsOn フィールドです。

クラスターをまたいで確認する

Flux には中央のダッシュボードがないため、各クラスターを自分のコンテキストから確認します。

flux get kustomizations --context staging
flux get kustomizations --context production

どちらも Ready と表示されるはずです。flux tree と flux get all -A を使って、Git がデプロイ済みとしているものと、各クラスターが報告するものを比較します。フリート全体の可視性のために、チームはしばしば Flux の Prometheus メトリクスを Grafana に収集します。

staging から本番にプロモートする

両方のクラスターが同じリポジトリを読むため、プロモーションは commit です。一般的な流れは次のとおりです。

1. apps/staging を変更し、Flux に staging クラスターへ適用させます。
2. テストして確認します。
3. レビュー済みのプルリクエストで、apps/production に同じ変更を加えるか、本番の GitRepository が追跡するリリースにタグを付けます（オーバーレイのガイドを参照）。

代替案：1 つの制御クラスター、多くのリモートクラスター

すべてのクラスターで Flux を実行する代わりに、1 か所で実行して、その Kustomization と HelmRelease を他のクラスターに適用させることもできます。リソースの spec.kubeConfig に、リモートクラスターの kubeconfig を保持する Secret を設定します。

spec:
  kubeConfig:
    secretRef:
      name: production-kubeconfig

これにより制御は一元化されますが、すべてのクラスターの認証情報が、制御クラスターに置かれることにもなります。これは、認証情報が各クラスターの外に出ず、侵害されたクラスターが他のクラスターに到達できない、通常の Flux のモデルとは異なります。軽量なエッジクラスターなど、一元化する明確な理由がない限り、クラスターごとに 1 つの Flux のインストールを優先してください。この方法をとる場合は、プラットフォームがサポートしているなら、長期間有効な kubeconfig の代わりに、クラウドの workload identity を使い、大規模なフリートの管理には、Flux Operator を検討してください。

良い習慣

• 各クラスターの flux-system フォルダーを、共有のオーバーレイに入れないでください。bootstrap がそれを所有します。
• dependsOn を使って、インフラ、CRD、コントローラーが、それを必要とするアプリより前にインストールされるようにします。
• staging が本番のシークレットを復号できないように、各クラスターに独自の SOPS キーを与えます（シークレットのガイドを参照）。
• Flux のアップグレードは、本番以外のクラスターから始めて、1 度に 1 クラスターずつ、より新しい CLI で flux bootstrap を再実行して行います。