ArgoCD と Flux2 の比較

これはGitOps用ツールに ArgoCD と Flux2 のどちらを選ぶか考えるための調査資料です。

ArgoCD v1.7.8 と Flux2 v0.2.2 の比較をします。

Flux2についてはまだ使い込んでいないので、誤ったことを書いているかもしれません。何か変な記述を見つけたら教えて下さい。

背景

Flux(Flux2) と ArgoCD は GitOps を実践するためのソフトウェアです。
役割がかぶっているため、インフラ構築時には基本的にどちらか片方を選択することになります。

GitOps は Weaveworks の提唱した概念で、この会社は Flux の開発元です。
ArgoCD の開発元は Intuit です。
いずれも k8s ネイティブな OSS プロダクトとして作られています。

Flux2 はもともと GitOps toolkit (=gotk) という名前で開発されていましたが、v0.2.0 のリリースで Flux2 にリネームされました。

機能比較

機能が大きくかぶっているため、差分に着目して機能を比較します。

GUI/CLI

ArgoCDにはGUIダッシュボードがあります。
単なる閲覧だけでなく、変更操作も行えます。
argocd という CLI ツールもあります。基本的に行えることは GUI とほぼ同じです。

Flux2 には GUI はありません。flux というCLIツールを使います。

diffing

ArgoCDを使うと、今クラスタに作成されているオブジェクトと、Gitリポジトリのマニフェストのdiffを見ることが出来ます。また、このdiffに基づき、Gitリポジトリの更新がないときも自動的に再同期する self-healing 機能があります。

Flux2 ではそのような機能を提供していません。Flux2 では diff 計算をせず、対象のGitリポジトリのリビジョンが更新されたら kubectl apply するという仕組みを採用しています。(カスタムWebhookでpushベースの同期を行うことも可能です)
なお今は kubectl diff があるので、人が diff を確認する分には Flux2 でも困りません。

権限管理

ArgoCD は OIDC プロバイダ(dexなど)と連携させることで、SSO を行うことができます。
これは k8s とは独立した権限管理です。
k8s の RBAC を ArgoCD を使用するテナントの権限管理に使うことはできません。ArgoCD には非常に強い権限を渡しておくことになり、テナントの権限は上述の仕組みで認可します。

Flux2 にはユーザー管理機能はありません。
その代わりに k8s の RBAC で権限制御することができます。
具体的に言うと、kustomization.yaml ごとに kubectl apply に使う service account を指定できます。なので namespace ベースの普通のマルチテナンシーを実践していれば、それを活用できます。

通知

ArgoCD で同期に関するイベントを通知したいときは ArgoCD Notifications というアドオンコンポーネントを導入します。
後付けの機能なので、Application CRのアノテーションに多少記述することになります。
通知の発火条件を condition というフィールドに式で書くことができます。

Flux2 では Alert CR と Provider CR で通知設定を記述できます。
ArgoCDのような condition という概念はありません。

自動イメージ更新

ArgoCD には ArgoCD Image Updater というアドオンコンポーネントがあります。
これを使うと新たなイメージタグがコンテナリポジトリに追加されたとき、自動でイメージを更新することができます。semver に従ったタグ付けをしていれば、自動更新を許可するバージョン区間を指定できます。

Flux2 ではこれと似たような機能を実装予定です。もともとFluxで実装されていたので、それを継承する形になります。

同期順序の制御

ArgoCD のリソースの同期順序は sync-wave というアノテーションで制御します。sync-wave には phase という番号を指定することになります。番号なのでメンテが若干面倒です。

Flux2 では Kustomization CR 同士の依存関係を dependsOn フィールドに設定すると、その順番に同期されます。

カスタムリソースのヘルスチェック

ArgoCDでもFluxでも、同期対象となるリソースをあるひとまとまりの形で Application/Kustomization CR を用いながら管理することになります。
Application/Kustomization CRのヘルスステータスは、自身が管理しているリソースの状態から決定されます。
管理対象がk8sビルトイン系リソースなら、自動でそれを読んでくれるのですが、カスタムリソースの場合はそうはいきません。そのようなとき、カスタムヘルスチェックが欲しくなります。

ArgoCD においてApplicationのヘルスチェックをカスタムリソース用に作り込みたいときは、luaを使って書くことができます。ただし有名なカスタムリソースのヘルスチェックはArgoCDにビルトインされているので、書かずに済むケースもあります。

Flux2 においてKustomizationのヘルスチェックをカスタムリソース用に作り込みたいときは、カスタムリソースにkstatus用のインターフェースを実装することになります。

暗号化Secretの復号

ArgoCD では暗号化 Secret のための機能は提供されていませんが、kustomize build 実行時の引数を指定することは出来るので、kustomize-sopsをApplication Controllerコンテナの中に仕込み、kustomize build 時に plugin を呼ぶことでsopsによる暗号化Secretを復号できます。

Flux2 では Kustomization CR の機能として sops を呼ぶフィールドが用意されているので、それに従うと kustomize build 時に sops による暗号化 Secret を復号できます。

まとめ

Flux2 のほうが後発なだけあって、よく使うオプション機能をうまくCRD設計に溶け込ませている感じがします。

ArgoCD ユーザーの権限を制御するために独自 RBAC や OIDC プロバイダを用意しなければならないのは大げさだなと思っていたので、
Flux2 の K8s RBAC で権限管理を行うという設計は個人的に好みです。

ただし Flux2 には、GUIダッシュボードや App Diff に相当する機能が無いので、その辺りが重要になる場合はFlux2ではなくArgoCDを選択することになります。