Argo CD と Flux — 一つのアプリケーションコントローラと複数コントローラの組み合わせ

一言でいうと

Argo CDは、APIサーバー・リポジトリサーバー・アプリケーションコントローラーの3つの部品がApplicationという1つのリソースを中心に動き、Fluxは、source・kustomize・helm・notification・imageの各コントローラーがそれぞれのCRDを担当して組み合わさります。アラートとメトリクスは、どちらのツールも標準的な方式(アノテーション/CRD、Prometheus)でつながります。

なぜ必要なのか

CGOAのToolingドメイン(14%)は、「調整器としてArgo CDとFluxがある」と知っているだけでは終わりません。2つのツールが同じ原則を異なる構造で実装していること、そのためHelmの扱い方が違い、UIの有無が違い、マルチテナンシーの解き方が違うことを問います。実務でもツールを選ぶときは、「どちらがよいか」より「うちのチームはどの構造に合うか」のほうが答えに近いものです。

どう動くのか

Argo CD: 3つの部品とApplication

公式のアーキテクチャドキュメントにある3つの構成要素です。APIサーバーはgRPC/RESTサーバーで、Web UI・CLI・CI/CDシステムが使うAPIを提供し、アプリケーションの管理と状態の報告、syncやrollbackなどの操作の呼び出し、リポジトリとクラスターの認証情報の管理(K8s Secret)、外部IdPへの認証の委任、RBAC、そしてGit Webhookの受信を担当します。リポジトリサーバーは、Gitリポジトリのローカルキャッシュを維持し、リポジトリURL・リビジョン・パス・テンプレート設定(parameters、values)を入力として受け取り、マニフェストを生成します。アプリケーションコントローラーは、実行中のアプリケーションを継続的に監視して、実際の状態と望ましい状態を比較し、OutOfSyncを検知し、PreSync・Sync・PostSyncのフックを呼び出します。

Git/Helm/OCI  ──►  repo-server (렌더: helm template / kustomize build)
                        │
                        ▼
              application-controller ──► 클러스터(들)   비교·sync·훅
                        ▲
UI / CLI / CI  ──►  api-server (RBAC, 인증, 웹훅 수신)

Flux: GitOps Toolkitのコントローラーの組み合わせ

Fluxは、「GitOps Toolkit」と呼ばれる専用のコントローラー・組み合わせ可能なAPI・Goパッケージの集まりで、各コントローラーは自分のCRDだけを担当します。

コントローラー	CRD	担当すること
source-controller	GitRepository、OCIRepository、HelmRepository、HelmChart、Bucket	ソースを定期的に確認してアーティファクト(tar.gz)を作り、クラスター内で提供します
kustomize-controller	Kustomization	アーティファクトをKustomizeでビルドして適用し、SOPSの復号、サービスアカウントの偽装(impersonation)、ヘルス評価、depends-onによる順序付け、削除されたオブジェクトの整理(prune)を行います
helm-controller	HelmRelease	HelmChartのアーティファクトで実際のHelmアクション(インストール・アップグレード・テスト・ロールバック・削除)を実行し、失敗時は自動で対処します
notification-controller	Provider、Alert、Receiver	外部のイベントを受けて(Receiver)調整を起こし、コントローラーのイベントを外部へ送ります(Provider/Alert)
image-reflector/automation	ImageRepository、ImagePolicy、ImageUpdateAutomation	レジストリをスキャンしてポリシーに合う新しいタグを見つけ、Gitにコミットとして書き戻します

Sourceは「リポジトリの出どころと、それを取得する条件(認証情報、バージョンセレクター)」を定義し、決まった間隔で確認して、新しいバージョンがあれば新しいアーティファクトを作ります。1つのソースを複数のコンシューマーが共有できます。Kustomizationはデフォルトで5分ごとに調整し、kubectl edit/patch/deleteで変えたものはすぐに元に戻されます。すべてのFlux CRDはリソースカテゴリに登録されているので、kubectl get fluxcd -Aの1回ですべてを見られます。bootstrapは、Flux自体の構成要素をGitRepositoryとKustomizationとして適用し、Fluxが自分自身を管理するようにする手順です。

構造が生む違い

最もよく問われる違いはHelmです。Argo CDはhelm templateでレンダリングするだけで、ライフサイクルを自分で管理するので、Helmのリリース履歴やHelmフックのセマンティクスには頼りません。Fluxのhelm-controllerは、HelmReleaseを見て実際のHelmのインストールやアップグレードを実行し、Helmテストとロールバックを含む自動対処(remediation)を提供します。2つ目は画面です。Argo CDはAPIサーバーとWeb UIが核となる構成要素で、FluxはCLIが基本で、UIはFlux Operator・Capacitor・Headlampのプラグイン・Weave GitOpsのような別のプロジェクトの一覧で案内されています。3つ目はマルチテナンシーです。Fluxは「偽装(impersonation)による本物のKubernetes RBAC」で、Kustomizationごとにサービスアカウントを指定し、Argo CDはAppProjectと独自のRBACで分けます。

アラート: どこに何をつなぐか

Argo CD Notificationsは、アプリケーションの状態の変化を監視して、トリガーとテンプレートでアラートを作ります。カタログに便利なトリガーとテンプレートがあるのでそのまま使え、サービスはargocd-notifications-cmとargocd-notifications-secretに登録し、購読はApplicationやProjectにnotifications.argoproj.io/subscribe.on-sync-succeeded.slack: <채널>のようなアノテーションで設定します(プレースホルダーはチャンネル名です)。Fluxは、コントローラーがリソースの状態が変わるたびにKubernetesのイベントを出し、notification-controllerがProvider(type: slackなど、secretRef)とAlert(providerRef、eventSourcesでkind/nameを選択、eventSeverity info/error)でそれを外部へ送ります。GitHub・GitLab・Gitea・Bitbucket・Azure DevOpsのプロバイダーは、チャットの代わりにコミットステータスとして返す点が違います。

オブザーバビリティ: Prometheusのメトリクス

Argo CDは、サーバーごとに異なるメトリクスのセットを出し、アプリケーションコントローラーのメトリクスはargocd-metrics:8082/metricsでスクレイプします。argocd_app_info(sync_statusとhealth_statusのラベルを持つgauge)、argocd_app_sync_total(counter)、argocd_app_reconcile(histogram)が代表的です。Fluxのコントローラーは、デフォルトでポート8080の/metricsに、gotk_reconcile_duration_seconds_bucket{kind,name,namespace,le}のような調整の所要時間のヒストグラムと、controller_runtime_reconcile_total{controller,result}を出します。Fluxリソース自体の状態のメトリクスは、コントローラーが出すのではなくkube-state-metricsで収集し、flux2-monitoring-exampleリポジトリが用意された構成を提供しています。

CIとの連携

どちらのツールもCIを実行しません。連携のポイントは3つです。1つ目は、CIがGitを変えると、Webhookで調整を前倒しにすることです(Argo CDの/api/webhook、FluxのReceiver)。2つ目は、Argo CDのAPIサーバーはCI/CDシステムが呼び出すAPIなので、パイプラインがsyncを要求したり状態を照会したりできることです。3つ目は、Fluxのイメージ自動化が、CIがレジストリに上げた新しいタグを見つけてGitにコミットとして書き戻すので、CIがマニフェストを直さなくてもデプロイが続くことです。どの場合でも、クラスターを変える主体は調整器の1つです。

現場での姿

Argo CDを使うチームから、「Syncedなのに実際のPodが古いイメージのまま」という問い合わせがよくあります。原因はたいてい調整器ではなく、その前にあります。CIがタグを変えていない、リポジトリサーバーのキャッシュがまだ古いリビジョンのままである、Webhookが来ずに3分のポーリングを待っている最中である、のいずれかです。メトリクスでargocd_app_infoのsync_statusとGitの最新コミットを一緒に見れば、どの段階で止まっているかが分かれます。

Fluxでは、kubectl get fluxcd -Aを最初に見れば、たいてい答えが出ます。GitRepositoryがReadyでなければsourceの段階、KustomizationがReadyでなければ、ビルド・適用・ヘルス評価のどこで詰まったかが、コンディション(condition)に書かれています。

次のクイズで確認すること

IaC・CI/CDとGitOpsの境界、Webhookがpullの原則とどう両立するか、in-clusterとexternalの調整器での認証情報の置き場所、段階的デプロイとGitの宣言の関係、Argo CDの3つの部品の役割、FluxのコントローラーとCRDの対応、Helmの扱い方の違い、アラートとメトリクスがつながる場所を問います。参考: Argo CD Architectural Overview、GitOps Toolkit components、Argo CD Notifications、Flux alerts、Argo CD Metrics、Flux Prometheus metrics。