Argo CD Argo CD

Push と Pull：Argo CD が Kubernetes にデリバリーする仕組み

Git 主導の pull 型デリバリーが、デプロイ、セキュリティ、復旧の方法をどう変えるか。

8 min learn.level.初級

多くのチームは、Kubernetes へのデプロイを同じ方法で始めます。CI システムがイメージをビルドし、クラスターに対して kubectl apply や helm upgrade を実行します。これは機能しますが、アプリケーションやクラスターの数が増えるまでです。このガイドでは、Argo CD のようなクラスター内のエージェントが代わりに Git から望ましい状態を pull する場合に何が変わるのか、そしてどのようなトレードオフがあるのかを説明します。

push モデルと、その限界

push 型パイプラインでは、CI ジョブだけがクラスターに触れます。

  1. commit がテストとイメージビルドを起動します。
  2. ジョブがマニフェストの新しいイメージタグを更新します。
  3. ジョブがクラスターに対して kubectl apply（または helm upgrade）を実行します。

スケールすると、3 つの問題が現れます。

  • 認証情報がクラスターの外にある。 すべてのパイプラインに kubeconfig やクラウドの認証情報が必要で、アプリケーションとクラスターが増えるたびにそれが増えます。
  • ツールがランナー上にある。 kubectl、helm、およびそれらのバージョンを、デプロイが実行されるすべての場所にインストールして揃えておく必要があります。
  • フィードバックが「適用済み」で止まる。 ジョブは API サーバーがマニフェストを受け付けたことは知っていますが、Pod が実際に健全になったかどうかは分かりません。

方向を反転する：pull

pull モデルでは、エージェントがクラスター内で動作し、Git リポジトリを監視して、そこに宣言されている内容と稼働中の内容を比較し、差分を適用します。

Developer ─▶ App repo ─▶ CI (test, build) ─▶ Image registry
                            │
                            └─ commits new image tag ─▶ Config repo
                                                            ▲
                                        Argo CD (in cluster) ┘ pulls, compares, applies
                                                │
                                                ▼
                                            Kubernetes

変更を適用するのはクラスター内で動作するエージェントだけなので、クラスターの認証情報はクラスターの外に出ません。エンジニアや CI システムに必要なのは Git への書き込み権限だけです。Argo CD はプレーンな YAML、Helm チャート、Kustomize オーバーレイを読み取り、適用前に Kubernetes マニフェストにレンダリングします。

アプリケーションコードと設定を別のリポジトリに分ける

一般的な推奨は 2 つのリポジトリです。1 つはアプリケーションのソースコード用、もう 1 つは Kubernetes の設定（Deployment、Service、ConfigMap、Ingress など）用です。

理由は、設定が独自のスケジュールで変わるからです。Service や ConfigMap を編集するたびに、変更のないコードのビルドとテストのパイプライン全体を実行すべきではありませんし、commit を調べて何をスキップするか判断するパイプラインロジックも避けたいところです。CI パイプラインの最後のステップは「新しいイメージタグを設定リポジトリに commit する」になり、あとは Argo CD が引き継ぎます。責任範囲もきれいに分かれ、開発者が CI を、プラットフォームチームや運用チームがデリバリーを担当します。

Git を唯一の入口にする：ドリフト検出とセルフヒール

Argo CD はリポジトリに加えて、稼働中のクラスターも監視します。両者が一致しない場合、アプリケーションは OutOfSync と報告されます。設定によっては、Argo CD は通知するだけか、クラスターを Git に合わせて元に戻します（このシリーズの同期ポリシーのガイドを参照）。

これには実用的な効果があります。

  • すべての変更に commit、作成者、通常はレビュー済みのプルリクエストがあり、監査証跡が得られます。
  • 権限が Git に移ります。経験の浅いエンジニアはプルリクエストを開き、マージできるのは少数だけにできます。これを実現するために、個人ごとのクラスターロールは不要です。
  • 本番環境での手軽な kubectl edit が、見えない変更ではなくなります。

ロールバックと復旧が Git の操作になる

望ましい状態がバージョン管理されているため、既知の正常な状態に戻すには git revert を実行するだけで、Argo CD がクラスターをそれに収束させます。復旧にも同じ考え方が当てはまります。クラスターが失われた場合は、新しいクラスターを作成して Argo CD をインストールし、同じリポジトリを登録すれば、ワークロードはそこから再作成されます。永続データや別の場所で管理しているシークレットなど、Git にないものについては、引き続き独自のバックアップ戦略が必要です。

1 つの Argo CD インスタンスで多数のクラスターを管理することもできるため、1 つのリポジトリでクラスター群全体を動かせます。

Argo CD が置き換えないもの

Argo CD はデリバリーツールであり、ビルドツールではありません。コードのテスト、イメージのビルド、レジストリへのプッシュには、引き続き CI が必要です。また Kubernetes 専用なので、他のデプロイ先には別のツールが必要です。そして唯一の GitOps コントローラーでもありません。Flux は同じ原則を異なる設計で実装しています。このシリーズの以降のガイドは Argo CD を前提とし、そのインストールから始めます。詳しいリファレンスは、Argo CD 公式ドキュメントを参照してください。

人気のガイド