2026.07.24 インフラ

Flux CDとは？GitOps Toolkitの仕組みとArgo CDとの違いを実装者目線で解説

Flux CDは、Git上の宣言（マニフェスト）をKubernetesクラスタの状態と一致させ続ける、CNCF Graduated（2022年）のGitOps継続的デリバリーツールです。特徴は、単一の巨大なアプリケーションではなく、source・kustomize・helm・notification・image-automationといった役割別のコントローラ群（GitOps Toolkit）で構成される点にあります。この記事では、望ましい状態を宣言してリコンサイルさせるGitOpsの仕組み、各コントローラとカスタムリソースの責務、Argo CDとの違い、Flux Operatorでの導入手順、そして自社が採用すべき場面と見送るべき場面までを実装者目線で整理します。基準とするバージョンはFlux v2.8系（2026年5月時点でv2.8.8）です。

まとめ：Flux CDの要点と採用判断の結論

Flux CDは「Gitリポジトリを唯一の正とし、クラスタを自動でその状態へ収束させる」pull型のGitOpsツールです。CIがクラスタへkubectl applyを打ちに行くpush型と異なり、クラスタ内のコントローラがGitを継続的に監視し、差分を検出して自律的に是正します。デプロイ資格情報をCIに渡さずに済み、手作業のドリフトも巻き戻せる点が運用上の効き目です。

結論として、Kubernetesを本番運用し、複数クラスタ・複数チームの構成をコードで統制したい組織にはFluxが噛み合います。逆に、Kubernetesをまだ持たない、あるいは1クラスタで管理画面を重視するなら過剰投資になりがちです。設計・根拠・手順は以降の章で具体化します。GUIでの可視化を最優先するならArgo CDが有力で、両者の使い分けは後述の比較章で判断軸を示します。

Flux CD（GitOps Toolkit）の全体像と設計思想

Fluxを理解する近道は、単体のCDツールではなく「継続的デリバリーを組み立てるためのAPIとコントローラの部品セット」と捉えることです。この設計思想が、後述するArgo CDとの違いの根になります。

GitOpsの前提とFlux CDが担う継続的デリバリーの範囲

GitOpsは、システムの望ましい状態をGitに宣言的に記述し、実際のクラスタ状態をそれへ継続的に近づける運用モデルです。IaC（Infrastructure as Codeの考え方はこちらの解説で整理しています）が「構成をコードで書く」までを指すのに対し、GitOpsは「そのコードとクラスタの差分を機械が検出し、自動で収束させる」ところまでを含みます。Fluxが担うのはこの後半、つまりデプロイと状態の維持です。

アプリのビルドやテストは対象外です。イメージのビルドは既存のCIに任せ、できあがったイメージのデプロイからをFluxが引き受けます。CI/CDの全体像とパイプラインの役割分担を押さえると、Fluxが「CDの後段」に位置することが掴めます。

標準UIを持たないマルチコントローラ構成をあえて選んだ設計の狙い

Fluxには標準の統合Webダッシュボードがありません。これは機能不足ではなく、Kubernetesの流儀（各リソースを専任コントローラが調停する）に揃えた設計です。ソース取得・マニフェスト適用・Helm管理・通知・イメージ更新を、それぞれ独立したコントローラとCRD（Custom Resource Definition）に分けています。

分離の実利は、権限と障害の切り分けです。Helmだけを使う環境ならhelm-controllerの挙動だけを追え、通知が不要ならnotification-controllerを入れない、という取捨ができます。反面、状態を一望する画面が要るなら、後述のFlux Operator付属UIやサードパーティのダッシュボードを別途組み合わせる前提になります。

GitOps Toolkitを構成するコントローラとカスタムリソース

Fluxの実体は、クラスタ内で動く複数のコントローラと、それらが調停するカスタムリソースです。ここが実装の中心なので、責務の割り当てを具体的に押さえます。

GitOps Toolkitを担う各コントローラとCRDの責務分担

各コントローラは1つ以上のCRD（Custom Resource Definition）を所有し、その望ましい状態への収束だけに責任を持ちます。役割分担は次の5系統です。

  • source-controller：Git・OCIレジストリ・S3等から成果物を取得しクラスタ内へ公開する。所有CRDはGitRepository・OCIRepository・HelmRepository・HelmChart・Bucket
  • kustomize-controller：取得したマニフェストをKustomizeでビルドしてクラスタへ適用する。所有CRDはKustomization
  • helm-controller：Helmチャートのインストールとアップグレードを宣言的に実行する。所有CRDはHelmRelease
  • notification-controller：Slack等への通知送出とWebhook受信による再同期を担う。所有CRDはProvider・Alert・Receiver
  • image-automationコントローラ群：レジストリの新イメージを検出しGitへ書き戻す。所有CRDはImageRepository・ImagePolicy・ImageUpdateAutomation

マニフェストの適用にKustomizationを経由するため、Kustomizeの理解がそのままFluxの理解になります。base・overlaysの仕組みはKustomizeとはの実装解説に委ねます。

GitRepositoryとKustomizationで宣言する望ましい状態

最小構成は2つのリソースで完結します。GitRepositoryが「どのリポジトリのどのブランチを、どの間隔で取りに行くか」を宣言し、Kustomizationが「取得した成果物のどのパスを、どのnamespaceへ、どんな間隔で適用するか」を宣言します。両者はsourceRefで連結する構成です。

APIバージョンは、Source APIとKustomize APIがともにv1（安定版）、Helm APIがv2、Notification APIがv1とv1beta3という構成です（2026年時点）。v1に到達したCRDは後方互換の保証が働くため、本番のマニフェストはv1系を基準に書くのが無難です。

リコンサイル間隔の設定とドリフト自動是正の挙動と運用上の注意点

Fluxはintervalで指定した周期（例：1分・5分）ごとにGitと実状態を突き合わせ、差分があれば適用します。誰かがkubectl editで本番を手直ししても、次のリコンサイルでGitの宣言に巻き戻ります。これが「手作業のドリフトを許さない」というGitOpsの実効です。

ただし巻き戻しは諸刃です。緊急対応で一時的に手を入れたい場面では、対象Kustomizationをsuspendしてから作業し、恒久修正はGitへ反映してresumeする、という手順を運用ルールに組み込む必要があります。この作法を決めずに導入すると「直したのに戻る」という混乱を招きます。

Argo CDとの違いとFlux CDが噛み合う組織の判断軸

GitOpsツールの選定は、多くの場合FluxとArgo CDの二択になります。同じGitOpsでも設計思想が異なるため、組織の運用体制で向き不向きが分かれます。

実装観点で見るアーキテクチャ・標準UI・マルチテナンシーの比較

両者の性格差を、実装・運用の観点で並べます。

観点 Flux CD Argo CD
構成 役割別コントローラ群 統合アプリ型
標準UI なし（外部ツール併用） あり（同期状態を可視化）
状態モデル 各CRDに分散 Applicationに集約
マルチテナント namespaceで分離 Project単位のRBAC
得意領域 多クラスタのコード統制 画面でのセルフ運用

製品として別物のため、意図が異なれば併存もあり得ます。Argo CD側の詳細な仕組みと導入判断はArgoCDとはの実装解説を主として参照し、本記事はFlux側の判断に集中します。

運用主体で決めるFlux CDとArgo CDの選定判断基準

選定は好みではなく運用主体で決めます。プラットフォームチームがコードで全クラスタを統制し、開発者は画面を触らない運用ならFluxが噛み合います。逆に、多数の開発チームに「自分のアプリの同期状態を画面で見て自分で再同期する」体験を配りたいなら、標準UIを持つArgo CDが強いです。

もう一つの軸はイメージ自動更新です。レジストリの新タグを検出してGitへ自動コミットさせたいなら、Fluxのimage-automationが標準機能として揃っている分だけ設計が短くなります。Argo CDでは別途Argo CD Image Updater等の追加が要ります。この一点で天秤が傾く現場は珍しくありません。

Flux CDの導入手順とImage Automationの運用設計

導入は「クラスタにコントローラを入れ、Gitと接続し、最初のKustomizationを宣言する」流れです。現在はFlux Operatorを使う方法が管理を簡素にします。

Flux Operatorとbootstrapコマンドによる導入手順

導入経路は主に2つです。従来のflux bootstrapはCLIがクラスタへコントローラを入れつつ、その構成自体をGitへコミットして自己管理させます。広がりつつあるFlux Operator（ControlPlaneが公開）は、FluxInstanceというCRDでFlux本体のバージョンや構成を宣言的に管理し、アップグレードも宣言で回せます。

  1. KubernetesクラスタとGitリポジトリ、書き込み権限のあるトークンを用意する
  2. Flux Operatorをインストールし、FluxInstanceでインストールするコンポーネントとバージョンを宣言する
  3. GitRepositoryで対象リポジトリとブランチ、リコンサイル間隔を宣言する
  4. Kustomizationで適用対象のパスと同期先namespaceを宣言する
  5. Gitへpushし、リコンサイルでクラスタが宣言通りに収束することを確認する

マネージドKubernetesに載せる場合、クラスタ側の準備はAmazon EKSとはの解説のようなマネージドサービスの理解が前提です。コンテナオーケストレーション（Kubernetes）の役割を押さえたうえで、その上の継続的デリバリー層としてFluxを重ねる構図になります。

Image Automationによる自動デプロイの設計判断

image-automationを入れると、CIがイメージをレジストリへpushした瞬間に、Fluxがそれを検出してGitのタグを書き換え、リコンサイルで本番へ反映する、という完全自動のパイプラインが組めます。開発速度は上がりますが、無条件に有効化すると「テストが通っただけのイメージが本番へ直行する」危うさがあります。

実務では、開発・ステージングは自動更新、本番はImagePolicyをセマンティックバージョンの安定タグに限定し、昇格はPull Request経由の手動マージにする、という段階設計が現実解です。自動化の範囲を環境ごとに絞ることが、事故を防ぐ勘所になります。

Flux CDを採用すべき企業と見送るべき場面の実務的な切り分け

ツールの優劣ではなく、自社の運用体制に合うかで判断します。ここでは条件を付けて言い切ります。

Flux CDの採用が噛み合う4条件と過剰投資になる見送り場面

採用が噛み合うのは、次の条件が揃う組織です。すでにKubernetesを本番運用している。クラスタやチームが複数あり、構成のばらつきを1つのGitで統制したい。デプロイ権限をCIに配らず、pull型で資格情報の露出を絞りたい。プラットフォームチームがマニフェストとコントローラを保守できる。この4点に当てはまるほど、Fluxの分散コントローラ設計が効きます。

逆に見送るべきは次の場面です。Kubernetesをまだ導入しておらず、コンテナ運用の内製体制もない段階では、GitOps以前にオーケストレーション基盤の学習コストが先に立ち、過剰投資になります。少人数で1クラスタを回し、画面での手動デプロイで十分足りているなら、標準UIのないFluxはかえって運用を重くします。この場合はArgo CDの画面運用や、まずマネージドなCIのデプロイ機能から始める方が身の丈に合うはずです。

導入判断や、GitOps基盤の構築・保守運用の内製化に踏み込むかを検討する段階では、Kubernetesとデリバリー基盤の運用設計を含めて相談できる体制が要ります。当社のWebシステムの保守運用・内製化支援では、GitOps導入後の運用ルール整備やチームへの定着まで含めて伴走します。ツール選定だけで終わらせず、誰がどう運用し続けるかまで設計するのが、この種の基盤で失敗しない条件です。

よくある質問

導入検討でよく挙がる論点を、実装者の視点で簡潔に答えます。

Flux CDは無料で使えますか？

Flux本体はApache License 2.0のオープンソースで、ライセンス費用はかかりません。CNCFのGraduatedプロジェクトとしてコミュニティが開発しています。かつて商用として提供されたWeave GitOpsのエンタープライズ版は提供元の事情で終息しており、現在はFlux OSSと、ControlPlane等が提供するサポート付きディストリビューションを組み合わせる形が主流です。運用の実費はクラスタと人件費の側に乗ります。

Flux CDとArgo CDはどちらが優れていますか？

優劣ではなく運用体制で選びます。コードによる多クラスタ統制やイメージ自動更新を重視するならFlux、開発者へ画面でのセルフサービスを配りたいならArgo CDが向きます。標準UIの有無が最も分かりやすい分岐点です。詳細はArgoCDとはの記事と本記事の比較章を突き合わせて判断してください。

Flux CDの導入にKubernetesは必須ですか？

必須です。FluxはKubernetesのコントローラとして動き、CRDでクラスタ状態を調停するため、Kubernetesクラスタが前提になります。まだクラスタを持たない場合は、マネージドKubernetes（Amazon EKS等）の導入が先行します。GitOpsはその上に重ねるデリバリー層と捉えてください。

push型のCIからGitOps（pull型）へ移行する利点は何ですか？

デプロイ資格情報をCIへ渡さずに済むことと、手作業のドリフトが自動で是正されることです。push型はCIがクラスタへ直接権限を持ちますが、pull型はクラスタ内のコントローラがGitを取りに行くため、権限の露出面が縮みます。Gitが唯一の正になるため、誰が何をいつ変えたかの監査もコミット履歴で追えます。

Flux CDのバージョンはどう管理すべきですか？

Fluxはv2.8系（2026年5月時点でv2.8.8）まで進んでおり、依存ライブラリの脆弱性対応（go-git経由のCVE修正など）が随時入ります。Flux Operatorを使えばFluxInstanceのバージョン指定で宣言的にアップグレードでき、更新自体もGitOpsの管理下に置けます。セキュリティ修正を含むパッチは、動作確認のうえ計画的に追随する運用が無難です。

関連記事

資料請求

RELATED POSTS 関連記事

一覧へ戻る