ArgoCD を使用して GKE クラスタのフリートを構築する
Google Cloud Japan Team
※この投稿は米国時間 2022 年 8 月 31 日に、Google Cloud blog に投稿されたものの抄訳です。
アプリケーションをコンテナ化して Kubernetes 上で実行している組織はしばしば、単一クラスタを実行するだけではニーズを満たせないという状況に直面します。一例として、アプリケーションを新しいリージョンの市場にいるユーザーに近い場所で実行したいとします。新しいリージョンにクラスタを追加すれば、復元性を向上させることができます。この場合のメリットやデメリットについて詳しく知りたい方は、こちらのマルチクラスタのユースケースについての概要をお読みください。
ArgoCD とフリートを使用すると、個々のクラスタではなくクラスタのプロファイルに注目する、簡単に変更できるラベルに基づいてクラスタの状態を定義できるようになるため、マルチクラスタ環境の管理が容易になります。
この投稿では、ArgoCD と Argo Rollouts を使用して GKE クラスタのフリートの状態を自動で管理する方法を説明します。このデモでは、クラスタ オペレータが経験しうる 3 つの状況について取り上げます。
クラスタをデプロイして特別なラベルを付与することに加えて、新しいアプリケーション クラスタをフリートにゼロタッチで追加します。新しいクラスタは、そのクラスタラベルに結び付けられているアプリケーションとともに、ツールとセキュリティのための一連のベースライン構成を自動的にインストールします。
新しいアプリケーションをフリートにデプロイします。フリートは、アプリケーションを開発および配信するチームのためにマルチテナントのベースライン構成を継承し、Kubernetes RBAC ポリシーをチームの ID グループに適用します。
新しいバージョンのアプリケーションをクラスタのグループ（またはウェーブ）全体に段階的にロールアウトします。各ウェーブ間では、手動の承認が必要になります。
このデモで使用されているコードは、GitHub にあります。
ArgoCD フリート アーキテクチャを構成する
ArgoCD は、Kubernetes 向けの GitOps 継続的デリバリーを提供する CNCF ツールです。ArgoCD の機能のうち、最も価値あるものの一つがその UX / UI です。クラスタのフリート全体で UI / UX を維持するには、ハブ アンド スポーク アーキテクチャを使用してください。ハブ アンド スポークの設計では、一元化された GKE クラスタを使用して ArgoCD をホストします（ArgoCD クラスタ）。アプリケーションを Secret としてホストする各 GKE クラスタを、ArgoCD クラスタの ArgoCD Namespace に追加します。各アプリケーション クラスタに特別なラベルを割り当てて、特定できるようにします。フリートに必要な Kubernetes の構成を含む各 Git リポジトリに対して、ArgoCD 構成リポジトリ オブジェクトが作成されます。ArgoCD の同期エージェントは ArgoCD アプリケーションで定義された構成リポジトリを継続的に監視します。そして、ArgoCD Namespace のクラスタの Secret に含まれるクラスタ ラベルに基づいて、アプリケーション クラスタのフリート全体で変更を有効にします。
基盤となるインフラストラクチャのセットアップ
アプリケーション クラスタを使用し始める前に、いくらかの基盤となるインフラストラクチャが必要になります。Fleet infra setup の手順に沿って、Google が提供するデモ ツールを使用し、VPC、リージョンのサブネット、Pod とサービスの IP アドレス範囲、その他の基盤となるインフラストラクチャをセットアップします。これらの手順によって、コントロール クラスタとして動作する一元化された ArgoCD クラスタも作成されます。
ArgoCD クラスタを構成する
インフラストラクチャのセットアップができたら、マネージド Anthos Service Mesh（ASM）、マルチクラスタ Ingress（MCI）、その他のコントロール用コンポーネントを使用して、一元化された ArgoCD を構成できます。まずは、フリートにとって ASM と MCI が非常に重要である理由を考えましょう。
MCI によって、クライアントに最も近いフリート内の GKE クラスタにトラフィックをルーティングするグローバル レイヤ 7 ロードバランサの前に単一のエニーキャスト IP が提供されるため、外部のクライアントからクラスタにルーティングされるすべてのトラフィックのパフォーマンスが向上します。また MCI では、リージョンの障害に対する復元性ももたらされます。クライアントに最も近いリージョンでアプリケーションに到達できない場合は、その次に近いリージョンにルーティングされます。
mTLS、アプリリケーションのレイヤ 7 の指標、その他のいくつかの優れた機能に加えて、ASM は GKE クラスタのフリート全体で Pod 間トラフィックを処理するネットワークを提供します。これは、ローカルの呼び出しが失敗するかエンドポイントがない場合に、アプリケーションが、クラスタ内の他のアプリケーションへの呼び出しを自動的に他のクラスタへリダイレクトするということを意味しています。
Fleet cluster setup の手順に沿って操作します。コマンドによって、ArgoCD のインストール、アプリケーション クラスタのツールと構成のための ApplicationSets の作成、ArgoCD へのログインを行うスクリプトが実行されます。また、GitHub のプライベート リポジトリと同期するように ArgoCD が構成されます。
GKE アプリケーション クラスタを Secret として ArgoCD Namespace に追加して `env: "multi-cluster-controller"` というラベルを付与すると、multi-cluster-controller ApplicationSet が multi-cluster-controllers フォルダ内のサブディレクトリとファイルに基づいてアプリケーションを生成します。 このデモでは、そのフォルダには、各アプリケーション クラスタにインストールされる ASM Ingress ゲートウェイに対してマルチクラスタ Ingress を設定するために必要なすべての構成が含まれています。
GKE アプリケーション クラスタを Secret として ArgoCD Namespace に追加し、`env: "prod"` というラベルを付与すると、app-clusters-tooling アプリケーション セットは app-clusters-config フォルダ内の各サブフォルダに対してアプリケーションを生成します。このデモでは、app-clusters-config フォルダには各アプリケーション クラスタに必要なツールが含まれています。たとえば、argo-rollouts フォルダには、すべてのアプリケーション クラスタにインストールされる必要がある、Argo Rollouts カスタム リソース定義が含まれています。
この時点で、以下が揃っているはずです。
GitHub リポジトリと同期する、一元化された ArgoCD クラスタ。
ArgoCD クラスタと同期する、マルチクラスタ Ingress とマルチ クラスタ サービス オブジェクト。
各アプリケーション クラスタに対して Google Cloud ロードバランサを構成する、マルチクラスタ Ingress とマルチ クラスタ サービス コントローラ。ロードバランサは、最初のアプリケーション クラスタがフリートに追加されたときにのみインストールされます。
フリート全体で Istio エンドポイントとオブジェクトを監視し、Istio サイドカーとゲートウェイ オブジェクトを最新の状態に維持する、マネージド Anthos Service Mesh。
次の図はこの状態を示しています。
アプリケーション クラスタをフリートに接続する
ArgoCD コントロール クラスタのセットアップができたら、新しいクラスタを作成してフリートにプロモートできます。これらのクラスタがアプリケーションを実行します。前の手順で、マルチクラスタ Ingress と Anthos Service Mesh を使用して、マルチクラスタ ネットワークを構成しました。新しいクラスタを、`env=prod` ラベルを使用して Secret として ArgoCD クラスタに追加することで、新しいクラスタは Anthos Service Mesh ゲートウェイなどの必要なベースライン ツールを確実に自動で取得するようになります。
新しいクラスタを ArgoCD に追加するために、Secret をコントロール クラスタの ArgoCD Namespace に追加します。これは次の方法で行うことができます。
`argocli add cluster` コマンド。新しいアプリケーション クラスタに対する `clusteradmin` アクセス許可をコントロール クラスタに付与する署名なしトークンを自動的に Secret に挿入します。
Connect ゲートウェイとフリートの Workload Identity。ApplicationSets に何をすべきかを伝えるラベルなどのカスタムラベルを持つ Secret を構築し、Google OAuth2 トークンを使用して GKE コントロール プレーンに対して認証された API 呼び出しを行うように ArgoCD を構成します。
新しいクラスタを ArgoCD に追加する場合、そのクラスタを特定のロールアウト ウェーブの一部としてマークできます。デモの後半で段階的ロールアウトを開始する際に、これを活用します。
次の Secret マニフェストのサンプルは、Connect ゲートウェイの認証構成と、`env: prod` および `wave` などのラベルを示しています。
デモでは、Google が提供するスクリプトを使用して、アプリケーション クラスタを ArgoCD 構成に追加できます。手順については、Promoting Application Clusters to the Fleet を参照してください。
次のサンプル画像に示されているように、ArgoCD ウェブ インターフェースを使用して、クラスタ内での自動化されたツール セットアップの進捗状況を確認できます。
新しいチーム アプリケーションと新しいクラスタを追加する
この時点で、フリート内のアプリケーション クラスタは、アプリケーションを提供する準備ができています。クラスタにアプリケーションをデプロイするために、アプリケーション構成を作成して、それらを ArgoCD 構成リポジトリに push します。ArgoCD は push を検出し、自動的にアプリケーションのデプロイと構成を行い、Anthos Service Mesh ゲートウェイを介してトラフィックの提供を開始します。
このデモでは、Google が提供するスクリプトを実行して、新しい ArgoCD Team にあるテンプレート `team-2` に基づいて新しいアプリケーションを作成します。手順については、Creating a new app from the app template を参照してください。
新しいアプリケーションを作成すると、段階的ロールアウトの各ウェーブに対して、そのウェーブの Git ブランチと同期されるアプリケーション セットが構成されます。
そのアプリケーション クラスタは wave one としてラベル付けされており、これまでにデプロイされている唯一のアプリケーション クラスタであるため、次のように、アプリケーションの UI には Argo アプリケーションが 1 つだけ表示されているはずです。
エンドポイントに対して `curl` を実行すると、アプリケーションは、実行されている Google Cloud ゾーンの名前を含むいくつかのメタデータを返します。
可用性を高めるために、別の Google Cloud ゾーンに新しいアプリケーション クラスタを追加できます。そのためには、同じ VPC 内でクラスタを作成し、既存の ApplicationSets に一致するラベルを持つ新しい ArgoCD Secret を追加します。
このデモでは、Google が提供するスクリプトを使用して次のことを行うことができます。
別のゾーンで新しいクラスタを追加する
新しいクラスタに、wave two というラベルを付ける（既存のアプリケーション クラスタのラベルは wave one）
ArgoCD がベースライン ツールをインストールするように、アプリケーション固有のラベルを追加する
そのクラスタにサンプル アプリケーションの他のインスタンスをデプロイする
アプリケーション エンドポイントに対して `curl` を実行すると、curl の送信元からの潜在経路が最小の GKE クラスタがレスポンスを返します。たとえば、`us-west1` の Compute Engine インスタンスから curl を実行すると、`gke-std-west02` クラスタにルーティングされます。
異なる地理的位置にあるマシンからエンドポイントにアクセスしてみることにより、レイテンシベースのルーティングを実験してみることができます。
デモのこの時点では、以下がある状態です。
wave one とラベル付けされた 1 つのアプリケーション クラスタ
wave two とラベル付けされた 1 つのアプリケーション クラスタ
両方のアプリケーション クラスタにデプロイされたアプリケーションを持つ、単一のチーム
ArgoCD を使用するコントロール クラスタ
新しい変更を自動で push する、背後の構成リポジトリ
フリート全体でアプリケーションを段階的にロールアウトする
ArgoCD のロールアウトは Kubernetes のデプロイと似ていますが、ロールアウトを制御するためのいくつかの追加のフィールドがあります。新しいバージョンを `wave-1` Git ブランチから `wave-2` Git ブランチにマージし、その後 `main` にマージすることで、ロールアウトを使用してアプリの新しいバージョンをフリート全体で段階的にデプロイし、ロールアウトのウェーブごとの進捗状況を手動で承認できます。
このデモでは、Google が提供するスクリプトを使用して次のことを行うことができます。
新しいアプリケーションを、両方のアプリケーション クラスタに追加する。
アプリケーションの新しいイメージ バージョンを、wave one クラスタにリリースする。
新しいアプリケーション イメージを使用する Pod から少しずつトラフィックを提供することで、ロールアウトしたバージョンにエラーがないかをテストする。
ロールアウトしたバージョンを wave two クラスタにプロモートする。
ロールアウトしたバージョンをテストする。
`main` で、ロールアウトしたバージョンを新しい stable バージョンとしてプロモートする。
手順については、Rolling out a new version of an app を参照してください。
次のサンプルは、ArgoCD ロールアウトに特有のフィールドを示しています。`strategy` フィールドは、使用するロールアウト方法を定義します。この例では、方法はカナリアで、ロールアウトには 2 つの手順が含まれます。アプリケーション クラスタのロールアウト コントローラは、ロールアウト オブジェクトに対するイメージの変更を確認して、新しいイメージを追加する際に、更新されたイメージタグを持つ新しいレプリカセットを作成します。その後ロールアウト コントローラは、クラスタへのトラフィックの 20% が新しいイメージを使用する Pod にルーティングされるように、Istio 仮想サービスの重み付けを調整します。
各手順は 4 分間実行され、次の手順に移る前に分析テンプレートを呼び出します。次の分析テンプレートのサンプルは Prometheus プロバイダを使用してクエリを実行し、ロールアウトのカナリア バージョンの成功率を確認します。成功率が 95% 以上の場合、ロールアウトは次の手順に移ります。成功率が 95% 未満の場合、ロールアウト コントローラは、stable バージョンのイメージを実行している Pod に対して Istio 仮想サービスの重み付けを 100% に設定することで、変更をロールバックします。
すべての分析手順が完了したら、ロールアウト コントローラは新しいアプリケーションのデプロイに stable というラベルを付け、その stable バージョンに Istio 仮想サービス 100% を設定し、以前のイメージ バージョン デプロイを削除します。
まとめ
この投稿では、ArgoCD と Argo Rollouts を使用して GKE クラスタのフリートの状態を自動で管理する方法を学びました。この自動化によって GKE クラスタの独自性が抽象化され、時間とともに変化するニーズに合わせて、クラスタのプロモートと削除を行えるようになります。
このデモを構築するために使用されているサービスを詳しく知りたい場合は、次のドキュメントをご覧ください。
Argo ApplicationSet コントローラ: 改善されたマルチクラスタおよびマルチテナント サポート。
Argo Rollouts: Blue / Green やテストなどの高度なロールアウト機能を提供する、Kubernetes コントローラ。
マルチクラスタ Ingress: 複数の GKE クラスタを単一の Google Cloud ロード バランサにマッピングし、1 つのクラスタを Ingress コントローラのコントロール ポイントとして使用します。
マネージド Anthos Service Mesh: 高可用性のために、アプリケーションをフリート内の複数のクラスタ全体に分散させる機能を持つ、一元化された Google マネージド コントロール プレーン。
フリートの Workload Identity: フリートのクラスタの任意の場所にあるアプリケーションが、Kubernetes サービス アカウントを IAM サービス アカウントとして使用して Google Cloud API に認証できるようにします。サービス アカウント キーや他の長期間の認証情報の管理は必要ありません。
- GKE プロダクト マネージャー Nicholas Eberts
- GKE テクニカル ライター Shannon Kularathna
