Flux
Git に置いたマニフェストと Kubernetes クラスタの状態を継続的に一致させ続ける GitOps ツール。
- カテゴリ: App Definition & GitOps
- CNCF 成熟度: Graduated
- 言語: Go
- ライセンス: Apache-2.0
- リポジトリ: fluxcd/flux2
- ドキュメント基準コミット:
65d975b(main, 2026-06-19; 最寄りタグv2.8.8)
何をするものか
Flux は Kubernetes の構成を Git から配信する。YAML をリポジトリに commit すると、クラスタ内のコントローラ群がその状態を pull して適用する処理を繰り返し、クラスタは Git が示す状態へ収束する。開発者のラップトップや CI ランナーからクラスタへ push するものは何もない。
fluxcd/flux2 リポジトリは 2 つの顔を持つ。flux CLI は day-0 の作業を担う。クラスタのブートストラップ、マニフェスト生成、状態の確認だ (cmd/flux/main.go:43)。継続的なリコンサイルは GitOps Toolkit のコントローラ群が行う。これらは別リポジトリにあり、go.mod を通じて API モジュールとして取り込まれる。デフォルトインストールでは source-controller、kustomize-controller、helm-controller、notification-controller が立ち上がる (pkg/manifestgen/install/options.go:46)。
特徴的なのは、Flux が自分自身を GitOps 管理下に置く点だ。ブートストラップ後、Flux 自身のコンポーネントマニフェストも Git に存在し、クラスタ内の kustomize-controller が他のワークロードと同様にリコンサイルする。Flux のアップグレードは commit に帰着し、day-1 以降は CLI を必要としない。
いつ使うか
- 各クラスタが自分自身をリコンサイルし、CI からの中央 push を行わない pull 型 GitOps モデルが欲しいとき。
- 多数のクラスタやエッジ環境を運用し、クラスタあたりの常駐フットプリントを小さくしたいとき。
- Helm を一級のデリバリ機構として扱い、CI でレンダリングするのではなく
HelmReleaseオブジェクトをコントローラにリコンサイルさせたいとき。 - リコンサイルループ内で secret の SOPS ネイティブ復号が必要なとき。
- 単一の中央コントロールプレーンとリッチな Web UI を主要インターフェースにしたい場合は不向き。その形には Argo CD がより直接的に合う。
このディープダイブの構成
- 歴史: 起源・マイルストーン・存在理由。
- アーキテクチャ: コンポーネントとリクエストの流れ。
- 採用事例・エコシステム: 誰が動かし、周囲に何があるか。
- 内部実装: ソースから読んだ重要なコードパス。
- はじめに: インストールと最初の動く構成。
出典
- fluxcd/flux2 リポジトリ (source, LICENSE, go.mod, Makefile)、参照日 2026-06-22。
- Flux Graduates from the CNCF Incubator、参照日 2026-06-22。
- Flux is a CNCF Graduated project、参照日 2026-06-22。
- What is Flux CD? (CNCF)、参照日 2026-06-22。
- An introduction to Flux, Part 1: History and features (Platform9)、参照日 2026-06-22。
- Flux Adopters、参照日 2026-06-22。
- Flux vs Argo CD (Northflank)、参照日 2026-06-22。