アプリケーションデプロイおよびライフサイクル管理ツールのArgo CDは、バージョン3.3のリリースにより新たなマイルストーンに到達した。人気のGitOps継続的デリバリーツールの機能を拡張するとともに、運用担当者が長年抱えてきた複数の課題に対処する。
Argo CD 3.3は、大規模なアーキテクチャ変更ではなく、日常的なGitOps運用における長年のギャップを埋める実践的なリリースとして位置付けられている。リリース候補版は、削除時の安全性、認証体験、リポジトリ性能、クラスターおよびオートスケーリングリソースに対するより精緻な制御に焦点を当てている。
/filters:no_upscale()/news/2026/02/argocd-33/en/resources/1Screenshot%20From%202026-02-28%2023-14-33-1772321393615.png)
リリース候補版公開時に掲載された発表ブログにおいて、ソフトウェアエンジニアのPeter Jiang氏は、Argo CD 3.3におけるもっとも目に見える変更点としてPreDeleteフックを紹介している。これは既存のPreSync、Sync、PostSyncフックに加わり、ライフサイクルを完成させる。ブログの中でJiang氏は、これまでユーザーはアプリケーション削除前の準備として外部スクリプト、手動クリーンアップ、またはKubernetesのファイナライザーに依存してきたと説明している。これらは、予測可能な終了シーケンスが求められる場面において脆弱または不透明であることが多かった。PreDeleteフックにより、チームはArgo CDがアプリケーションの他のリソース削除を進める前に実行および成功しなければならないKubernetesリソース（例。Job）を定義できる。フックが失敗した場合、削除はブロックされる。実運用においては、これにより削除が明示的なライフサイクルフェーズとなり、データエクスポート、トラフィックのドレイン、依存システムへの通知などを組み込める。
本リリースにおける第2の主要機能は、OIDCバックグラウンドトークンリフレッシュである。これはKeycloakなどのプロバイダーとArgo CDを統合するユーザーから頻繁に寄せられていた不満に対応する。従来は、エンジニアが作業中であってもアクセストークンの有効期限が短い場合にユーザーインターフェースからログアウトさせられることがあり、長時間のデバッグやデプロイ作業中の大きなストレス要因となっていた。新たな挙動では、OIDCトークンの有効期限切れ前にバックグラウンドで自動更新が行われる。更新は、残存有効期間がどの程度になったら更新するかを定める設定可能なしきい値により制御される。LinkedInに投稿したDeepak Yadav氏は、これを際立った変更点の一つとして挙げ、「ランダムなログアウトにさようなら。」と要約し、この問題がどれほど強く認識されていたかを示している。
Gitリポジトリのオプションによるシャロークローンも追加された。有効化すると、Argo CDはリポジトリ全体ではなく必要なコミット履歴のみを取得する。発表によれば、大規模なモノレポや長期運用プロジェクトにおいて取得時間を数分から数秒へ短縮できる可能性がある。本機能はリポジトリ設定のフラグとして実装されており、ワークフロー上フル履歴が不要であると判断した運用担当者向けのオプトイン型パフォーマンス最適化である。コミュニティ投稿でも、3.3の主要ハイライトとしてPreDeleteフックやOIDCリフレッシュと並び、シャロークローンが一貫して挙げられている。
発表では、複雑な構成ワークフロー処理において重要性を増しているSource Hydratorの改善にも言及している。新バージョンではインラインパラメータ対応が導入され、設定変更ごとに個別のパラメータファイルをコミットする必要がなくなった。また、モノレポ構成への対応強化と、不要なrepo server呼び出しを回避するパフォーマンス改善も追加された。Jiang氏はこれらの変更をコミュニティ貢献者によるものとし、大規模構成管理により適したArgo CDへ進化させる継続的取り組みの一環と位置付けている。これらの変更により、Source Hydratorは、マルチアプリケーション展開における構成複雑性に対応する仕組みとして、従来のApplicationSetsと並ぶ存在となった。
クラスターリソースに対する粒度の高い制御も3.3で改善された。AppProjectsにおけるclusterResourceWhitelistが拡張され、APIグループおよび種類だけでなく個別リソース名による制限も可能となった。これにより、すべてのCRDではなく特定のCustomResourceDefinitionsのみを管理対象にできる。発表では、共有クラスター上で複数チームやコントローラーを運用するユーザーからの長年の要望であったと説明している。LinkedIn上のコメントでは、この変更をRBAC制御全体の改善の一環と評価し、CRDのより精緻なスコープ設定が組織のセキュリティポリシーや職務分離により適合すると指摘している。
本リリースでは、Kubernetes Event-driven AutoscalingプロジェクトであるKEDAへのファーストクラスサポートも導入された。Argo CDはユーザーインターフェースからKEDAのScaledObjectsおよびScaledJobsを直接一時停止および再開可能になり、ScaledJobのヘルス状態も認識する。従来の汎用的な「Unknown」表示は置き換えられる。コミュニティ投稿では、メンテナンスウィンドウやデバッグ時に特に有用であると評価されている。運用担当者は他のアプリケーションリソースと同じGitOps制御面からイベント駆動型ワークロードを一時停止できるからだ。
これらの主要機能に加え、Jiang氏は段階的改善を支える複数の小規模変更も挙げている。Redis認証情報のボリュームマウント利用、Ceph CRDのヘルスチェック追加、ApplicationSetユーザーインターフェースの進化、APIグループによるCLIフィルタリング対応、設定可能なKubernetes APIタイムアウト、リフレッシュ動作やビュー拡張に関するユーザーインターフェース改善などである。
全体として、v3.3は実際の運用上の痛みによって形作られたリリースのように感じます。Argo CDのメンテナーおよびコントリビューターの皆さん、よくやりました。これは確かな前進です。
— Deepak Yadav氏
Argo CDと並び、FluxはKubernetes向けGitOpsを実装するもう一つの主要なCNCFインキュベーションプロジェクトとして台頭している。ただし、中央集約型Webアプリケーションではなく、コントローラー駆動モデルを重視している点が特徴である。FluxはGit、Helmリポジトリ、コンテナレジストリをクラスターと整合させる一連のコントローラーを実行し、HelmおよびKustomizeをネイティブにサポートする。可視化はバンドルされたダッシュボードではなく、Weave GitOpsインターフェースを通じてオプションで提供される。安全な削除を実現するため、リソースに対するpruningや保護アノテーションなどの概念を使用する。これにより、バージョン管理から消えたリソースをどの程度積極的にクリーンアップするかを調整しつつ、特定オブジェクトの削除を防止できる。
Argo CDとFluxは、厳密な競合というよりも補完的存在として位置付けられることが多い。Argo CDは組み込みUIとArgo Rolloutsとの緊密な統合により、視覚的制御やカナリアリリース、ブルーグリーンデプロイメントを重視する組織に適している。FluxのGitOps Toolkitは、イメージレジストリを監視しマニフェストを自動更新する、構成可能でCLI志向のスタックを提供する。Redditのユーザーからは、両ツールを併用しているとの報告もある。例えば、Fluxでコアクラスターインフラを管理し、Argo CDでアプリケーションレベルのデプロイメントを統括する構成である。
Argo CD 3.3.2は現在利用可能だ。