Argo CD 3.3がより安全なGitOps削除とスムーズな日常運用を実現
アプリケーションのデプロイとライフサイクル管理ツールであるArgo CDは、バージョン3.3のリリースにより、人気のGitOps継続的デリバリーツールの機能を拡張し、運用担当者の長年の課題に対処する新たなマイルストーンに到達した。
キーポイント
バージョン3.3のリリース
Argo CDが新バージョン3.3をリリースし、GitOps継続的デリバリーツールとしての機能を拡張した。
運用上の課題への対応
運用担当者が長年抱えていた複数の課題に対処する改善が行われた。
GitOpsの安全性向上
より安全なGitOps削除機能が導入され、日々の運用がよりスムーズになった。
影響分析・編集コメントを表示
影響分析
このリリースは、GitOps実践者にとって重要な運用上の課題を解決し、より安全で効率的な継続的デリバリープロセスを実現する。特に大規模なKubernetes環境での運用負荷軽減に貢献し、DevOpsプラクティスの普及を後押しする可能性がある。
編集コメント
Argo CDの安定性と安全性が向上したことで、本番環境でのGitOps採用がさらに進む可能性がある。運用担当者にとっては具体的な課題解決につながる実用的なアップデートと言える。
アプリケーションのデプロイメントおよびライフサイクル管理ツールである Argo CD が、バージョン 3.3 のリリースにより新たなマイルストーンに到達しました。これは人気のある GitOps 継続的デリバリーツールの機能を拡張すると同時に、運用担当者にとって長年悩まされてきたいくつかの課題に対処するものです。
Argo CD 3.3 は、大規模なアーキテクチャ変更というよりも、日々の GitOps 運用における長年のギャップを埋める実用的なリリースとして位置づけられています。このリリース候補版は、削除時の安全性、認証体験、リポジトリのパフォーマンス、およびクラスターや自動スケーリングリソースに対するより精密な制御に焦点を当てています。
image/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 finalisersに依存しており、チームが予測可能なテardownシーケンスを必要とする際にこれらが脆かったり不透明であったりすることが多いと説明しています。一方、PreDeleteフックを使用すれば、チームはArgo CDがアプリケーションの残りのリソースの削除を進める前に実行して成功させる必要があるJobsなどのKubernetesリソースを定義できるようになり、フックに失敗した場合は削除がブロックされます。実際には、これによりデータのエクスポート、トラフィックのドレイン、依存するシステムへの通知などを含む明示的なライフサイクルフェーズとして削除が可能になります。
リリースの2つ目の主要機能は、OIDC 背景トークンリフレッシュです。これは Keycloak などのプロバイダーと Argo CD を統合するユーザーからの頻繁な不満に対応したものです。以前は、アクセストークンの有効期間が短いため、アクティブに作業中であってもユーザーインターフェースからログアウトされることがあり、長時間のデバッグやデプロイセッション中に大きなストレスの原因となっていました。新しい動作では、OIDC トークンを有効期限切れ前に自動的に背景でリフレッシュします。これは、リフレッシュをトリガーする残存有効期間の閾値を設定可能にすることで制御されます。Deepak Yadav は LinkedIn で、これを目立つ変更の一つとして強調し、「ランダムなログアウトにさようなら」と要約しています。これはこの問題がどれほど強く感じられていたかを反映するものです。
Git リポジトリのオプション浅いクローン(shallow cloning)も追加されました。有効化すると、Argo CD は完全なリポジトリではなく必要なコミット履歴のみを取得します。発表によると、これにより大規模なモノレポや長期間稼働するプロジェクトで取得時間が数分から数秒に短縮される可能性があります。この機能はリポジトリ設定のフラグとして実装されており、ワークフローに完全な履歴が必要ないと判断した運用者が選択的にパフォーマンスを最適化できる仕組みとなっています。3.3 の主要ハイライトを説明するコミュニティ投稿では、浅いクローンが PreDelete フックや OIDC リフレッシュと並んで常に挙げられています。
発表ではまた、複雑な設定ワークフローを処理する Argo CD の中核部分となりつつある Source Hydrator に対する改善も指摘されています。新バージョンではインラインパラメータサポートが導入され、各設定変更ごとに個別のパラメータファイルをコミットする必要がなくなりました。さらにモノレポ構成への対応が強化され、リポジトリサーバーへの不要な呼び出しを避けるためのパフォーマンス向上も行われています。Jiang はこれらの変更をコミュニティの貢献者によるものとし、大規模な設定管理に適した Argo CD を実現するための継続的な取り組みの一環として位置付けています。これらの変更により、Source Hydrator は ApplicationSets における先行する取り組みと並んで、マルチアプリケーション展開における増大する設定複雑性を処理するメカニズムとして位置づけられています。
クラスターリソースに対する粒度の細かい制御も 3.3 で改善されています。リリースでは AppProjects 内の clusterResourceWhitelist が拡張され、アクセス制限が API グループや種別だけでなく、個々のリソース名によっても行えるようになりました。これにより、プロジェクトはすべての CRD(Custom Resource Definitions)ではなく特定の CustomResourceDefinitions のみを管理できるようになり、発表ではこれは共有クラスター上で複数のチームとコントローラーを運用するユーザーからの長年の要望であると説明されています。LinkedIn でのコメントはこの変更を RBAC コントロールのより広範な改善の一部として捉えており、CRD のスコープをより精密に設定することが組織のセキュリティポリシーや職務分離により適合すると指摘しています。
本リリースでは、Kubernetes イベント駆動型自動スケーリングプロジェクトである KEDA に対するファーストクラスのサポートも導入されました。Argo CD は now、ユーザーインターフェースから直接 KEDA の ScaledObjects および ScaledJobs を一時停止および再開できるようになり、ScaledJob のヘルスステートも認識するようになりました。これにより、以前は汎用的な「不明」と表示されていた部分が置き換えられました。コミュニティの投稿では、これはメンテナンスウィンドウやデバッグにおいて特に有用であると評価されており、オペレーターが他のアプリケーションリソースに対して使用している GitOps コントロールサーフェースを通じて、イベント駆動型ワークロードを一時的に停止できるためです。
これらの目玉機能以外にも、Jiang は改善をより漸進的に捉えることを支援する一連の小さな変更点を列挙しています。これらには、Redis 認証情報のためのボリュームマウントの使用、Ceph CRD のヘルスチェック追加、ApplicationSet ユーザーインターフェースの進化、API グループによる CLI フィルタリングのサポート、設定可能な Kubernetes API タイムアウト、およびリフレッシュ動作やビュー拡張に関するいくつかのユーザーインターフェースの改良が含まれます。
全体として、v3.3 は実際の運用上の課題を反映して設計されたリリースという印象を受けます。Argo CD のメンテナーとコントリビューターの方々にお疲れ様でした — これは着実な前進です。
Argo CD と並んで、Flux も Kubernetes 向けの GitOps を実装する CNCF インキュベーションプロジェクトの主要な存在として台頭しましたが、こちらは中央集権型の Web アプリケーションではなく、コントローラー駆動モデルを強調しています。Flux は、Git、Helm リポジトリ、コンテナレジストリとクラスターとの整合性を保つ一連のコントローラーを実行し、Helm と Kustomize をネイティブでサポートします。また、バンドルされたダッシュボードではなく、Weave GitOps インターフェースを通じたオプションの可視化機能を提供します。安全な削除を行うために、リソースに対するプルーニング(不要物の除去)や保護アノテーションといった概念を利用し、オペレーターが特定のオブジェクトが整合性処理中に削除されないように防止したり、バージョン管理から消えたリソースを Flux がどの程度積極的にクリーンアップするかを調整したりできるようにしています。
Argo CD と Flux は、厳密な競合関係というよりは補完的な存在として位置づけられることが多いです。Argo CD の組み込み UI と Argo Rollouts との緊密な統合は、視覚的な制御と、本格的なカナリア展開やブルーグリーンデプロイメントを望む組織にとって魅力的です。一方、Flux の GitOps Toolkit は、イメージレジストリを監視しマニフェストを自動的に更新する、コンポーザブルで CLI 指向のスタックを提供します。Reddit のユーザーからは、両方のツールを併用しているという報告もあります。例えば、コアとなるクラスターインフラストラクチャの管理に Flux を使い、アプリケーションレベルのデプロイメントのオーケストレーションには Argo CD を利用するといったケースです。
Argo CD 3.3.2 は 今すぐ入手可能です。
著者について
Matt Saunders
私はアダプタビストの VP DevOps です。チームが DevOps、プラットフォームエンジニアリング、およびクラウドネイティブなツールや技術を活用して、ストレスを最小限に抑えつつ、迅速かつ効率的に信頼性の高い高品質なソフトウェアを提供できるよう支援しています。複雑な大企業から小規模スタートアップ、中小企業まで、その間のあらゆる組織で経験があります。
また、ロンドン DevOps ミートアップグループの共同運営者でもあり、10,000 名以上のメンバーを抱える非常に人気のある月次業界イベントを主催しています。
もっと見る表示する
原文を表示
The application deployment and lifecycle management tool Argo CD has reached a new milestone with the release of version 3.3, extending the capabilities of the popular GitOps continuous delivery tool while addressing several long-standing pain points for operators.
Argo CD 3.3 is presented as a practical release that closes several long-standing gaps in day-to-day GitOps operations rather than a major architectural change. The release candidate focuses on deletion safety, authentication experience, repository performance and more precise control for cluster and autoscaling resources.
Argo CD Screenshot/filters:no_upscale()/news/2026/02/argocd-33/en/resources/1Screenshot%20From%202026-02-28%2023-14-33-1772321393615.png)
In the announcement blog post, published at the time when the release candidate became available, software engineer Peter Jiang introduces PreDelete hooks as the most visible change in Argo CD 3.3, completing the existing lifecycle of PreSync, Sync and PostSync hooks. In the blog, Jiang explains that users have historically relied on external scripts, manual cleanup or Kubernetes finalisers to prepare for application deletion, which often proved fragile or opaque when teams needed a predictable teardown sequence. PreDelete hooks instead allow teams to define Kubernetes resources, such as Jobs that must run and succeed before Argo CD proceeds with deleting the rest of an application's resources, and a failing hook will block deletion. In practice, this turns deletion into an explicit lifecycle phase that can include data export, draining traffic or notifying dependent systems.
The second major feature in the release is OIDC background token refresh, which addresses frequent complaints from users integrating Argo CD with providers such as Keycloak. Previously, engineers could be logged out of the user interface after a short access token lifetime even while actively working, which was a source of frustration during longer debugging or deployment sessions. The new behaviour automatically refreshes OIDC tokens in the background before expiry, governed by a configurable threshold that determines how much remaining lifetime triggers a refresh. Deepak Yadav, writing on LinkedIn, highlights this as one of the standout changes and summarises it as "Goodbye random logouts", reflecting how strongly this issue was felt.
Optional shallow cloning of Git repositories has also been added. When enabled, Argo CD fetches only the required commit history instead of the full repository, which the announcement notes can reduce fetch times from minutes to seconds in larger monorepos or long-lived projects. This feature is implemented as a flag in repository configuration, making it an opt-in performance optimisation for operators who have assessed that they do not need full history for their workflows. Community posts describing top highlights for 3.3 consistently include shallow cloning alongside PreDelete hooks and OIDC refresh.
The announcement also notes improvements to the Source Hydrator, an increasingly central part of Argo CD's handling of complex configuration workflows. The new version introduces inline parameter support so that teams no longer need to commit separate parameter files for each configuration change, and adds better support for monorepo layouts, together with performance work to avoid unnecessary calls to the repo server. Jiang attributes these changes to community contributors and frames them as part of an ongoing effort to make Argo CD more appropriate for large-scale configuration management. These changes place the Source Hydrator alongside earlier work on ApplicationSets as a mechanism for handling growing configuration complexity in multi-application deployments.
Granular control over cluster resources is also improved in 3.3. The release extends clusterResourceWhitelist in AppProjects so that access can be restricted not only by API group and kind but also by individual resource names. This allows a project to manage only specific CustomResourceDefinitions rather than all CRDs, which the announcement describes as a long-standing request from users who maintain multiple teams and controllers on shared clusters. Commentary on LinkedIn highlights this change as part of a broader improvement in RBAC controls, noting that more precise scoping of CRDs aligns better with organisational security policies and separation of duties.
The release also introduces first-class support for KEDA, the Kubernetes Event-driven Autoscaling project. Argo CD can now pause and resume KEDA ScaledObjects and ScaledJobs directly from the user interface and understands ScaledJob health states, replacing earlier generic "Unknown" indicators. Community posts describe this as particularly useful for maintenance windows and debugging, since operators can temporarily suspend event-driven workloads through the same GitOps control surface they use for other application resources.
Beyond these headline features, Jiang lists a series of smaller changes that collectively support a more incremental view of improvement. These include using volume mounts for Redis credentials, adding Ceph CRD health checks, evolving the ApplicationSet user interface, supporting CLI filtering by API group, configurable Kubernetes API timeouts, and several user interface refinements around refresh behaviour and view extensions.
Overall, v3.3 feels like a release shaped by real operational pain. Well done to the Argo CD maintainers and contributors — this is a solid step forward.
- Deepak Yadav
Alongside Argo CD, Flux has emerged as the other major CNCF‑incubated project implementing GitOps for Kubernetes, but it emphasises a controller-driven model rather than a centralised web application. Flux runs a set of controllers that reconcile Git, Helm repositories and container registries with the cluster, supports Helm and Kustomize natively, and offers optional visualisation through the Weave GitOps interface rather than a bundled dashboard. It uses concepts such as pruning and protective annotations on resources to do safe deletions, allowing operators to prevent specific objects from being removed during reconciliation and to tune how aggressively Flux cleans up resources that disappear from version control.
Argo CD and Flux are often positioned as complementary rather than strictly competing. Argo CD’s built-in UI and close integration with Argo Rollouts make it attractive for organisations that want visual control and first-class canary or blue-green deployments. Flux’s GitOps Toolkit provides a composable, CLI-oriented stack that monitors image registries and automatically updates manifests. Users on Reddit report running both tools together. For example, using Flux to manage core cluster infrastructure and Argo CD to orchestrate application-level deployments.
Argo CD 3.3.2 is available now.
About the Author
Matt Saunders
I am VP DevOps at Adaptavist. I help teams use DevOps, platform engineering and cloud-native tools and technologies to deliver reliable quality software quickly and efficiently and with minimal stress. I've worked with complex enterprises, small start-ups, SMEs and everything in between.
I also co-organise the London DevOps meetup group, which has over 10,000 members, hosting a hugely popular monthly industry event.
Show moreShow less
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み