このページでは、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 プロジェクトのオーナーでない場合は、プロジェクト オーナーから以下のロールを付与してもらう必要があります。
コンソールで Anthos と Google Kubernetes Engine のページにアクセスする必要がある場合は、roles/container.viewer も必要です。
ロールの付与については、プロジェクト、フォルダ、組織へのアクセスを管理するをご覧ください。
コマンドライン アクセス
クラスタを作成した後、Connect ゲートウェイを使用して、管理ワークステーション以外のコンピュータでクラスタに対して kubectl コマンドを実行する場合は、使用予定のコンピュータに次のコマンドライン ツールをインストールします。
最新バージョンの gcloud CLI。
Kubernetes クラスタに対してコマンドを実行するために使用する
kubectl。kubectlをインストールする必要がある場合は、以下の手順に沿ってください。
管理クラスタを作成するクライアントを選択する
コンソールまたは gcloud CLI を使用して、Anthos On-Prem API で管理される管理クラスタを作成できます。Anthos clusters on bare metal を初めてインストールする場合は、gcloud CLI よりもコンソールのほうが使いやすいかもしれません。
クラスタを作成する際に入力する必要がある情報に慣れてきたら、コマンドを引数とともにテキスト ファイルに保存できるため、gcloud CLI のほうが便利かもしれません。Cloud Build などの CI / CD ツールを使用している場合は、gcloud コマンドを使用してクラスタを作成し、--impersonate-service-account フラグを指定して作成を自動化できます。
前提条件
コンソール
Google Cloud コンソールで、Anthos の [クラスタ] ページに移動します。
クラスタを作成する Google Cloud プロジェクトを選択します。選択したプロジェクトは、フリート ホスト プロジェクトとしても使用されます。
[CREATE CLUSTER] をクリックします。
ダイアログ ボックスで、[オンプレミス] をクリックします。
[ベアメタル] の横にある [構成] をクリックします。[管理クラスタを作成する] がオンになっていることを確認します。
[前提条件] ページに、管理ワークステーションとクラスタノード マシンの要件が表示されます。ネットワークの要件セクションの 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 コントローラをホストします。管理クラスタを作成すると、ブートストラップ クラスタのコントローラによりノードがプロビジョニングされ、プリフライト チェックが実行されて、管理クラスタがフリートに登録されます。クラスタが正常に作成されると、ブートストラップ クラスタは自動的に削除されます。
コンソール
管理クラスタの名前を入力します。ブートストラップ クラスタ名は、管理クラスタ名の前に bootstrap- を付けて生成されることに注意してください。
管理クラスタの Anthos clusters on bare metal を選択します。
[Google Cloud API のロケーション] フィールドで、リストから Google Cloud リージョンを選択します。この設定では、Anthos On-Prem API が実行されるリージョンと、以下のデータが保存されるリージョンを指定します。
- クラスタのライフサイクルを管理する際に Anthos On-Prem API が必要とするクラスタ メタデータ
- システム コンポーネントの Cloud Logging データと Cloud Monitoring データ
- Cloud Audit Logs によって作成された管理監査ログ
クラスタ名、プロジェクト、ロケーションにより、Google Cloud でクラスタが一意に識別されます。
コンソールに管理ワークステーションで実行する必要があるコマンドが表示されます。
bmctlコマンドライン ツールは、作成するクラスタのバージョンと一致する必要があります。該当するバージョンのbmctlがすでに管理ワークステーションにダウンロードされている場合は、再度ダウンロードする必要はありません。
gcloud CLI
gcloud CLI のベータ版コンポーネントを含む、最新バージョンの gcloud CLI があることを確認します。
ベータ版のコンポーネントがない場合は、次のコマンドを実行してインストールします。
gcloud components install beta
必要に応じて gcloud CLI コンポーネントを更新します。
gcloud components update
次のコマンドを実行して、Google アカウントでログインします。
gcloud auth login
利用可能な Anthos clusters on bare metal のインストール可能なバージョンを一覧表示します。ブートストラップ環境を作成するためにダウンロードする
bmctlバージョンは、管理クラスタにインストールするバージョンと一致する必要があります。gcloud beta container bare-metal admin-clusters query-version-config \ --location=REGION
REGIONは、Anthos On-Prem API が実行される Google Cloud リージョンに置き換えます。us-west1または別のサポートされているリージョンを指定します。
ブートストラップ クラスタを作成する
管理ワークステーションで次の手順を行います。これらのコマンドは、コンソールに表示されます。
ユーザー認証情報をアプリケーションのデフォルト認証情報（ADC）として設定します。
gcloud auth application-default login
画面の指示に沿って、ADC 用の Google アカウントを選択します。
必要に応じて、
bmctlコマンドライン ツールを現在の作業ディレクトリにダウンロードします。gsutil cp gs://anthos-baremetal-release/bmctl/VERSION/linux-amd64/bmctl . chmod a+x ./bmctl
VERSIONは、インストールする Anthos clusters on bare metal のバージョンに置き換えます。コンソールからコマンドをコピーした場合は、バージョンはすでにコマンドに含まれています。ブートストラップ クラスタを作成します。
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
以下を置き換えます。
YOUR_PRIVATE_KEY: 非公開の SSH 認証鍵へのパス。ノードへの root SSH アクセス権を設定したときに SSH 認証鍵を作成しました。
コンソールに表示されたコマンドをコピーした場合は、次のフィールドはすでに入力されています。
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 エージェントは、このサービス アカウントを使用して、クラスタから 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..
管理クラスタを作成する
コンソール
[ブートストラップ環境のインストール] ページで、[接続を確認] をクリックします。
成功すると、コンソールに [ 接続が確立されました] と表示されます。
続行する前に、ブートストラップ クラスタへの接続が確立されている必要があります。接続が確立されていない場合は、
bmctl register bootstrapコマンドに指定した引数を確認します。--nameの値が、[ブートストラップ環境の基本] セクションに表示された生成されたブートストラップ名と一致していることを確認します。--project-idの値がコンソールで選択したプロジェクトの ID と一致していることを確認します。
ブートストラップ クラスタ名またはプロジェクト ID を変更する必要がある場合は、「
Ctrl-C」と入力してbmctl register bootstrapを終了し、コマンドを再実行します。[次へ] をクリックして管理クラスタの構成を開始します。コンソールのほとんどの設定は、クラスタ構成ファイルのフィールドに対応しています。
[ノード構成] で、[ノードあたりの最大 Pod 数] に 64～250 の値を入力するか、デフォルトの 110 を受け入れます。クラスタを作成した後でこの値を更新することはできません。
ノードあたりの最大 Pod 数（Pod 密度と呼ばれる）は、クラスタで使用可能な IP リソースによっても制限されます。詳しくは、Pod ネットワークをご覧ください。
[Next] をクリックします。
[ネットワーキング] ページで、クラスタ内のノードとコンポーネント間の通信方法や、Kubernetes コントロール プレーンとの通信方法を定義します。
詳細情報については、各フィールドの横にある にポインタを合わせます。
[確認して作成] をクリックします。
コンソールで設定を確認し、データセンターにクラスタを作成するときに、ステータス メッセージが表示されます。
構成に問題がある場合は、エラー メッセージがコンソールに表示されます。このエラー メッセージは、構成の問題を修正してクラスタの作成を再試行できるように十分明確なものでなければなりません。
gcloud CLI
管理クラスタを作成する前に、ブートストラップ クラスタがフリートのメンバーとして登録されていることを確認します。
gcloud container fleet memberships list \ --project=FLEET_HOST_PROJECT_ID
ブートストラップ クラスタがリストにない場合は、bmctl register bootstrap に指定したブートストラップ クラスタ名とプロジェクト ID を確認します。ブートストラップ クラスタ名またはプロジェクト ID を変更する必要がある場合は、「Ctrl-C」と入力して bmctl register bootstrap を終了し、コマンドを再実行します。
次のコマンドを使用して、管理クラスタを作成します。
gcloud beta container bare-metal admin-clusters create
コマンドに指定するフラグのほとんどは、ユーザー クラスタ構成ファイルのフィールドに対応しています。
バンドル型ロードバランサを使用して管理クラスタを作成するには:
gcloud beta 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: Anthos clusters on bare metal のバージョン。バージョンは、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 アドレス空間の範囲（172.26.232.0/24など）を使用することをおすすめします。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 beta container bare-metal operations describe OPERATION_ID \ --project=FLEET_HOST_PROJECT_ID \ --location=REGION
詳細については、gcloud beta container bare metal オペレーションをご覧ください。
プリフライト エラーを修正する
クラスタを作成する前に、bmctl は一連のプリフライト チェックを実行して構成を確認します。構成に問題があると、gcloud ... create コマンドは次のようなエラーで終了します。
ERROR: (gcloud.alpha.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
管理ワークステーションで、
bmctl register bootstrapプロセスがまだ実行されていることを確認します。実行されていない場合は、同じ引数でコマンドを再実行して--reuse-bootstrap-cluster=trueフラグを追加します。gcloud ... updateを実行して無効な IP アドレスを修正します。gcloud beta 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 beta container bare-metal 管理クラスタの更新 をご覧ください。
クラスタ作成プロセスの詳細は、管理ワークステーションに出力されます。プリフライト チェックに合格すると、次のように表示されます。
[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 ゲートウェイを次のように設定します。
管理ワークステーションで、
KUBECONFIG環境変数を設定します。export KUBECONFIG=$HOME/bmctl-workspace/ADMIN_CLUSTER_NAME/ADMIN_CLUSTER_NAME-kubeconfig
現在のコンテキストを環境変数に設定します。
export CONTEXT="$(kubectl config current-context)"次の
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.- ユーザー アカウントにクラスタに対する Kubernetes
これらの RBAC ポリシーを適用すると、Google ID を使用してコンソールからクラスタにログインできます。さらに、Connect ゲートウェイ経由でリクエストをルーティングする特別な kubeconfig を使用して、管理ワークステーション以外のコンピュータで読み取り専用の kubectl コマンドを実行することもできます。
管理ワークステーション以外のコンピュータで次のコマンドを実行して、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.これで、Connect ゲートウェイ経由で
kubectlコマンドを実行できるようになりました。kubectl get pods -A