Google Cloud コンソールからクラスタを管理する

このドキュメントでは、Google Distributed Cloud を Google Cloud コンソールで管理する方法について説明します。ここでは、基本的な管理作業（クラスタにログインしてワークロードを表示するなど）だけでなく、クラスタをアップグレード、更新、削除できるようにクラスタのライフサイクル管理を有効にする方法も説明します。

フリート メンバーとコンソール

Google Distributed Cloud はすべてフリートのメンバーである必要があります。フリートは、複数のクラスタとそのワークロードを表示して管理するための統合された方法です。クラスタの各フリートは、フリート ホスト プロジェクトに関連付けられています。

Google Distributed Cloud では、クラスタ構成ファイルの gkeConnect セクションでフリートホスト プロジェクトを指定すると、管理クラスタが作成時にフリートに登録されます。Google Distributed Cloud は、この情報を使用して、指定されたフリート プロジェクトにクラスタを登録します。登録に失敗した場合は、gkectl update credentials register を実行して登録を再試行できます。

登録を再試行する場合、connect-register サービス アカウント キーを更新する必要はありません。元の connect-register サービス アカウントを引き続き使用できます。このコマンドの詳細については、サービス アカウント キーのローテーションをご覧ください。

Google Distributed Cloud では、ユーザー クラスタは作成時にフリートに登録されます。

• gkectl を使用してユーザー クラスタを作成する場合は、クラスタ構成ファイルの gkeConnect セクションでフリートホスト プロジェクトを指定します。Google Distributed Cloud は、この情報を使用して、指定されたフリート プロジェクトにクラスタを登録します。

• 標準ツール（コンソール、Google Cloud CLI、Terraform）でユーザー クラスタを作成すると、クラスタは自動的に指定したプロジェクトのフリート メンバーになります。

Google Distributed Cloud など、Google Cloud の外部のフリート メンバーは、フリート ホスト プロジェクトのコンソールに、Google Cloud 上の GKE などの他のフリート クラスタと一緒に表示されます。コンソールから Google Distributed Cloud を管理できる範囲は、以下の要因によって異なります。

• 認証を設定している場合は、クラスタにログインしてワークロードや他の詳細を表示できます。

• クラスタのクラスタ ライフサイクル管理を有効にしている場合は、コンソールを使用してユーザー クラスタをアップグレード、更新、削除することもできます。この機能が有効になっていない場合は、管理ワークステーションで gkectl を使用してクラスタのライフサイクル管理のみを行えます。

登録済みクラスタを表示する

すべてのフリート クラスタが、コンソールの Google Kubernetes Engine クラスタの概要ページに表示されます。これらの両方によって、フリート全体の概要を確認できます。また、Google Distributed Cloud では、GKE On-Prem API によって管理されているクラスタを確認できます。

フリート クラスタを表示するには:

1. コンソールで、Google Kubernetes Engine クラスタの概要ページに移動します。

   GKE クラスタに移動

2. Google Cloud プロジェクトを選択します。

   • [タイプ] 列に「vm Google Distributed Cloud」と表示されている場合、クラスタは GKE On-Prem API によって管理されています。

   • [タイプ] 列に「外部」と表示されている場合は、クラスタが GKE On-Prem API で管理されていません。

   

クラスタの詳細を表示するには、クラスタにログインして認証する必要があります。そのためには、次のことを行う必要があります。

• 認証方法を設定する
• ユーザーに特定の Identity and Access Management ロールを付与する

認証を設定する

前述のように、すべてのフリート クラスタはコンソールの GKE クラスタと GKE Enterprise クラスタのリストに表示されます。ただし、ノードやワークロードなどの詳細を表示する場合や、クラスタのライフサイクル管理タスクを実行するためにこの機能が有効になっている場合は、クラスタにログインして認証する必要があります。これを行うには、登録したクラスタに次のいずれかの認証方法を設定する必要があります。

• Google ID: このオプションを選択すると、Google Cloud identity（Google Cloud アカウントに関連付けられているメールアドレス）を使用してログインできます。ユーザーが Google ID で Google Cloud にすでにアクセスできる場合は、このオプションを使用します。コンソールでクラスタを作成した場合は、Google ID を使用してクラスタにログインできますが、他のユーザー用に認証を構成する必要があります。

  Google ID でのログインは、コンソールでの認証が最も簡単な方法です。特に、最小限のインストールで Google Distributed Cloud を試す場合は、この設定の詳細を確認してください。詳しくは、後述の Google ID 認証を設定するをご覧ください。

• OpenID Connect（OIDC）: このオプションを選択すると、ユーザーは、Okta や Microsoft AD FS などのサードパーティの OIDC ID プロバイダからの ID を使用して、コンソールからクラスタにログインできます。このオプションは、プロバイダの既存のユーザー名、パスワード、セキュリティ グループ メンバーがある場合に使用できます。クラスタにサードパーティの OIDC 認証を設定する方法については、次のガイドをご覧ください。

  • OIDC による GKE Identity Service 用のクラスタを構成する: このガイドでは、クラスタ別にクラスタに OIDC 認証を設定する方法について説明します。

  • フリート用に GKE Identity Service を設定する: このオプションを選択すると、フリートレベルで OIDC を設定できます。

• 署名なしトークン: 上記の Google 提供のソリューションが組織に適していない場合は、Kubernetes サービス アカウントとログインする署名なしトークンを使用して認証を設定できます。詳細については、署名なしトークンを使用して設定するをご覧ください。

必要なロールを付与する

コンソールへのアクセスは、Identity and Access Management（IAM）によって制御されます。これらの IAM ロールは、どの認証方法を使用する場合でも必要です。コンソールでクラスタのライフサイクルを管理するには、一部の IAM ロールを付与する必要があります。

• ユーザーがコンソールにアクセスできるようにするには、少なくとも次のロールを付与する必要があります。

  • roles/container.viewer。このロールを使用すると、ユーザーはコンソールで GKE クラスタのページやその他のコンテナ リソースを表示できます。このロールに含まれる権限の詳細と、読み取り / 書き込み権限を持つロールの付与方法については、IAM のドキュメントで Kubernetes Engine ロールの説明をご覧ください。

  • roles/gkehub.viewer: このロールでは、ユーザーがコンソールで Google Cloud の外部のクラスタを表示できます。このロールに含まれる権限の詳細と、読み取り / 書き込み権限を持つロールの付与方法については、IAM ドキュメントで GKE Hub ロールの説明をご覧ください。

• ユーザーがコンソールでクラスタのライフサイクルを管理できるようにするには、roles/gkeonprem.admin の IAM ロールを付与します。roles/gkeonprem.admin ロールを使用すると、GKE On-Prem API に対する管理者権限がユーザーに付与されます。この API により、コンソールでクラスタのライフサイクルを管理できます。このロールに含まれる権限の詳細については、IAM のドキュメントの GKE On-Prem ロールをご覧ください。

次のコマンドでは、コンソールでクラスタのライフサイクルを管理するために必要な最小限のロールを付与する方法を示します。

gcloud projects add-iam-policy-binding FLEET_HOST_PROJECT_ID \
    --member=MEMBER \
    --role=roles/container.viewer

gcloud projects add-iam-policy-binding FLEET_HOST_PROJECT_ID \
    --member=MEMBER \
    --role=roles/gkehub.viewer

gcloud projects add-iam-policy-binding FLEET_HOST_PROJECT_ID \
    --member=MEMBER \
    --role=roles/gkeonprem.admin

ここで

• FLEET_HOST_PROJECT_ID は、フリート ホスト プロジェクトです。gkectl を使用して作成されたクラスタの場合、これは、ユーザー クラスタの構成ファイルの gkeConnect セクションで構成したプロジェクトです。コンソールで作成されたクラスタの場合、これはクラスタの作成時に選択したプロジェクトです。

• MEMBER は、user:emailID 形式のユーザーのメールアドレスです（例: user:[e-mail]）。

コンソールでクラスタのライフサイクル管理を有効にする

標準ツール（コンソール、gcloud CLI、Terraform）で作成されたユーザー クラスタは、GKE On-Prem API に自動的に登録されます。これにより、コンソールでクラスタのライフサイクル管理タスクを実行できます。gkectl を使用して作成したユーザー クラスタでこの機能を有効にする場合は、GKE On-Prem API で管理されるようにユーザー クラスタを構成するの手順に沿って操作します。クラスタ ライフサイクル管理が有効になっている場合は、コンソールから次のタスクを実行できます。

• ユーザー クラスタをアップグレードする
• ユーザー クラスタのサイズを変更する
• ノードプールを作成して管理する
• ユーザー クラスタを削除する

注: Google Cloud からクラスタのライフサイクルを管理しない場合は、管理ワークステーションと gkectl を使用して同じタスクをすべて実行できます。

Google ID 認証を設定する

ユーザーが Google ID を使用してクラスタにログインできるようにするには、以下の内容を構成する必要があります。

• コンソールの GKE クラスタのリストにクラスタを表示して操作できるようにするには、ユーザーに特定の Identity and Access Management（IAM）ロールが必要です。

• Connect Gateway が Connect Agent を使用してクラスタの Kubernetes API サーバーにアクセスするために必要な Kubernetes のロールベース アクセス制御（RBAC）ポリシーにユーザーを追加する必要があります。

RBAC 認可を構成する

各クラスタの Kubernetes API サーバーは、コンソールからのリクエストを認可できる必要があります。認可を構成するには、クラスタごとに Kubernetes のロールベース アクセス制御（RBAC）ポリシーを構成する必要があります。

標準ツールでユーザー クラスタを作成した場合、クラスタに対する完全な管理者権限を付与する適切な RBAC ポリシーがすでに付与されている可能性があります。GKE On-Prem API は、次の場合、管理者として Google アカウントを自動的に追加します。

• コンソールでユーザー クラスタを作成した。

• gcloud CLI を使用してユーザー クラスタを作成し、Google アカウントが cluster create コマンドの --admin-users フラグで指定されている。

• Terraform を使用してユーザー クラスタを作成し、Google アカウントが authorization.admin_users.username フィールドで指定されている。

gkectl を使用して作成されたユーザー クラスタには、コンソールを使用してクラスタを管理するための RBAC ポリシーが付与されません。クラスタの作成後に自分自身を追加する必要があります。クラスタの作成に使用したツールにかかわらず、クラスタの作成後に他のユーザーを管理者として追加できます。

次のいずれかの方法で、クラスタに管理者権限を付与できます。2 つの異なる gcloud コマンドがあります。

• gcloud ... generate-gateway-rbac コマンドは、クラスタの kubeconfig とコンテキスト（通常は管理ワークステーションにのみ存在）にアクセスする必要があるため、管理ワークステーション上で実行する必要があります。generate-gateway-rbac コマンドを使用すると RBAC ポリシーをカスタマイズできますが、ユーザーのメールアドレスはコンソールの [クラスタの詳細] セクションに管理者として表示されません。

• gcloud ... update コマンドは、管理ワークステーションまたは GKE On-Prem API にアクセスできる任意のコンピュータで実行できます。

generate-gateway-rbac

1. 管理ワークステーションに接続します。

2. 次のコマンドを実行してコンポーネントを更新します。

   gcloud components update
   

3. RBAC ポリシーを生成して、ユーザーとサービス アカウントのクラスタに適用します。

   gcloud container fleet memberships generate-gateway-rbac  \
       --membership=MEMBERSHIP_NAME \
       --role=ROLE \
       --users=USERS \
       --project=FLEET_HOST_PROJECT_ID \
       --kubeconfig=KUBECONFIG_PATH \
       --context=KUBECONFIG_CONTEXT \
       --apply
   

   次のように置き換えます。

   • MEMBERSHIP_NAME: そのフリートでクラスタを一意に表すために使用される名前。Google Distributed Cloud では、メンバーシップ名とクラスタ名は同じです。
   • ROLE: クラスタのユーザーに付与する Kubernetes のロール。ユーザーに、クラスタ内のすべての名前空間ですべてのリソースへの完全アクセス権を付与するには、clusterrole/cluster-admin を指定します。読み取り専用アクセスを許可するには clusterrole/view を指定します。カスタムロールを作成することもできます（例: role/mynamespace/namespace-reader）。カスタムロールは、コマンドを実行する前に存在している必要があります。
   • USERS: カンマ区切りのリストとして、権限を付与するユーザー（ユーザー アカウントまたはサービス アカウント）のメールアドレス。例: --users=[e-mail],[e-mail]。
   • FLEET_HOST_PROJECT_ID: フリート ホスト プロジェクトのプロジェクト ID。
   • KUBECONFIG_PATH: クラスタのエントリを含む kubeconfig のローカルパス。

   • KUBECONFIG_CONTEXT: kubeconfig ファイルに含まれる、クラスタの内容。現在の内容は、kubectl config current-context を実行してコマンドラインから取得できます。現在の内容を使用するかどうかに関係なく、次のような単純なコマンドを実行して、クラスタへのアクセスに適していることを確認します。

     kubectl get namespaces \
       --kubeconfig=KUBECONFIG_PATH \
       --context=KUBECONFIG_CONTEXT
     

   gcloud container fleet memberships generate-gateway-rbac を実行すると、出力の最後に次のような文字列が表示されます（読みやすさのために短くしています）。

   Validating input arguments.
   Specified Cluster Role is: clusterrole/cluster-admin
   Generated RBAC policy is:
   --------------------------------------------
   ...
   Applying the generate RBAC policy to cluster with kubeconfig: /usr/local/google/home/foo/.kube/config, context: kind-kind
   Writing RBAC policy for user: [e-mail] to cluster.
   Successfully applied the RBAC policy to cluster.
   

   これは、Connect Gateway を介してクラスタにアクセスするためのコンテキストです。

   generate-gateway-rbac コマンドの詳細については、gcloud CLI リファレンス ガイドをご覧ください。

update

1. 次のコマンドを実行してコンポーネントを更新します。

   gcloud components update
   

2. clusterrole/cluster-admin ロールが必要なユーザーごとに、--admin-users フラグを指定して次のコマンドを実行します。1 つのフラグで複数のユーザーを指定することはできません。このコマンドは、コマンドで指定されたユーザーで付与リストを上書きするため、Google アカウントをコマンドに含める必要があります。

   gcloud container vmware clusters update USER_CLUSTER_NAME \
     --admin-users YOUR_GOOGLE_ACCOUNT \
     --admin-users ADMIN_GOOGLE_ACCOUNT_1 \
   

このコマンドは、Kubernetes の clusterrole/cluster-admin ロールを付与するだけでなく、Connect Gateway を介してクラスタにアクセスするために必要な RBAC ポリシーを付与します。

コンソール

RBAC ポリシーをユーザーに適用するには、コンソールで次の操作を行います。

1. コンソールで、Google Kubernetes Engine クラスタの概要ページに移動します。

   GKE クラスタに移動

2. ユーザー クラスタが存在する Google Cloud プロジェクトを選択します。

3. クラスタのリストでクラスタの名前をクリックして、詳細を表示します。

4. [認可] セクションで、[管理者ユーザー] の編集ボタンをクリックします。

5. [承認の編集] パネルに、クラスタ管理者として追加するユーザーのメールアドレスを入力します。管理者ユーザーを追加するには、[管理者ユーザーを追加] をクリックします。

6. ユーザーの追加が完了したら、[変更を保存] をクリックします。

注: 管理者ユーザーを追加すると、GKE On-Prem API が Kubernetes RBAC ポリシーをクラスタに適用し、クラスタの作成時に付与された権限と同じ管理者権限をユーザーに付与します。これらのポリシーによって、ユーザーに Kubernetes の clusterrole/cluster-admin ロールが付与されます。これにより、クラスタ内のすべての Namespace ですべてのリソースに対して完全アクセス権が付与されます。

詳細

• フリート管理の概要
• Google Cloud コンソールからクラスタを操作する
• Connect の概要
• Connect Agent の概要