Anthos On-Prem API クライアントを使用して管理クラスタを作成する

このページでは、Google Cloud コンソールまたは Google Cloud CLI（gcloud CLI）を使用して管理クラスタを作成する方法について説明します。これらの標準の Google Cloud クライアントは、どちらも Anthos On-Prem API を使用してクラスタを作成します。

Anthos On-Prem API とは

Anthos On-Prem API は、Google Cloud がホストする API で、Terraform や標準の Google Cloud アプリケーションを使用して、オンプレミス クラスタのライフサイクルを管理できます。Anthos On-Prem API は、Google Cloud のインフラストラクチャで動作します。Terraform、コンソール、gcloud CLI はこの API のクライアントであり、この API を使用してデータセンターにクラスタを作成します。

クラスタのライフサイクルを管理するには、Anthos On-Prem API がクラスタの作成時に指定した Google Cloud リージョンを使用して、クラスタの状態に関するメタデータを Google Cloud に保存する必要があります。このメタデータにより、API はクラスタのライフサイクルを管理できますが、メタデータにワークロード固有のデータは含まれません。

Anthos On-Prem API クライアントを使用してクラスタを作成する場合は、Google Cloud プロジェクトを指定します。クラスタが作成されると、指定したプロジェクトのフリートに自動的に登録されます。このプロジェクトはフリート ホスト プロジェクトと呼ばれます。フリートホスト プロジェクトは、クラスタの作成後は変更できません。

管理クラスタは、必要に応じて、管理クラスタの作成で説明されているように、管理クラスタ構成ファイルを作成し、bmctl を使用して作成できます。

bmctl を使用して作成されたクラスタのライフサイクルをコンソールまたは gcloud CLI で管理する場合は、Anthos On-Prem API で管理されるクラスタを構成するをご覧ください。

IAM 権限

Google Cloud プロジェクトのオーナーでない場合は、プロジェクト オーナーから以下のロールを付与してもらう必要があります。

コンソールで GKE Enterprise と Google Kubernetes Engine のページにアクセスする必要がある場合は、roles/container.viewer も必要です。

ロールの付与については、プロジェクト、フォルダ、組織へのアクセスを管理するをご覧ください。

コマンドライン アクセス

クラスタを作成した後、Connect ゲートウェイを使用して、管理ワークステーション以外のコンピュータでクラスタに対して kubectl コマンドを実行する場合は、使用予定のコンピュータに次のコマンドライン ツールをインストールします。

  • 最新バージョンの gcloud CLI。

  • Kubernetes クラスタに対してコマンドを実行するために使用する kubectl。kubectl をインストールする必要がある場合は、以下の手順に沿ってください。

管理クラスタを作成するクライアントを選択する

Anthos On-Prem API で管理される管理クラスタは、コンソールまたは gcloud CLI を使用して作成できます。GKE on Bare Metal を初めてインストールする場合は、gcloud CLI よりもコンソールのほうが使いやすいかもしれません。

クラスタを作成する際に入力する必要がある情報に慣れてきたら、コマンドを引数とともにテキスト ファイルに保存できるため、gcloud CLI のほうが便利かもしれません。Cloud Build などの CI / CD ツールを使用している場合は、gcloud コマンドを使用してクラスタを作成し、--impersonate-service-account フラグを指定して作成を自動化できます。

前提条件

コンソール

  1. Google Cloud コンソールで、GKE Enterprise の [クラスタ] ページに移動します。

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

  2. クラスタを作成する Google Cloud プロジェクトを選択します。選択したプロジェクトは、フリート ホスト プロジェクトとしても使用されます。

  3. [CREATE CLUSTER] をクリックします。

  4. ダイアログ ボックスで、[オンプレミス] をクリックします。

  5. [ベアメタル] の横にある [構成] をクリックします。[管理クラスタを作成する] がオンになっていることを確認します。

[前提条件] ページに、管理ワークステーションとクラスタノード マシンの要件が表示されます。ネットワークの要件セクションの IP アドレス プランナーは、管理クラスタ 1 つ、ユーザー クラスタ 1 つの最小インストールに必要な IP アドレスを計画するのに役立ちます。

管理ワークステーションの前提条件

このセクションを展開して、管理ワークステーションのハードウェア、オペレーティング システム、接続の各要件を表示します。

クラスタノード マシンの前提条件

このセクションを展開して、クラスタ ノードマシンのハードウェア、オペレーティング システム、接続の各要件を表示します。

ネットワークの要件

このセクションは、最小限の環境に必要な IP アドレスの計画に役立ちます。必要に応じて、[ノード IP と仮想 IP アドレス] セクションで、開始ノードの IP アドレスと仮想 IP アドレス（VIP）を指定すると、コンソールに必要な IP アドレスのテーブルが表示されます。これらの IP アドレスは、管理クラスタの構成には適用されません。これらは、インストールに必要な IP アドレスを計画する際に役立つガイドです。テーブルを CSV ファイルにダウンロードしてスプレッドシートまたは IP アドレス プランニング ツールにインポートすることで、クラスタに必要な IP アドレスを追跡するための出発点として使用できます。

Google Cloud リソースの確認

フリートホスト プロジェクトで、必要な Google API がすべて有効化されていることを確認してください。また、Anthos On-Prem API を有効にする必要があります。

gcloud services enable --project FLEET_HOST_PROJECT_ID \
  gkeonprem.googleapis.com

FLEET_HOST_PROJECT_ID は、フリート ホスト プロジェクトのプロジェクト ID に置き換えます。

クラスタを作成する前に、ブートストラップ環境の準備の説明に沿って管理ワークステーションで bmctl register bootstrap コマンドを実行します。このコマンドにより、管理クラスタの作成に必要な最小限の IAM 権限を持つ、必要なサービス アカウントが作成されます。必要に応じて、サービス アカウントを手動で構成することもできます。

開始する準備ができたら、左側のナビゲーション バーで [ブートストラップ環境のインストール] をクリックします。

gcloud CLI

ハードウェア、ネットワーキング、オペレーティング システムの前提条件

Anthos On-Prem API クライアントを使用して管理クラスタを作成するには、bmctl を使用してクラスタを作成する場合と同じハードウェア、ネットワーキング、オペレーティング システムの前提条件が必要です。詳細については、インストールの前提条件をご覧ください。

必要な Google API

フリートホスト プロジェクトで、必要な Google API がすべて有効化されていることを確認してください。また、Anthos On-Prem API を有効にする必要があります。

gcloud services enable --project FLEET_HOST_PROJECT_ID \
  gkeonprem.googleapis.com

FLEET_HOST_PROJECT_ID は、フリート ホスト プロジェクトのプロジェクト ID に置き換えます。

必要なサービス アカウントと権限

クラスタを作成する前に、ブートストラップ環境の準備の説明に沿って管理ワークステーションで bmctl register bootstrap コマンドを実行します。このコマンドにより、管理クラスタの作成に必要な最小限の IAM 権限を持つ、必要なサービス アカウントが作成されます。必要に応じて、サービス アカウントを手動で構成することもできます。

IP アドレスを計画する

管理クラスタを作成する前に、クラスタの IP アドレスを計画する必要があります。高可用性（HA）管理クラスタと 2 つの HA ユーザー クラスタに IP アドレスを割り振る方法の例については、IP アドレスを計画するをご覧ください。gcloud CLI を使用して管理クラスタを作成する場合でも、このセクションのコンソールの手順に沿って IP アドレス プランナーを使用することをおすすめします。

ブートストラップ環境を準備する

管理クラスタを作成する前に、管理ワークステーションで bmctl register bootstrap コマンドを実行する必要があります。このコマンドにより、管理ワークステーションに Kubernetes in Docker（kind）クラスタがデプロイされます。このブートストラップ クラスタは、管理クラスタの作成に必要な Kubernetes コントローラをホストします。管理クラスタを作成すると、ブートストラップ クラスタのコントローラによりノードがプロビジョニングされ、プリフライト チェックが実行されて、管理クラスタがフリートに登録されます。クラスタが正常に作成されると、ブートストラップ クラスタは自動的に削除されます。

コンソール

  1. 管理クラスタの名前を入力します。ブートストラップ クラスタ名は、管理クラスタ名の前に bootstrap- を付けて生成されることに注意してください。

  2. 管理クラスタの GKE on Bare Metal のバージョンを選択します。

  3. [Google Cloud API のロケーション] フィールドで、リストから Google Cloud リージョンを選択します。この設定では、Anthos On-Prem API が実行されるリージョンと、以下のデータが保存されるリージョンを指定します。

    • クラスタのライフサイクルを管理する際に Anthos On-Prem API が必要とするクラスタ メタデータ
    • システム コンポーネントの Cloud Logging データと Cloud Monitoring データ
    • Cloud Audit Logs によって作成された管理監査ログ

    クラスタ名、プロジェクト、ロケーションにより、Google Cloud でクラスタが一意に識別されます。

  4. コンソールに管理ワークステーションで実行する必要があるコマンドが表示されます。bmctl コマンドライン ツールは、作成するクラスタのバージョンと一致する必要があります。該当するバージョンの bmctl がすでに管理ワークステーションにダウンロードされている場合は、再度ダウンロードする必要はありません。

gcloud CLI

  1. gcloud CLI のベータ版コンポーネントを含む、最新バージョンの gcloud CLI があることを確認します。

  2. ベータ版のコンポーネントがない場合は、次のコマンドを実行してインストールします。

    gcloud components install beta

  3. 必要に応じて gcloud CLI コンポーネントを更新します。

    gcloud components update

  4. 次のコマンドを実行して、Google アカウントでログインします。

    gcloud auth login

  5. インストール可能な利用可能な GKE on Bare Metal のバージョンを一覧表示します。ブートストラップ環境を作成するためにダウンロードする bmctl バージョンは、管理クラスタにインストールするバージョンと一致する必要があります。

    gcloud container bare-metal admin-clusters query-version-config \
  --location=REGION

    REGION は、Anthos On-Prem API が実行される Google Cloud リージョンに置き換えます。us-west1 または別のサポートされているリージョンを指定します。

ブートストラップ クラスタを作成する

管理ワークステーションで次の手順を行います。これらのコマンドは、コンソールに表示されます。

  1. ユーザー認証情報をアプリケーションのデフォルト認証情報（ADC）として設定します。

    gcloud auth application-default login

    画面の指示に沿って、ADC 用の Google アカウントを選択します。

  2. 必要に応じて、bmctl コマンドライン ツールを現在の作業ディレクトリにダウンロードします。

    gsutil cp gs://anthos-baremetal-release/bmctl/VERSION/linux-amd64/bmctl .
chmod a+x ./bmctl

    VERSION は、インストールする GKE on Bare Metal のバージョンに置き換えます。コンソールからコマンドをコピーした場合は、バージョンはすでにコマンドに含まれています。

  3. ブートストラップ クラスタを作成します。bmctl で必要なサービス アカウント（SA）を作成するか、自分でサービス アカウントと鍵ファイルを作成して bmctl register bootstrap コマンドに渡します。

bmctl が SA を作成する

bmctl で管理クラスタの作成に必要な最小限の権限を持つ、必要なサービス アカウントを作成する場合は、次のコマンドを使用します。このコマンドは、bmctl が現在の作業ディレクトリにあることを前提としています。

./bmctl register bootstrap \
  --ssh-key=YOUR_PRIVATE_KEY \
  --name=bootstrap-ADMIN_CLUSTER_NAME \
  --project-id=FLEET_HOST_PROJECT_ID

以下を置き換えます。

コンソールに表示されたコマンドをコピーした場合は、次のフィールドはすでに入力されています。

  • ADMIN_CLUSTER_NAME: 管理クラスタの名前。ブートストラップ クラスタ名の形式は bootstrap-ADMIN_CLUSTER_NAME にする必要があります。

  • FLEET_HOST_PROJECT_ID: クラスタの作成後に管理クラスタが自動的に登録されるプロジェクト。

bmctl register bootstrap コマンドによって、次のサービス アカウントが作成されます。サービス アカウント キーは bmctl-workspace/.sa-keys ディレクトリに保存されます。

サービス アカウント 目的 IAM ロール
anthos-baremetal-gcr Anthos on bare metal は、このサービス アカウントを使用して Google Container Registry からコンテナ イメージをダウンロードします。 なし
anthos-baremetal-connect Connect Agent は、このサービス アカウントを使用して、クラスタと Google Cloud 間の接続を維持します roles/gkehub.connect
anthos-baremetal-register Connect Agent は、このサービス アカウントを使用して、Google Cloud フリートにクラスタを登録します。 roles/gkehub.admin
anthos-baremetal-cloud-ops Stackdriver Agent は、このサービス アカウントを使用して、クラスタから Cloud Logging と Cloud Monitoring にログと指標をエクスポートします。 roles/logging.logWriter
roles/monitoring.metricWriter
roles/stackdriver.resourceMetadata.writer
roles/opsconfigmonitoring.resourceMetadata.writer
roles/monitoring.dashboardEditor

SA キーファイルを指定する

必要に応じて、作成したサービス アカウント キー ファイルを bmctl に渡すことができます。次のコマンドは、サービス アカウントを手動で構成するのキーファイル名を使用しており、bmctl とキーファイルが現在の作業ディレクトリにあることを前提としています。

./bmctl register bootstrap \
  --ssh-key=YOUR_PRIVATE_KEY \
  --name=bootstrap-ADMIN_CLUSTER_NAME \
  --project-id=FLEET_HOST_PROJECT_ID \
  --gcr-service-account-key=anthos-baremetal-gcr.json \
  --gke-agent-service-account-key=connect-agent.json \
  --gke-register-service-account-key=connect-register.json \
  --cloud-operation-service-account-key=anthos-baremetal-cloud-ops.json

以下を置き換えます。

  • YOUR_PRIVATE_KEY: 非公開の SSH 認証鍵へのパス。ノードへの root SSH アクセス権を設定したときに SSH 認証鍵を作成しました。

  • ADMIN_CLUSTER_NAME: 管理クラスタの名前。ブートストラップ クラスタ名の形式は bootstrap-ADMIN_CLUSTER_NAME にする必要があります。

  • FLEET_HOST_PROJECT_ID: クラスタの作成後に管理クラスタが自動的に登録されるプロジェクト。

以下のフラグは、キーファイルのパスを指定します。

  • -gcr-service-account-key: コンテナ イメージを pull するサービス アカウント（anthos-baremetal-gcr）のキーファイルのパス。

  • --gke-agent-service-account-key: Connect Agent サービス アカウント（anthos-baremetal-connect）のキーファイルのパス。

  • --gke-register-service-account-key: クラスタをフリートに登録する Connect Agent サービス アカウント（anthos-baremetal-register）のキーファイルのパス。

  • --cloud-operation-service-account-key: ログを監査してプロジェクトをモニタリングするサービス アカウント（anthos-baremetal-cloud-ops）のキーファイルのパス。

bmctl がブートストラップ クラスタの作成に成功すると、次のような出力が表示されます。

[2023-03-22 17:35:24+0000] Waiting for the temporary cluster to be registered... OK
[2023-03-22 17:35:37+0000] Please go to https://console.cloud.google.com/home/dashboard?project=example-project-12345 to create the cluster
[2023-03-22 17:35:37+0000] Waiting for preflight checks and cluster to run..

管理クラスタを作成する

コンソール

  1. [ブートストラップ環境のインストール] ページで、[接続を確認] をクリックします。

    成功すると、コンソールに [ 接続が確立されました] と表示されます。

    続行する前に、ブートストラップ クラスタへの接続が確立されている必要があります。接続が確立されていない場合は、bmctl register bootstrap コマンドに指定した引数を確認します。

    • --name の値が、[ブートストラップ環境の基本] セクションに表示された生成されたブートストラップ名と一致していることを確認します。

    • --project-id の値がコンソールで選択したプロジェクトの ID と一致していることを確認します。

    ブートストラップ クラスタ名またはプロジェクト ID を変更する必要がある場合は、「Ctrl-C」と入力して bmctl register bootstrap を終了し、コマンドを再実行します。

  2. [次へ] をクリックして管理クラスタの構成を開始します。コンソールのほとんどの設定は、クラスタ構成ファイルのフィールドに対応しています。

  3. [ノード構成] で、[ノードあたりの最大 Pod 数] に 64～250 の値を入力するか、デフォルトの 110 を受け入れます。クラスタを作成した後でこの値を更新することはできません。

    ノードあたりの最大 Pod 数（Pod 密度と呼ばれる）は、クラスタで使用可能な IP リソースによっても制限されます。詳しくは、Pod ネットワークをご覧ください。

  4. [Next] をクリックします。

  5. [ネットワーキング] ページで、クラスタ内のノードとコンポーネント間の通信方法や、Kubernetes コントロール プレーンとの通信方法を定義します。

    詳細情報については、各フィールドの横にある にポインタを合わせます。

  6. [確認して作成] をクリックします。

    コンソールで設定を確認し、データセンターにクラスタを作成するときに、ステータス メッセージが表示されます。

    構成に問題がある場合は、エラー メッセージがコンソールに表示されます。このエラー メッセージは、構成の問題を修正してクラスタの作成を再試行できるように十分明確なものでなければなりません。

gcloud CLI

管理クラスタを作成する前に、ブートストラップ クラスタがフリートのメンバーとして登録されていることを確認します。

gcloud container fleet memberships list \
  --project=FLEET_HOST_PROJECT_ID

ブートストラップ クラスタがリストにない場合は、bmctl register bootstrap に指定したブートストラップ クラスタ名とプロジェクト ID を確認します。ブートストラップ クラスタ名またはプロジェクト ID を変更する必要がある場合は、「Ctrl-C」と入力して bmctl register bootstrap を終了し、コマンドを再実行します。

次のコマンドを使用して、管理クラスタを作成します。

gcloud container bare-metal admin-clusters create

コマンドに指定するフラグのほとんどは、ユーザー クラスタ構成ファイルのフィールドに対応しています。

バンドル型ロードバランサを使用して管理クラスタを作成するには:

gcloud container bare-metal admin-clusters create ADMIN_CLUSTER_NAME \
  --project=FLEET_HOST_PROJECT_ID \
  --location=REGION \
  --version=VERSION \
  --max-pods-per-node=MAX_PODS_PER_NODE \
  --control-plane-vip=CONTROL_PLANE_VIP \
  --control-plane-load-balancer-port=CONTROL_PLANE_LOAD_BALANCER_PORT \
  --control-plane-node-configs 'CONTROL_PLANE_NODE_CONFIG' \
  --island-mode-service-address-cidr-blocks=SERVICE_ADDR_CIDR \
  --island-mode-pod-address-cidr-blocks=POD_ADDR_CIDR \
  --lvp-share-path=/mnt/localpv-share \
  --lvp-share-storage-class=local-shared \
  --lvp-node-mounts-config-path=/mnt/localpv-disk \
  --lvp-node-mounts-config-storage-class=local-disks

手動ロード バランシングを使用する必要がある場合は、コマンドに --enable-manual-lb を追加します。

以下を置き換えます。

  • ADMIN_CLUSTER_NAME: 管理クラスタの名前。この名前はクラスタの作成後は変更できません。

  • FLEET_HOST_PROJECT_ID: クラスタの作成後に管理クラスタが自動的に登録されるプロジェクト。 フリートホスト プロジェクトは、クラスタの作成後は変更できません。

  • REGION: Anthos On-Prem API が実行される Google Cloud リージョン。us-west1 または別のサポートされているリージョンを指定します。リージョンはクラスタの作成後は変更できません。この設定では、以下のデータが保存されるリージョンを指定します。

    • クラスタのライフサイクルを管理する際に Anthos On-Prem API が必要とするクラスタ メタデータ
    • システム コンポーネントの Cloud Logging データと Cloud Monitoring データ
    • Cloud Audit Logs によって作成された管理監査ログ

    クラスタ名、プロジェクト、ロケーションにより、Google Cloud でクラスタが一意に識別されます。

  • VERSION: ベアメタル版 GKE バージョン。バージョンは、bmctl register bootstrap を実行するために使用した bmctl のバージョンと一致する必要があります。bmctl のバージョンを確認するには、管理ワークステーションで bmctl version を実行します。

  • MAX_PODS_PER_NODE : 管理クラスタでは 32～250、非 HA クラスタでは 64～250 が許容値です。コマンドに --max-pods-per-node が含まれていない場合のデフォルト値は 110 です。クラスタの作成後は、この値を更新できません。

    ノードあたりの最大 Pod 数（Pod 密度と呼ばれる）は、クラスタで使用可能な IP リソースによっても制限されます。詳しくは、Pod ネットワークをご覧ください。

  • CONTROL_PLANE_VIP: クラスタの Kubernetes API サーバー用ロードバランサの仮想 IP（VIP）。ロードバランサ ノードと同じサブネットにコントロール プレーン VIP を含めます。ロードバランサのアドレスプールには、コントロール プレーン VIP を含めないでください。

  • CONTROL_PLANE_LOAD_BALANCER_PORT: ロードバランサがコントロール プレーンを提供するポート。別の値を構成することもできますが、ポート 443 は HTTPS 接続に使用される標準ポートです。

  • CONTROL_PLANE_NODE_CONFIG: コントロール プレーン ノードの IPv4 アドレス。コントロール プレーン ノードはシステム ワークロードを実行します。コントロール プレーン ノードごとにこのフラグを指定します。通常は、マシン 1 台（最小デプロイメントを使用する場合）とマシン 3 台（高可用性（HA）デプロイメントを使用する場合）のいずれかです。HA 用に過半数のクォーラムが確保できるように、ノード数を奇数で指定します。これらのアドレスは、クラスタを更新またはアップグレードするたびに変更できます。

    フラグの値の形式は次のとおりです。

    'node-ip=CP_IP_ADDRESS_1,labels=CP_KEY_1.1=CP_VALUE_1.1;CP_KEY_1.2=CP_VALUE_1.2;...' \

    この値には、node-ip と labels というキーワードで始まるセグメントがあります。各セグメントをカンマで区切ります。

    • node-ip: コントロール プレーン ノードの IP アドレス。フラグごとに 1 つの node-ip しか指定できません。複数のノードを指定する必要がある場合は、ノードごとにフラグを指定し直してください。

    • labels: ノードに付加される 1 つ以上の Key-Value ペア。

    次の構文ルールに注意してください。

    • 値全体を単一引用符で囲みます。
    • 空白文字は使用できません。
    • labels セグメントの各 Key-Value ペアはセミコロンで区切ります。

    次に例を示します。

    --control-plane-node-configs 'node-ip=192.0.2.1' \
--control-plane-node-configs 'node-ip=192.0.2.2,labels=key2.1=value2.1' \
--control-plane-node-configs 'node-ip=192.0.2.3,labels=key3.1=value3.1;key3.2=value3.2' \

  • SERVICE_ADDR_CIDR: クラスタにある Service の IPv4 アドレスの範囲（CIDR 形式）。CIDR 範囲は /24～/12 にする必要があります（/12 の場合に IP アドレスが最多になります）プライベート インターネットには、RFC 1918 で定義されている IP アドレス空間の範囲（10.96.0.0/20 など）を使用することをおすすめします。

  • POD_ADDR_CIDR: ユーザー クラスタにある Pod に使用される IPv4 アドレスの範囲（CIDR 形式）。CIDR 範囲は /18～/8 にする必要があります（/8 の場合に IP アドレスが最多になります）プライベート インターネットには、RFC 1918 で定義されている IP アドレス空間の範囲（192.168.0.0/16 など）を使用することをおすすめします。

次のストレージ フラグを指定する必要があります。このコマンドの例には、一般的な値が含まれています。詳細については、ローカル ストレージの構成をご覧ください。

  • --lvp-share-path: サブディレクトリを作成できるホストマシンのパスです。サブディレクトリごとにローカル PersistentVolume（PV）が作成されます。

  • --lvp-share-storage-class: 永続ボリュームの作成に使用する StorageClass。StorageClass はクラスタの作成時に作成されます。

  • --lvp-node-mounts-config-path: マウントされたディスクを検出できるホストマシンのパス。それぞれのマウントに対してローカル PersistentVolume（PV）が作成されます。

  • --lvp-node-mounts-config-storage: クラスタの作成時に PV が作成されるストレージ クラス。

フラグとその説明の完全なリストについては、gcloud CLI リファレンスをご覧ください。

このコマンドからの出力は、次のようになります。

Waiting for operation [projects/example-project-12345/locations/us-west1/operations/operation-1679543737105-5f7893fd5bae9-942b3f97-75e59179] to complete.

この出力例では、operation-1679543737105-5f7893fd5bae9-942b3f97-75e59179 という文字列は長時間実行オペレーションの OPERATION_ID です。オペレーションのステータスは、次のコマンドで確認できます。

gcloud container bare-metal operations describe OPERATION_ID \
  --project=FLEET_HOST_PROJECT_ID \
  --location=REGION

詳細については、gcloud container bare metal オペレーションをご覧ください。

プリフライト エラーを修正する

クラスタを作成する前に、bmctl は一連のプリフライト チェックを実行して構成を確認します。構成に問題があると、gcloud ... create コマンドは次のようなエラーで終了します。

ERROR: (gcloud.beta.container.bare-metal.admin-clusters.create) Invalid resource state for "projects/694677185633/locations/us-west1/bareMetalAdminClusters/abm-cluster-1": cluster preflight checks failed

たとえば、コントロール プレーン ノードに到達できなかったため、プリフライト チェックで失敗したとします。管理ワークステーションには、次のように表示されます。

[2023-03-27 20:34:38+0000] Waiting for preflight check job to finish... OK
[2023-03-27 20:35:58+0000] - Validation Category: machines and network
[2023-03-27 20:35:58+0000]    - [PASSED] pod-cidr
[2023-03-27 20:35:58+0000]    - [FAILED] node-network (log: bmctl-workspace/log/register-bootstrap-20230327-201548/node-network)
[2023-03-27 20:35:58+0000]        - Failed to connect to the host via ssh: ssh: connect to host 10.100.0.5 port 22: Connection timed out
[2023-03-27 20:35:58+0000] Flushing logs... OK
[2023-03-27 20:35:58+0000] Error polling the preflight check abm-cluster-mar-27 in the cluster-abm-cluster-mar-27: preflight check failed

  1. 管理ワークステーションで、bmctl register bootstrap プロセスがまだ実行されていることを確認します。実行されていない場合は、同じ引数でコマンドを再実行して --reuse-bootstrap-cluster=true フラグを追加します。

  2. gcloud ... update を実行して無効な IP アドレスを修正します。

    gcloud container bare-metal admin-clusters update ADMIN_CLUSTER_NAME \
  --project=FLEET_HOST_PROJECT_ID \
  --location=REGION \
  --control-plane-node-configs 'node-ip=NEW_NODE_ID_ADDRESS'

    詳細については、gcloud container bare-metal admin-clusters update をご覧ください。

クラスタ作成プロセスの詳細は、管理ワークステーションに出力されます。プリフライト チェックに合格すると、次のように表示されます。

[2023-03-22 23:12:47+0000] Waiting for cluster kubeconfig to become ready OK
[2023-03-22 23:15:47+0000] Writing kubeconfig file
[2023-03-22 23:15:47+0000] kubeconfig of cluster being created is present at bmctl-workspace/abm-cluster-1/abm-cluster-1-kubeconfig
[2023-03-22 23:15:47+0000] Please restrict access to this file as it contains authentication credentials of your cluster.
[2023-03-22 23:15:47+0000] Waiting for cluster to become ready OK
[2023-03-22 23:20:17+0000] Please run
[2023-03-22 23:20:17+0000] kubectl --kubeconfig bmctl-workspace/abm-cluster-1/abm-cluster-1-kubeconfig get nodes
[2023-03-22 23:20:17+0000] to get cluster nodes status.
[2023-03-22 23:20:17+0000] Waiting for node pools to become ready OK
[2023-03-22 23:20:37+0000] Waiting for metrics to become ready in GCP OK
[2023-03-22 23:25:38+0000] Waiting for cluster API provider to install in the created admin cluster OK
[2023-03-22 23:25:48+0000] Moving admin cluster resources to the created admin cluster
[2023-03-22 23:25:51+0000] Waiting for node update jobs to finish OK
[2023-03-22 23:27:41+0000] Flushing logs... OK
[2023-03-22 23:27:41+0000] Deleting membership... OK
[2023-03-22 23:27:42+0000] Deleting bootstrap cluster.

管理クラスタに接続する

bmctl register bootstrap コマンドにより、管理ワークステーションに管理クラスタの kubeconfig ファイルが作成されます。kubeconfig が配置されているディレクトリとファイル名は、次のように管理クラスタ名に基づいています。

bmctl-workspace/ADMIN_CLUSTER_NAME/ADMIN_CLUSTER_NAME-kubeconfig

この kubeconfig にはクラスタの認証情報が含まれているため、アクセスを制限する必要があります。

Google ID でクラスタにログインする必要がある場合は、Connect ゲートウェイを次のように設定します。

  1. 管理ワークステーションで、KUBECONFIG 環境変数を設定します。

    export KUBECONFIG=$HOME/bmctl-workspace/ADMIN_CLUSTER_NAME/ADMIN_CLUSTER_NAME-kubeconfig

  2. 現在のコンテキストを環境変数に設定します。

    export CONTEXT="$(kubectl config current-context)"

  3. 次の gcloud コマンドを実行します。このコマンドは次の処理を行います。

    • ユーザー アカウントにクラスタに対する Kubernetes clusterrole/view ロールを付与します。
    • 管理ワークステーションに SSH 接続しなくても、ローカル コンピュータで読み取り専用の kubectl コマンドを実行できるようにクラスタを構成します。

    GOOGLE_ACCOUNT_EMAIL は、Google Cloud アカウントに関連付けられているメールアドレスに置き換えます。例: --users=alex@example.com。

    gcloud container fleet memberships generate-gateway-rbac  \
    --membership=ADMIN_CLUSTER_NAME \
    --role=clusterrole/view \
    --users=GOOGLE_ACCOUNT_EMAIL \
    --project=FLEET_HOST_PROJECT_ID \
    --kubeconfig=$KUBECONFIG \
    --context=$CONTEXT\
    --apply

    このコマンドの出力は次のようになります（読みやすくするために省略しています）。

    Validating input arguments.
Specified Cluster Role is: clusterrole/view
Generated RBAC policy is:
--------------------------------------------
...

Writing RBAC policy for user: GOOGLE_ACCOUNT_EMAIL to cluster.
Successfully applied the RBAC policy to cluster.

これらの RBAC ポリシーを適用すると、Google ID を使用してコンソールからクラスタにログインできます。さらに、Connect ゲートウェイ経由でリクエストをルーティングする特別な kubeconfig を使用して、管理ワークステーション以外のコンピュータで読み取り専用の kubectl コマンドを実行することもできます。

  1. 管理ワークステーション以外のコンピュータで次のコマンドを実行して、Connect ゲートウェイ経由でクラスタにアクセスできる kubeconfig エントリを取得します。

    gcloud container fleet memberships get-credentials ADMIN_CLUSTER_NAME \
    --project=FLEET_HOST_PROJECT_ID

    出力は次のようになります。

    Starting to build Gateway kubeconfig...
Current project_id: FLEET_HOST_PROJECT_ID
A new kubeconfig entry "connectgateway_FLEET_HOST_PROJECT_ID_global_ADMIN_CLUSTER_NAME" has been generated and set as the current context.

  2. これで、Connect ゲートウェイ経由で kubectl コマンドを実行できるようになりました。

    kubectl get pods -A

次のステップ