Connect Gateway と ArgoCD: 分散 Kubernetes へのデプロイ
Google Cloud Japan Team
※この投稿は米国時間 2022 年 9 月 7 日に、Google Cloud blog に投稿されたものの抄訳です。
ArgoCD Deployment をConnect Gateway およびWorkload Identity と統合することによって、多くのプラットフォームに Kubernetes をシームレスにデプロイできます。ArgoCD は、GKE クラスタ、Anthos クラスタなど、さまざまなクラスタ プラットフォームを一元管理するために簡単に構成できます。これにより、フリート全体の整合性の促進、新しいクラスタのオンボーディング時間の短縮、管理接続のための分散型 RBAC モデルの簡素化を実現します。以下の手順に進み、ユースケースに合わせて ArgoCD を構成してください。
背景
ArgoCD を継続的デリバリー ツールとして選択する Cloud のお客様は、ArgoCD が 中央 K8s クラスタでホストされ、さまざまな分散型アプリケーション クラスタの管理を担う一元化されたアーキテクチャを選択できます。これらのアプリケーション クラスタは、Connect Gateway を介してアクセスされる多くのクラウド プラットフォームで利用でき、ArgoCD の認証、認可、および K8s API サーバーとのやり取りを簡素化します。このモデルの概要については、以下の図をご覧ください。
ArgoCD にアプリケーション クラスタを追加する際のデフォルトの認証動作は、最初のコントロール プレーンの接続にオペレーターの kubeconfig を使用して、アプリケーション クラスタ（「argo-manager」）にローカル KSA を作成し、K8S Secret で KSA の署名なしトークンをエスクローすることです。ここでパイプラインの管理者は、2 つの特有の課題に直面することになります。
プリンシパル管理: GCP では、複数のクラスタ間でスコープされる連携 Kubernetes Service Account（KSA）は提供されません。ArgoCD によって管理される各クラスタに対して 1 つの KSA を作成する必要があります。各 KSA はコントロール プレーンに固有で、認証情報のローテーション、RBAC の冗長化など、個別のライフサイクル管理プロセスを必要とします。
承認: 権限を付与された KSA Secret は ArgoCD 中央クラスタに保存されます。これにより、システムのセキュリティを保護するために、オペレーターのオーバーヘッドとリスクが発生します。
この 2 つの課題は、Connect Gateway とWorkload Identity を使用することで、直接的に対処 / 軽減できます。以下のアプローチを行います。
クラスタ管理者の KSA は一切作成しません。代わりに GSA を使い、（Workload Identity を介して）「argocd」Namespace の ArgoCD サーバーとアプリケーション コントローラのワークロードに GSA をマッピングします。この GSA は、IAM ポリシーまたは K8s RBAC ポリシーで、各アプリケーション クラスタのクラスタ管理者として承認されます。
K8s Secret は、ArgoCD によって Google Oauth トークンを取得し、Google Cloud API に対して認証を行う、より安全なメカニズムに変更される予定です。これにより、KSA Secret の管理が不要になり、取得した Oauth トークンのローテーションも自動化されます。
ArgoCD 中央クラスタとマネージド アプリケーション クラスタの依存関係は互いに排他的なものです。つまり、これらのクラスタは同じ GCP プロジェクト内にある必要はなく、VPC ピアリング、SSH トンネル、HTTP プロキシ、踏み台インスタンスなどの緊密なネットワーク関係も必要ありません。
対象となるアプリケーション クラスタは、異なるクラウド プラットフォームに配置できます。また、これらのクラスタにも、同じ認証 / 認可と接続モデルが拡張されます。
インストール手順
まず、用語について簡単に説明します。クラスタの一つを「中央クラスタ」と呼び、もう一つを「アプリケーション クラスタ」と呼ぶことにします。前者は中央の ArgoCD Deployment をホストし、後者ではアプリケーションや構成をデプロイします。
要件:
VPC ネットワーク、VPC ネイティブ クラスタをサポートするのに十分なセカンダリ範囲が設定されたサブネット、GKE クラスタや Anthos クラスタをホストするために有効化された API を含む、ブートストラップされた GCP プロジェクトが 1 つ以上必要です。
Workload Identity を有効にし、適切なデフォルト設定でデプロイされた 2 つのクラスタが必要です。私は Terraform ベースのデプロイメントを選択し、safer-cluster モジュールを使用することにしました。
Anthos クラスタを使用する場合、クラスタは完全にデプロイされ、フリートに登録されていることが前提です（そのため Connect Gateway 経由で到達可能）
gcloudSDK がインストール済みで、gcloud auth loginで認証されている必要があります。オプション: 置換を行わずに以下の
gcloudコマンドを実行するために PROJECT_ID 環境変数を設定します。
ID の構成:
このセクションでは、GSA を設定します。これは、Google Cloud とのやりとりの際に ArgoCD で使用する ID です。
Google サービス アカウントを作成し、必要な権限を設定します。
2. 先ほど作成した GSA の権限を ArgoCD の Namespace / KSA が借用することを許可する IAM ポリシーを作成します。
アプリケーション クラスタの構成（GKE の場合）:
このセクションでは、GKE クラスタをフリートに登録し、Connect Gateway を介して ArgoCD で管理できるようにします。
1. 目的の GCP プロジェクトに必要な API を有効にするために必要な API を有効化します。
2. アプリケーション クラスタにアクセスし管理するための ArgoCD 権限を付与します。
3. 登録に使用したアプリケーション クラスタの URI を記載します。
4. アプリケーション クラスタをフリート プロジェクトに登録します。ここでは例として、gcloud SDK のコマンドを使用しています。Terraform のような他のツールをご利用の場合は、このドキュメントを参照してください。
5. アプリケーション クラスタのフリート メンバーシップを表示します。
アプリケーション クラスタの構成（GKE 以外の場合）:
このセクションでは、GKE 以外のクラスタ（Anthos-on-VMware、Anthos-on-BareMetal など）を ArgoCD に登録する手順について説明します。
GKE のシナリオの手順と同様に、まずアプリケーション クラスタをフリート プロジェクトに登録します。最新の Anthos バージョンでは、アプリケーション クラスタを作成した時点ですでに登録されています。クラスタが登録されていない場合は、このガイドを参照して登録してください。
1. アプリケーション クラスタのフリート メンバーシップを表示します。
2. アプリケーション クラスタにアクセスし管理するための ArgoCD 権限を付与します。ArgoCD を使用してこのラスタに接続、管理するには、手順 1 の ArgoCD GSA を「アプリケーション クラスタ」RBAC でプロビジョニングする必要があります。<CONTEXT> と <KUBECONFIG> は適切な値で置き換えます。
中央クラスタでの ArgoCD のデプロイ:
バージョン 2.4.0 以降である必要があります。中央クラスタにArgoCD をデプロイするには、Kustomize の使用をおすすめしています。これにより、Workload Identity と Connect Gateway の有効化に必要な構成のパッチ適用を、最小限に簡略化できます。
1. ArgoCD をデプロイするための Namespace を作成します。
2. GKE クラスタ: 中央クラスタが GKE でホストされている場合、手順 1 で作成した GSA で argocd-server と argocd-application-controller の KSA をアノテーションしてください。これを行うための Kustomize オーバーレイ マニフェストの例を示します。
3. Anthos クラスタ: 中央クラスタが Anthos クラスタでホストされている場合、こちらを参照して Workload Identity を構成する必要があります。前提条件として、中央クラスタがフリート プロジェクトに登録されている必要があります。この条件に基づいて、ArgoCD のワークロードが目的の GSA の権限を借用するように構成できます。これを行うための Kustomize オーバーレイ マニフェストの例は、このリポジトリで確認できます。
4. オプション: ArgoCD サーバーをLoadBalancer タイプの Service または Ingress で外部（または内部）に公開します。5. 任意のツールを使用して、手順 1 で作成した中央クラスタの argocd Namespace に、ArgoCD をデプロイします。Kustomize を使用した例を示します。overlay/demo はオーバーレイ マニフェストを含むパスです。
ArgoCD のテスト:
これで、ArgoCD Deployment が機能し、UI が外部や内部で任意に公開されるようになりました。以下の手順では、アプリケーション クラスタを ArgoCD の「外部クラスタ」として追加し、今回の統合が期待通りに機能することを確認します。
1. アプリケーション クラスタを表すクラスタタイプの Secret を作成し、中央クラスタのargocd Namespace に適用します。（例: kubectl apply -f cluster-secret.yaml -n argocd）注: この手順は、アプリケーション クラスタのライフサイクルを担う IaC パイプラインに最適です。アプリケーション クラスタの作成や変更が正常に行われた時点で、この Secret は動的に生成され、中央クラスタに適用されます。同様に、アプリケーション クラスタが削除された場合は、Secret を中央クラスタから削除する必要があります。
2. ArgoCD コンソールにログインし、アプリケーション クラスタが正常に追加されたことを確認します。ArgoCD 用の最初の管理者パスワードを入手するには、以下のコマンドを使用します。
3. ArgoCD からテスト アプリケーションを push し、アプリケーション クラスタが正常に同期されることを確認します。簡単なテスト用にデプロイできるサンプルアプリケーションについては、こちらのリポジトリをご確認ください。
まとめ
上記の手順では、Connect Gateway と Workload Identity を使用して、分散 Kubernetes プラットフォームへの継続的デプロイを可能にする方法をご紹介しました。この一元化されたアーキテクチャを活用することで、構成とアプリケーションのデリバリー パイプラインを簡素化してセキュリティを確保し、フリート全体の整合性を促進できます。
ArgoCD と Argo Rollouts を使用して GKE クラスタのフリートの状態を自動で管理する方法に焦点を当てた概念実証を行いたい場合は、主要なオペレーターのユーザー ストーリーを構築できるこの投稿をご確認ください。
クラスタをデプロイして特定のラベルを付与するだけではなく、新しいアプリケーション クラスタをフリートにゼロタッチで追加します。新しいクラスタは、そのクラスタラベルに結び付けられているアプリケーションとともに、ツールとセキュリティのための一連のベースライン構成を自動的にインストールします。
新しいアプリケーションをフリートに追加します。フリートは、アプリケーションを配信する開発チームのためにマルチテナントのベースライン構成を継承し、Kubernetes RBAC をチームの ID グループにバインドします。
新しいバージョンのアプリケーションをクラスタのグループ（またはウェーブ）全体に段階的にロールアウトします。各ウェーブ間では、手動で認証を行うゲートが必要になります。
- Kubernetes ソフトウェア エンジニア Xuebin Zhang
