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 によって管理されているクラスタを確認できます。

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

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

    GKE クラスタに移動

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

    • ベアメタルが [タイプ] 列に表示されている場合、クラスタは GKE On-Prem API によって管理されています。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 認証を設定する方法については、次のガイドをご覧ください。

  • 署名なしトークン: 上記の 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 GatewayConnect 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 ポリシーをユーザーに適用するには、管理ワークステーションで次の操作を行います。

  1. 次のコマンドを実行して、コンポーネントを更新します(必要な場合)。

    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: そのフリートでクラスタを一意に表すために使用される名前。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

  1. 次のコマンドを実行してコンポーネントを更新します。

    gcloud components update
    
  2. 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

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

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

    ...
    clusterSecurity:
      authorization:
        clusterAdmin:
          gcpAccounts: [alex@example.com,hao@example.com,sasha@example.com]
    ...
    
  2. クラスタを更新します。

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

    次のように変更します。

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

コンソール

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

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

    GKE クラスタに移動

  2. ユーザー クラスタが存在する Google Cloud プロジェクトを選択します。

  3. クラスタリストでクラスタの名前をクリックし、[詳細] パネルの [詳細を表示] をクリックします。

  4. [認可] セクションで [管理者ユーザー] フィールドをクリックし、各ユーザーのメールアドレスを入力します。

  5. ユーザーの追加が完了したら、[完了] をクリックします。

詳細