Connect ゲートウェイを使用して登録済みクラスタに接続する

Google Cloud のフリートは、Kubernetes クラスタと他のリソースを一元管理できる論理グループで、Google Cloud にクラスタを登録して作成されます。フリートを活用して構築される Connect Gateway を使用すると、GKE Enterprise ユーザーは、フリート メンバー クラスタが Google Cloud、他のパブリック クラウド、またはオンプレミスのどこにある場合でも、シンプルで一貫性のある安全な方法で接続して、コマンドを実行できます。これにより、すべてのクラスタにわたって DevOps プロセスの自動化が容易になります。

このガイドは、基本的なフリートのコンセプトと、フリートへのクラスタの登録について理解していることを前提としています。そうでない場合は、フリート管理の概要フリートの作成の概要、および関連するガイドをご覧ください。また、kubectlclient-go(Gateway を自動化に使用する場合)、ロールベース アクセス制御(RBAC)、Kubernetes の主要リソースなど、Kubernetes のツールとコンセプトについても十分に理解している必要があります。

デフォルトでは、Connect Gateway は Google ID を使用してクラスタに対する認証を行います。これは、Workforce Identity 連携を使用するサードパーティの ID プロバイダと、GKE Identity Service を介したグループベースの認証をサポートしています。GKE Identity Service の詳細を確認したり、スタンドアロンのサードパーティ認証オプションとして使用する場合は、GKE Identity Service の概要をご覧ください。

Connect Gateway を使用する理由

クラスタが複数のクラウドやハイブリッド環境で実行されている場合、ワークロードの管理には多くの課題があります。クラスタが異なる Virtual Private Cloud(VPC)で実行され、異なる ID プロバイダを利用するため、接続、認証、承認が複雑になる場合があります。このような環境では、どのクラスタが存在するのか確認するのも難しい場合があります。

Connect Gateway を使用すると、次の処理を簡単に行うことができます。

  • Google Cloud、別のパブリック クラウド、オンプレミスに存在するクラスタを検出し、簡単なクエリを使用してフリートに登録する。
  • Google Cloud コンソールで登録済み GKE クラスタの表示に使用したものと同じインフラストラクチャを使用して、目的のクラスタに接続する。
  • Google Cloud サービスで使用しているものと同じ ID を使用して認証する。
  • フリートに登録されているすべてのクラスタに対して一貫して認可を行う。

Gateway は、Google Cloud ID を認証し、Connect サービスを介してクラスタの API サーバーへの接続を提供します。

kubectl など、kubeconfig を受け入れるコマンドライン ツールを使用し、Gateway を介してクラスタを直接操作できます。Gateway は、ビルド パイプラインや他の DevOps 自動化にも簡単に活用できます。これを行う方法の例については、Cloud Build との統合のチュートリアルをご覧ください。

Connect Service を使用すると、Google Cloud コンソールから Google Cloud ID を使用して、Google Cloud ID を持つ登録済みクラスタに接続することもできます。これを行うには、Google Cloud コンソールからクラスタを操作するの手順に沿って操作します。

仕組み

ここでは、標準的なユーザーまたはサービス(CI / CD パイプラインなど)が、適切な認証と認可を構成した後に、Connect Gateway を使用するために行うフローを示します。ユーザー向けの手順の詳細については、使用方法のガイドをご覧ください。

  1. ユーザーまたはサービスは、Google Cloud CLI を使用してフリート メンバーシップ リソースを一覧表示することでクラスタを検出します。

    gcloud container fleet memberships list
    
  2. ユーザーまたはサービスは、Google Cloud CLI を使用して、選択したクラスタにアクセスするために必要な Connect Gateway 固有の kubeconfig を取得します。

    gcloud container fleet memberships get-credentials membership-name
    

    GKE で gcloud CLI を使用することに慣れている場合、これは Google Cloud アカウントで gcloud container clusters get-credentials を実行する場合と同様です。これにより、プロジェクトのフリート内で登録され、接続されている任意のクラスタにアクセスできます(認可されている場合)。

  3. ユーザーまたはサービスは、kubectlclient-go の場合と同様に、ダウンロードした kubeconfig ファイルを使用してコマンドを実行します。

    1. ユーザーまたはサービスが Connect Gateway によって認証され、Gateway を使用するための権限があるかどうか確認されます。
    2. リクエストは、Connect Service と Connect Agent を介して、対応する Kubernetes API サーバーに転送されます。
    3. Kubernetes API サーバーがリクエストを承認します。そのためには、Connect Agent がユーザーまたはサービスの権限を借用でき、ユーザーまたはサービスに目的のリクエストを行うための権限が付与されている必要があります。

Google グループのサポート

前のセクションで説明した標準フローでは、ユーザーのリクエストが個々の ID に基づいて承認されます。ただし、多くの場合、Google グループのメンバーシップに基づいてユーザーを認証できると便利です。グループ メンバーシップに基づいて認証すると、アカウントごとに個別の認証を設定する必要がないため、ポリシーの管理が簡素化され、監査が容易になります。たとえば、クラスタへのアクセスをチームで共有することで、ユーザーがチームに入ったり、チームから抜けたときに、個々のユーザーを手動でクラスタに追加または削除する必要がなくなります。GKE Identity Service を使用して追加設定を行うことで、ユーザーの Google グループ メンバーシップ情報を取得するように Connect Gateway を構成できます。

この機能の仕組みと設定方法の詳細については、Google グループを使用して Connect Gateway を設定するをご覧ください。

この機能を接続クラスタや他の GKE Enterprise 環境で使用する場合は、Cloud カスタマーケアまたは Connect Gateway チームにお問い合わせください。

サードパーティの ID のサポート

Connect Gateway は、Google Workspace のユーザーとグループの操作に加えて、Azure Active Directory や Okta などのサードパーティ ID を使用した認証をサポートしています。Workforce Identity 連携では、外部 ID プロバイダを使用して、Workforce(従業員、パートナー、請負業者などのユーザー グループ)を Identity and Access Management を使用して認証および認可し、ユーザーが Connect Gateway などの Google Cloud サービスにアクセスできるようにします。GKE Identity Service を使用して追加設定を行うことで、ユーザーのサードパーティ グループ メンバーシップ情報を取得するように Connect Gateway を構成できます。

Anthos(GKE Enterprise)バージョン 1.13 以降では、Connect Gateway のサードパーティ ID 機能は Google Distributed Cloud のデプロイ(VMware 上ベアメタル上)でサポートされています。接続クラスタの場合、この機能は Anthos 1.16 以降で利用できます。

この機能の仕組みと設定方法の詳細については、サードパーティの ID を使用して Connect Gateway を設定するをご覧ください。

必要に応じて、ドキュメントの説明に従って、GKE Identity Service を使用してサードパーティの認証を完全に設定することもできます。

レイテンシ

リクエストの Gateway 経由の合計レイテンシは、Connect Gateway サービスから Connect Agent への RTT(ラウンド トリップ時間)と、クラスタ内でのリクエスト実行時間の 2 つの部分に分けられます。RTT に追加されるレイテンシは、p95 で 500 ミリ秒未満、p99 で 1 秒未満です。なお、ほとんどの kubectl コマンドは、ユーザーにレスポンスを返す前に、ラウンドトリップが必要な一連のリクエストを実行します。

次のステップ