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

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

このドキュメントでは、Google Distributed Cloud software on bare metal で作成された管理クラスタとユーザークラスタを Google Cloud コンソールで管理できるようにする方法について説明します。クラスタ管理機能には、クラスタへのログイン、ワークロードの表示、クラスタのアップグレード、更新、削除などがあります。

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

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

すべてのクラスタは、作成時にフリートに登録されます。

bmctl を使用してクラスタを作成する場合は、クラスタ構成ファイルの gkeConnect セクションでフリートホストプロジェクトを指定します。クラスタは、指定したプロジェクトのフリートメンバーになります。
標準の GKE On-Prem API クライアント（コンソール、Google Cloud CLI、または Terraform）を使用して管理クラスタまたはユーザークラスタを作成すると、クラスタは指定されたプロジェクトのフリートメンバーになります。

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

認証を設定している場合は、クラスタにログインしてワークロードや他の詳細を表示できます。
クラスタのクラスタライフサイクル管理を有効にしている場合は、コンソールで管理クラスタとユーザークラスタをアップグレードできます。また、コンソールでユーザークラスタの更新と削除も行うことができます。この機能が有効になっていない場合は、管理ワークステーションで bmctl を使用してクラスタのライフサイクル管理のみを行えます。

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

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

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

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

GKE クラスタに移動
Google Cloud プロジェクトを選択します。
- ベアメタルが [タイプ] 列に表示されている場合、クラスタは GKE On-Prem API によって管理されています。GKE On-Prem API で管理できるのは、管理クラスタとユーザークラスタのみです。
- [タイプ] 列に「外部」と表示されている場合は、クラスタが GKE On-Prem API で管理されていません。

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

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

認証を設定する

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

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

Google ID でのログインは、コンソールでの認証が最も簡単な方法です。この設定方法の詳細は、以下の 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 ロールを付与する必要があります。

ユーザーがコンソールにアクセスできるようにするには、少なくとも次のロールを付与する必要があります。
- 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 PROJECT_ID \
    --member=MEMBER \
    --role=roles/container.viewer

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

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

ここで

PROJECT_ID は、フリートホストプロジェクトです。bmctl を使用して作成されたクラスタの場合、これは、ユーザークラスタの構成ファイルの gkeConnect セクションで構成したプロジェクトです。コンソールで作成されたクラスタの場合、これはクラスタの作成時に選択したプロジェクトです。
MEMBER は、user:emailID 形式のユーザーのメールアドレスです（例: user:alice@example.com）。

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

標準ツール（コンソール、gcloud CLI、または Terraform）で作成された管理クラスタとユーザークラスタは、GKE On-Prem API に自動的に登録されます。これにより、コンソールでクラスタのライフサイクル管理タスクを実行できます。Google Distributed Cloud 1.16 以降では、bmctl を使用してユーザークラスタと管理クラスタを作成すると、デフォルトで GKE On-Prem API に登録されます。クラスタを GKE On-Prem API に登録する必要がある場合は、クラスタを 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）ポリシーを構成する必要があります。次の場合、Google アカウントがユーザークラスタへの完全アクセス権を持つ管理者として追加されます。

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

クラスタの作成後に、他のユーザーを管理者として追加できます。次のいずれかの方法で、クラスタに管理者権限を付与できます。2 つの異なる gcloud コマンドが用意されています。

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

Google Cloud コンソールで管理クラスタを作成した場合、クラスタに対する読み取り専用アクセス権が付与されます。clusterrole/cluster-admin ロールの付与が必要な場合は、そのロールを持つユーザーに gcloud ... generate-gateway-rbac コマンドでの追加を依頼する必要があります。

`generate-gateway-rbac`

RBAC ポリシーをユーザーに適用するには、管理ワークステーションで次の操作を行います。

次のコマンドを実行して、コンポーネントを更新します（必要な場合）。
```
gcloud components update
```
RBAC ポリシーを生成して、ユーザーとサービスアカウントのクラスタに適用します。
```
gcloud container fleet memberships generate-gateway-rbac  \
    --membership=MEMBERSHIP_NAME \
    --role=ROLE \
    --users=USERS \
    --project=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=222larabrown@gmail.com,test-acct@test-project.iam.gserviceaccount.com。
- 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 bare-metal clusters update USER_CLUSTER_NAME \
  --admin-users YOUR_GOOGLE_ACCOUNT \
  --admin-users ADMIN_GOOGLE_ACCOUNT_1 \
```

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

bmctl