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

このドキュメントでは、Google Cloud コンソールで Google Distributed 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 GKE on VMware] と表示されている場合、クラスタは GKE On-Prem API によって管理されています。
- [タイプ] 列に [外部] と表示されている場合は、クラスタが GKE On-Prem API で管理されていません。

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

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

認証を設定する

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

Google ID: このオプションを選択すると、ユーザーは Google Cloud ID（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 を使用してクラスタにログインできるようにするには、以下の内容を構成する必要があります。

Google Cloud コンソールの GKE クラスタリストと GKE Enterprise クラスタリストでクラスタを表示して操作できるようにするには、ユーザーに特定の Identity and Access Management（IAM）ロールが必要です。
コネクトゲートウェイがコネクトエージェント経由でクラスタの Kubernetes API サーバーにアクセスするために必要な Kubernetes のロールベースアクセス制御（RBAC）ポリシーにユーザーを追加する必要があります。

RBAC 認可を構成する

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

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

コンソールでユーザークラスタを作成した。
gcloud CLI を使用してユーザークラスタを作成し、Google アカウントが cluster create コマンドの --admin-users フラグで指定されている。
Terraform を使用してユーザークラスタを作成し、authorization.admin_users.username フィールドに Google アカウントを指定している。

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 ゲートウェイを介してクラスタにアクセスするためのコンテキストです。

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 ロールを付与するだけでなく、コネクトゲートウェイを介してクラスタにアクセスするために必要な RBAC ポリシーを付与します。

コンソール

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

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

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