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

Version 1.14 

• 最新
• バージョン 1.16
• 以前のバージョン（サポート対象外）

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

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

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

GKE on Bare Metal では、ユーザー クラスタは作成時にフリートに登録されます。

• bmctl を使用してクラスタを作成する場合は、クラスタ構成ファイルの gkeConnect セクションでフリートホスト プロジェクトを指定します。GKE on Bare Metal は、この情報を使用して、指定したフリート プロジェクトにクラスタを登録します。

• コンソールでユーザー クラスタを作成すると、自動的にクラスタはコンソールで選択したプロジェクトのフリート メンバーになります。

  注: コンソールでの Google Distributed Cloud Virtual for Bare Metal のユーザー クラスタの作成は、プレビュー版が公開されます。

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

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

• クラスタのクラスタ ライフサイクル管理を有効にしている場合は、コンソールを使用してユーザー クラスタをアップグレード、更新、削除することもできます。これを行うには、Anthos On-Prem API と呼ばれるサービスによってクラスタを管理する必要があります。コンソールで作成されたユーザー クラスタでは、クラスタの作成時にクラスタのライフサイクル管理が有効になります。また、後で bmctl を使用して作成されたユーザー クラスタに対して、この機能を有効にすることもできます。この機能が有効になっていない場合は、管理ワークステーションで bmctl を使用してクラスタのライフサイクルの管理のみを行えます。

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

すべてのフリート クラスタは、コンソールの [GKE Enterprise クラスタ] ページと [GKE クラスタ] ページに表示されます。これらの両方によって、フリート全体の概要と、GKE on Bare Metal では Anthos On-Prem API によって管理されているクラスタを確認できます。

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

1. コンソールで GKE Enterprise クラスタページに移動します。

   GKE Enterprise クラスタのページに移動する

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

   • Anthos Bare Metal が [タイプ] 列に表示されている場合、クラスタは Anthos On-Prem API によって管理されています。

   • [タイプ] 列に [外部] と表示されている場合は、クラスタが Anthos 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 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 ロールを使用すると、Anthos 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:[e-mail]）。

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

コンソールで作成されたユーザー クラスタは、Anthos On-Prem API によって自動的に管理され、コンソールでクラスタのライフサイクル管理タスクを実行できます。bmctl を使用して作成したユーザー クラスタでこの機能を有効にする場合は、Anthos On-Prem API で管理されるようにユーザー クラスタを構成するに記載されている手順に沿って操作します。クラスタ ライフサイクル管理を有効にすると、コンソールからクラスタを更新できます。

• ユーザー クラスタの更新
• ユーザー クラスタのノードプールを追加または削除する
• ユーザー クラスタの削除

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

Google ID 認証を設定する

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

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

• コネクト ゲートウェイがコネクト エージェント経由でクラスタの Kubernetes API サーバーにアクセスするために必要な Kubernetes のロールベース アクセス制御（RBAC）ポリシーにユーザーを追加する必要があります。

RBAC 認可を構成する

各クラスタの Kubernetes API サーバーは、コンソールからのリクエストを認可できる必要があります。認可を構成するには、クラスタごとに Kubernetes のロールベースのアクセス制御（RBAC）ポリシーを構成する必要があります。コンソールでクラスタを作成した場合、Anthos On-Prem API はユーザー アカウントを管理者として追加し、クラスタに対する完全な管理者権限を付与する適切な RBAC ポリシーを作成します。

gcloud CLI

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

1. 次のコマンドを実行して、Google アカウントでログインし、コンポーネントを更新します。

   gcloud auth login
   gcloud components update
   

2. 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: 対象のフリートでクラスタを一意に表すために使用される名前。GKE on Bare Metal では、メンバーシップ名とクラスタ名は同じです。
   • ROLE: クラスタのユーザーに付与する Kubernetes のロール。ユーザーに、クラスタ内のすべての名前空間ですべてのリソースへの完全アクセス権を付与するには、clusterrole/cluster-admin を指定します。アクセスを制限するには、カスタムロールを作成します（例: role/mynamespace/namespace-reader）。カスタムロールは、コマンドを実行する前に存在している必要があります。
   • USERS: カンマ区切りのリストととして、権限を付与するユーザー（ユーザー アカウントまたはサービス アカウント）のメールアドレス。例: --users=[e-mail],[e-mail]。
   • 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 ゲートウェイを介してクラスタにアクセスするためのコンテキストです。

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

bmctl

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

1. clusterSecurity.authorization セクションをクラスタ構成ファイルに追加します。ご自分のメールアドレスと、クラスタを管理する必要がある他のユーザーのメールアドレスを指定します。次に例を示します。

   ...
   clusterSecurity:
     authorization:
       clusterAdmin:
         gcpAccounts: [[e-mail],[e-mail],[e-mail]]
   ...
   

   注: このフィールドは、ワークロードを実行できるクラスタにのみ適用されます。管理クラスタには gcpAccounts を指定できません。

2. クラスタを更新します。

   bmctl update cluster \
       -c CLUSTER_NAME \
       --kubeconfig=KUBECONFIG
   

   次のように変更します。

   • CLUSTER_NAME は、更新するクラスタの名前に置き換えます。
   • クラスタが自己管理クラスタ（管理クラスタやスタンドアロン クラスタなど）の場合、KUBECONFIG はクラスタの kubeconfig ファイルへのパスに置き換えます。クラスタがユーザー クラスタの場合、KUBECONFIG は管理クラスタの kubeconfig ファイルへのパスに置き換えられます。

詳細情報

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