Anthos clusters on VMware は、VMware 用 Google Distributed Cloud（ソフトウェアのみ）になりました。詳細については、プロダクトの概要をご覧ください。

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

このドキュメントでは、VMware 用 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 によって管理されているクラスタを確認できます。

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

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

GKE クラスタに移動
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:alice@example.com）。

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

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

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`

管理ワークステーションに接続します。
次のコマンドを実行してコンポーネントを更新します。
```
gcloud components update
```
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=foo@example.com,test-acct@test-project.iam.gserviceaccount.com。
- 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: foo@example.com to cluster.
Successfully applied the RBAC policy to cluster.
```
これは、Connect Gateway を介してクラスタにアクセスするためのコンテキストです。

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

`update`

次のコマンドを実行してコンポーネントを更新します。
```
gcloud components update
```
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 ポリシーをユーザーに適用するには、コンソールで次の操作を行います。

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

GKE クラスタに移動
ユーザークラスタが存在する Google Cloud プロジェクトを選択します。
クラスタのリストでクラスタの名前をクリックして、詳細を表示します。
[認可] セクションで、[管理者ユーザー] の編集ボタンをクリックします。
[承認の編集] パネルに、クラスタ管理者として追加するユーザーのメールアドレスを入力します。管理者ユーザーを追加するには、[管理者ユーザーを追加] をクリックします。
ユーザーの追加が完了したら、[変更を保存] をクリックします。