FluxCDは2016年にイギリスのWeaveworks社が開発した、Kubernetesへの継続デプロイを「Gitリポジトリ＝唯一の真実」という原則で実現するOSSツールです。同社CEOアレクシス・リチャードソンが2017年に「GitOps」という言葉を提唱した際の中核実装であり、業界に「コードレビューでインフラを変える」考え方を浸透させました。v2では完全にKubernetesカスタムリソース化され、CNCFのGraduatedプロジェクト（2023年）に昇格。Argo CDと並ぶGitOpsエコシステムの両輪として運用されています。
この記事の目次
- ソースとリコンシリエーションの構造
- Weaveworks発・GitOps概念の発祥
- 実運用での典型パターン
- Argo CDとの違いと選びどころ
- まとめ
ソースとリコンシリエーションの構造
FluxCD v2はKubernetes上に常駐する複数のコントローラから構成されます。「Source Controller」はGitリポジトリ・Helmリポジトリ・OCIアーティファクトなどの外部ソースを定期的にfetchし、内部のキャッシュに保持します。次に「Kustomize Controller」がそのキャッシュからkustomize buildを行い、現在のクラスタ状態と突き合わせて差分を kubectl apply 相当の処理で適用します。
「Helm Controller」はHelmChart／HelmReleaseカスタムリソースを監視し、宣言された通りにHelm chartをインストール・アップデートします。「Notification Controller」はGitOps変更をSlackやMicrosoft Teamsに通知する役割を担います。これらは全てKubernetesカスタムリソースとして宣言され、Flux自体もまたGitOpsで運用される自己ホスト構造になっています。プル型でクラスタ側から取りに行くため、CIシステムにクラスタ認証情報を渡す必要がなく、セキュリティ面で強みがあります。
Weaveworks発・GitOps概念の発祥
Weaveworksはネットワーク・ストレージ系のKubernetesツールで知られた英国企業で、CEOアレクシス・リチャードソンが2017年8月に同社ブログ「Guide to GitOps」で『GitOps』という造語を世に出したことが、FluxCDが歴史に名を残す契機となりました。『運用変更は全てGit経由のPRで行い、コードレビューを通してマージし、自動的にクラスタへ反映する』という方法論を、Fluxは実装として体現していました。
2021年にv2がリリースされ、単一のFluxバイナリから複数コントローラのモジュラ構成へ刷新。同年Argo CDと共にCNCF Incubatingに採択され、2023年7月にはGraduated（卒業）プロジェクトに昇格しました。皮肉にも親会社のWeaveworksは2024年に営業停止を発表しましたが、FluxCD自体はCNCF配下で開発が継続されており、コミュニティガバナンスの強さを示す事例となりました。現在もRedHat・Microsoft・AWS等のメンテナが活発にコミットし、Kubernetes標準のデプロイ機構として位置を確立しています。
実運用での典型パターン
FluxCDの典型的なディレクトリ構成は、dev／staging／productionをそれぞれ独立したGitリポジトリまたはディレクトリで管理し、各環境のFluxインスタンスが対応するパスを監視する形です。アプリチームはアプリ用リポジトリにマニフェストを書き、プラットフォームチームはクラスタ初期化用のリポジトリでFlux自体やネットワーク／認証ポリシーを管理する、というように責任境界を明確に分けられます。
「ImageUpdateAutomation」コントローラを使うと、コンテナレジストリ上の新しいタグを検知してGitリポジトリのマニフェストを自動更新できます。CIでイメージをビルドした後、PRやコミットをFluxが書き戻すことで、デプロイサイクルを完全自動化できます。また、姉妹プロジェクトの「Flagger」と組み合わせれば、CanaryリリースやBlue/Greenデプロイをメトリクスベースで自動進行・自動ロールバックできます。OCIアーティファクトをGitOpsのソースとして使う構成も最近主流で、Helm chartと並ぶ配布形式として普及しています。
Argo CDとの違いと選びどころ
GitOpsの双璧であるArgo CDと比較すると、FluxCDは「UIを持たないCRD中心」「軽量で組み合わせ自由」というアーキテクチャ思想が際立ちます。Argo CDが公式UIで状態を可視化することを重視するのに対し、Fluxは kubectl get gitrepositories のようにkubectlで状態を確認することを前提に作られており、プラットフォームエンジニアが既存の監視・通知基盤に組み込みやすい設計です。
選定の判断軸は、組織がUIを必要とするか（運用者の数が多い、開発チームに直接デプロイ画面を見せたいか）、そしてHelm運用がメインかKustomize運用がメインかという点になります。FluxはHelm Releaseの宣言的管理が非常に強力で、Helm chartを多用する組織で好まれます。また、Microsoft Azure Arc-enabled Kubernetes、Red Hat Advanced Cluster Management、VMware Tanzuなど主要KubernetesディストリビューションでFluxが標準採用されており、ベンダーロックインの少ない長期運用基盤として選ばれる傾向があります。
まとめ
FluxCDは『GitOps』という言葉を世に出した張本人であり、Kubernetesへの宣言的デプロイをGitリポジトリ起点で自動化する標準的ツールとして定着しました。CNCF卒業プロジェクトとしてコミュニティ運営は健全で、Argo CDと並ぶGitOpsの双璧として今後も中核インフラを担い続けます。
※本記事はIT用語辞典の手書きドラフトです。公開前に最新情報・出典を確認のうえ加筆修正してください。
コメント