プル型GitOpsでFluxを避けるべき理由を解説します。CICDパイプラインを使ったプッシュ型GitOpsも有力な選択肢ですが、最良の選択肢はArgoCDです。
プル型GitOpsならArgoCDがベスト
Kubernetesを使い込むほど、誰もがGitOpsの価値に気づきます。次に話題になるのがベストプラクティスです。ArgoCDか、それともFluxCD v2か。ほかに選択肢はあるのか。こうした疑問をお持ちなら、この記事はうってつけです。
本記事では、Fluxを避けるべき理由と、プル型GitOpsを実践するならArgoCDが最適である理由を解説します。さらに検討に値するもう一つの選択肢として、CICDパイプラインを使ったプッシュ型GitOpsも紹介します。
そもそもGitOpsに何を期待していたのか
まず前提として、GitOpsは以前のソリューションが生んだ問題への有効な解決策です。Infrastructure as Code(IaC)は再現性の高いデプロイを可能にし、Single Source of Truthが大規模チームの足並みをそろえ、コミュニケーションコストを最小限に抑えてくれます。ただしIaCのこうした恩恵は、インフラの実状態がGit上で定義された望ましい状態と一致していてこそのもの。GitOpsは、現実とGitを同期し続けるという、新たに浮上した構成ドリフト問題を解決します。
GitOpsで構成ドリフトを解決すれば、最小権限の原則も守りやすくなり、ロールベースアクセス制御(RBAC)もシンプルになります。人に対して読み取り専用のkubectlアクセスを付与する代わりに、読み取り専用のGitリポジトリアクセスで済ませられます。kubectlの直接アクセスは最小限にとどめ、GitOps用サービスアカウントとGitリポジトリにRBACを適用すればよいのです。
さらにGitOpsは、Gitに組み込まれたセキュリティ統制をそのまま継承できます。マージにピアレビューを必須にすれば、デプロイにもピアレビューが必須になります。Gitの履歴は、誰が何をいつ変更し、誰が承認したのかを示す監査証跡として機能します。
プル型GitOpsでFluxCDよりArgoCDを推す理由
結論を一言で言うと、ArgoCDはFlux v2に比べてはるかに成熟しており、ユーザー体験も段違いに優れているからです。
第一に、Argoで不正な構成をプッシュしても、SSOでGUIにログインすればエラーの有無と発生箇所が視覚的に示され、わかりやすいエラーメッセージも表示されます。一方Fluxでは、そもそもエラーが起きているかどうかを把握すること自体が困難です。エラーメッセージを出すには、適切なCLIツールを使い、適切なネームスペースの適切なオブジェクトに対し、適切なコマンドを実行する必要があります。kubectlで表示されるエラーもあれば、fluxctlで表示されるエラーもあるのです。
第二に、上述したメリットをもたらす真の意味でのプル型GitOpsを実現できるのは、ArgoCDだけです。Argoならkubectlアクセスなしでも問題を解消できます。Gitに変更をプッシュすれば、Argoが稼働中のクラスタをGitに基づいて絶え間なく同期し、結果をGUIで返してくれます。
これがFluxだと、kubectlアクセスなしでは問題を解消できません。仮に時間をかけて、エラーを浮かび上がらせるアラート付きの完璧なロギングパイプラインを構築したとしましょう。それでもFluxは、ArgoのようなKISSな無限リコンサイルループを採用していません。代わりに脆弱なイベント駆動型のリコンサイルループを使っており、頻繁に異常状態でスタックします(特にHelm利用時に顕著です)。
前職で、私はFluxを使ったGitOpsのトレーニングを数百人に行いました。その際、20人中少なくとも5人の環境でFluxが「スタック」していました。混乱状態が解消されるまでリコンサイルは止まり、Gitリポジトリの変更は一時的に無視されるため、手動での介入が必要になります。
復旧の唯一の手段は、いくつかのfluxctlコマンドを実行することです。しかもfluxctlはkubectlに依存しており、状態を修正する必要があるため読み取り専用アクセスでは事足りません。典型例が「install retries exhausted」エラーです。Git側で問題を直していても、Fluxは「exhausted」状態になった時点で諦めてしまうので意味がありません。再デプロイを強制するには複数のfluxctlコマンドが必要です。デフォルト設定をretries = -1(無限)に変更することもできますが、これでは根本解決にならず、スタックの頻度が下がるだけです。Fluxは変更を検知したときだけデプロイロジックを動かそうとします。そしてHelm関連の変更を検知できず、リコンサイルに失敗するエッジケースも存在します。
FluxがArgoより優れているケースはあるのか
ArgoCDは、Helmのあまり使われない高度な機能の一部を意図的にサポート対象外としています。その代わり、最も一般的なユースケースにおける鉄壁の安定性に注力しているのです。Helm Hooksのような高度な機能を使うHelmチャートを利用している場合、ArgoCDが対応していない可能性があります。Helm機能のカバー範囲という点ではFluxに分があります。
ほかにどんな選択肢があるのか
GitOpsの実装方法を検討するチームでは、次のようなパターンをよく目にします。
ArgoCD対FluxCD、そしてオペレータパターンに倣ったその他ツールが過剰に並ぶ構図です。これらのツールはおそらく「GitOps」で検索した際に上位に出てくるものなのでしょう。
見落とされがちなもう一つの選択肢は、Gitリポジトリに保管したIaCやスクリプトロジックを、汎用的なCICDパイプラインから参照する方式です。私はこれをプッシュ型GitOpsと呼んでいます。命令型と宣言型のデプロイロジックを手軽に併用でき、破壊的変更を伴うアップデートのような厄介なケースにも対応しやすい点が気に入っています。こうした問題は、純粋なプル型・宣言型のGitOpsソリューションでは解決が難しいのです。
まとめ
GitOpsをこれから導入する方は、Fluxを候補から外して構いません。GitOpsの実装には、ArgoCDかCICDパイプラインのほうがはるかに優れた選択肢になります。