このドキュメントでは、GKE on Bare Metal を Google Cloud コンソールで管理する方法について説明します。これには、基本的な管理（クラスタにログインしてワークロードを表示できることなど）と、クラスタをアップグレード、更新、削除できるようにクラスタのライフサイクル管理を有効にする方法が含まれます。
フリート メンバーとコンソール
GKE on Bare Metal はすべてフリートのメンバーである必要があります。フリートは、複数のクラスタとそのワークロードを表示して管理するために統合された方法です。クラスタの各フリートは、フリートホスト プロジェクトに関連付けられています。
GKE on Bare Metal では、ユーザー クラスタは作成時にフリートに登録されます。
bmctlを使用してクラスタを作成する場合は、クラスタ構成ファイルのgkeConnectセクションでフリートホスト プロジェクトを指定します。GKE on Bare Metal は、この情報を使用して、指定したフリート プロジェクトにクラスタを登録します。コンソールでユーザー クラスタを作成すると、自動的にクラスタはコンソールで選択したプロジェクトのフリート メンバーになります。
GKE on Bare Metal など、Google Cloud の外部のフリート メンバーは、フリートホスト プロジェクトのコンソールに、Google Cloud 上の GKE などの他のフリート クラスタと一緒に表示されます。GKE on Bare Metal をコンソールから管理できる範囲は、以下の内容によって異なります。
認証を設定している場合は、クラスタにログインしてワークロードや他の詳細を表示できます。
クラスタのクラスタ ライフサイクル管理を有効にしている場合は、コンソールを使用してユーザー クラスタをアップグレード、更新、削除することもできます。これを行うには、GKE On-Prem API と呼ばれるサービスによってクラスタを管理する必要があります。コンソールで作成されたユーザー クラスタでは、クラスタの作成時にクラスタのライフサイクル管理が有効になります。また、後で
bmctlを使用して作成されたユーザー クラスタに対して、この機能を有効にすることもできます。この機能が有効になっていない場合は、管理ワークステーションでbmctlを使用してクラスタのライフサイクルの管理のみを行えます。
登録済みクラスタを表示する
すべてのフリート クラスタが、コンソールの [GKE クラスタ] ページに表示されます。これらの両方によって、フリート全体の概要と、GKE on Bare Metal では GKE On-Prem API によって管理されているクラスタを確認できます。
フリート クラスタを表示するには:
コンソールで、Google Kubernetes Engine クラスタの概要ページに移動します。
Google Cloud プロジェクトを選択します。
ベアメタルが [タイプ] 列に表示されている場合、クラスタは GKE On-Prem API によって管理されています。
[タイプ] 列に [外部] と表示されている場合は、クラスタが GKE On-Prem API で管理されていません。
クラスタの詳細を表示するには、クラスタにログインして認証する必要があります。そのためには、次の手順を行います。
認証の設定
前述のように、すべてのフリート クラスタはコンソールの 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 サービス アカウントとログインする署名なしトークンを使用して認証を設定できます。詳細については、署名なしトークンを使用して設定するをご覧ください。
必要な役割の付与
コンソールへのアクセスは Google Cloud 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）。
コンソールでクラスタのライフサイクル管理を有効にする
コンソールで作成されたユーザー クラスタは、GKE On-Prem API によって自動的に管理され、コンソールでクラスタのライフサイクル管理タスクを実行できます。bmctl を使用して作成したユーザー クラスタでこの機能を有効にする場合は、GKE On-Prem API で管理されるようにユーザー クラスタを構成するに記載されている手順に沿って操作します。クラスタ ライフサイクル管理を有効にすると、コンソールからクラスタを更新できます。
- ユーザー クラスタの更新
- ユーザー クラスタのノードプールの追加または削除
- ユーザー クラスタの削除
Google ID 認証を設定する
ユーザーが Google ID を使用してクラスタにログインできるようにするには、以下の内容を構成する必要があります。
コンソールの [GKE クラスタ] ページでクラスタを表示して操作できるようにするには、ユーザーに特定の Identity and Access Management（IAM）ロールが必要です。
コネクト ゲートウェイがコネクト エージェントを使用してクラスタの Kubernetes API サーバーにアクセスするために必要な Kubernetes のロールベース アクセス制御（RBAC）ポリシーにユーザーを追加する必要があります。
RBAC 認可を構成する
各クラスタの Kubernetes API サーバーは、コンソールからのリクエストを認可できる必要があります。認可を構成するには、クラスタごとに Kubernetes のロールベースのアクセス制御（RBAC）ポリシーを構成する必要があります。コンソールでクラスタを作成した場合、GKE On-Prem API はユーザー アカウントを管理者として追加し、クラスタに対する完全な管理者権限を付与する適切な RBAC ポリシーを作成します。
gcloud CLI
RBAC ポリシーをユーザーに適用するには、管理ワークステーションで次の手順を行います。
次のコマンドを実行して、Google アカウントでログインし、コンポーネントを更新します。
gcloud auth login gcloud components updateRBAC ポリシーを生成して、ユーザーとサービス アカウントのクラスタに適用します。
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: 対象のフリートでクラスタを一意に表すために使用される名前。GKE on Bare Metal では、メンバーシップ名とクラスタ名は同じです。
- ROLE: クラスタのユーザーに付与する Kubernetes のロール。ユーザーに、クラスタ内のすべての名前空間ですべてのリソースへの完全アクセス権を付与するには、
clusterrole/cluster-adminを指定します。アクセスを制限するには、カスタムロールを作成します（例:role/mynamespace/namespace-reader）。カスタムロールは、コマンドを実行する前に存在している必要があります。 - USERS: カンマ区切りのリストととして、権限を付与するユーザー（ユーザー アカウントまたはサービス アカウント）のメールアドレス。例:
--users=foo@example.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 ゲートウェイを介してクラスタにアクセスするためのコンテキストです。
generate-gateway-rbacコマンドの詳細については、gcloud CLI リファレンス ガイドをご覧ください。
bmctl
ユーザーに RBAC ポリシーを適用するには、管理ワークステーションで次の手順を行います。
clusterSecurity.authorizationセクションをクラスタ構成ファイルに追加します。ご自分のメールアドレスと、クラスタを管理する必要がある他のユーザーのメールアドレスを指定します。次に例を示します。... clusterSecurity: authorization: clusterAdmin: gcpAccounts: [alex@example.com,hao@example.com,sasha@example.com] ...クラスタを更新します。
bmctl update cluster \ -c CLUSTER_NAME \ --kubeconfig=KUBECONFIG次のように変更します。
- CLUSTER_NAME は、更新するクラスタの名前に置き換えます。
- クラスタが自己管理クラスタ（管理クラスタやスタンドアロン クラスタなど）の場合、KUBECONFIG はクラスタの kubeconfig ファイルへのパスに置き換えます。クラスタがユーザー クラスタの場合、KUBECONFIG は管理クラスタの kubeconfig ファイルへのパスに置き換えられます。