Compute Engine VM 上に、Google Distributed Cloud Virtual for Bare Metal の管理クラスタとユーザー クラスタを作成する

Version 1.14 

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

このページでは、Compute Engine 仮想マシン（VM）上に Google Distributed Cloud Virtual for Bare Metal のユーザー クラスタと管理クラスタを作成する方法について説明します。提供されているスクリプトにより、管理クラスタノードとユーザー クラスタノード用の Compute Engine VM と管理ワークステーションが作成されます。

管理ワークステーションは、インストール中にクラスタをプロビジョニングするためのコマンドライン インターフェース（CLI）ツールと構成ファイルをホストします。また、インストール後に、プロビジョニングされたクラスタとやり取りするための CLI ツールもホストします。このスクリプトにより、管理ワークステーション VM に CLI ツールがインストールされます。

ユーザー クラスタは、コンテナ化されたワークロードを実行する Kubernetes クラスタです。 これは、コントロール プレーン ノードとワーカーノードで構成されます。ユーザー クラスタには、ユーザー ワークロードを実行する 1 つ以上のワーカーノードを含める必要があります。管理クラスタは、1 つ以上のユーザー クラスタを管理する Kubernetes クラスタであり、ユーザー クラスタの作成、更新、削除に役立ちます。管理クラスタは、コントロール プレーン ノードのみで構成されます。詳細については、管理クラスタとユーザー クラスタのデプロイをご覧ください。

このスクリプトにより、VM 間で Virtual Extensible LAN（VXLAN）オーバーレイ ネットワークを構成され、クラスタ作成のために VM が準備されます。このスクリプトは必要に応じて管理クラスタを作成します。または、管理者クラスタを自ら作成して、管理クラスタを作成するために GKE on Bare Metal に用意されているツールについて学習することもできます。

提供されているスクリプトを使用すると、ハードウェアを準備せずに GKE on Bare Metal をすぐに試すことができます。このページの手順を完了すると、Compute Engine で実行されている GKE on Bare Metal のテスト環境が機能するようになります。

重要: このデプロイは評価のみを目的としています。本番環境の Compute Engine VM で GKE on Bare Metal を実行しないでください。

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 プロジェクトを指定します。クラスタが作成されると、指定したプロジェクトのフリートに自動的に登録されます。このプロジェクトはフリート ホスト プロジェクトと呼ばれます。フリートホスト プロジェクトは、クラスタの作成後は変更できません。

準備

1. Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.

2. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

   Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

   Go to project selector

3. Make sure that billing is enabled for your Google Cloud project.

4. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

   Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

   Go to project selector

5. Make sure that billing is enabled for your Google Cloud project.

6. このページのスクリプトとコマンドで使用する環境変数を設定する際に必要となるため、プロジェクト ID をメモしておきます。既存のプロジェクトを選択した場合は、ご自身がプロジェクト オーナーまたはプロジェクト編集者であることを確認します。
7. このスクリプトは、Cloud Shell で実行できます。また、Linux あるいは macOS が実行されているローカルマシンで実行できます。Cloud Shell を使用しない場合:
   1. 最新の Google Cloud CLI（Google Cloud とやり取りするためのコマンドライン ツール）がインストールされていることを確認します。必要に応じて gcloud CLI コンポーネントを更新します。

      gcloud components update

      gcloud CLI のインストール方法によっては、「このインストールでは Google Cloud CLI コンポーネント マネージャーが無効になっているため、この操作を実行できません。次のコマンドを実行して、このインストールで同じ結果を得ることができます。」というメッセージが表示される可能性があります。以下の手順に従って、コマンドをコピーして貼り付け、コンポーネントを更新してください。

   2. kubectl がインストールされていることを確認します。kubectl をインストールする必要がある場合は、次のコマンドを実行します。

      gcloud components install kubectl

VM インフラストラクチャを作成し、必要に応じて管理クラスタを作成する

次の手順に沿ってスクリプトを準備し、実行します。ダウンロードして実行するスクリプトは、anthos-samples リポジトリにあります。スクリプトを実行する前に詳細を確認するには、次のセクションのスクリプトについてをご覧ください。

1. 環境変数を設定します。

   export PROJECT_ID=PROJECT_ID
   export ADMIN_CLUSTER_NAME=ADMIN_CLUSTER_NAME
   export ON_PREM_API_REGION=ON_PREM_API_REGION
   export ZONE=ZONE
   

   • ON_PREM_API_REGION: Anthos On-Prem API が稼働しメタデータを保存する Google Cloud リージョン。us-central1 または別のサポートされているリージョンを指定します。

   • ZONE: Compute Engine VM が作成される Google Cloud ゾーン。us-central1-a または他の Compute Engine ゾーンを使用できます。

2. デフォルトのプロジェクトとゾーンを設定するには、次のコマンドを実行します。

   gcloud config set project $PROJECT_ID
   gcloud config set compute/zone $ZONE
   

   PERMISSION_DENIED エラーが発生した場合は、入力したプロジェクト ID を再確認してください。プロジェクト ID が正しい場合は、gcloud auth login を実行して、プロジェクトにアクセスできるアカウントで gcloud CLI にログインします。

3. インストール可能な 1.14 バージョンのリストを取得します。

   gcloud container bare-metal admin-clusters query-version-config \
         --location=ON_PREM_API_REGION | grep 1.14
   

4. 前のコマンドの出力からバージョンを選択し、環境変数に設定します。

   export BMCTL_VERSION=BMCTL_VERSION
   

5. anthos-samples リポジトリのクローンを作成し、スクリプトを配置するディレクトリに移動します。

   git clone https://github.com/GoogleCloudPlatform/anthos-samples
   cd anthos-samples/anthos-bm-gcp-bash
   

6. スクリプトを実行します。

   bash install_admin_cluster.sh
   

7. プロンプトが表示されたら、インストール モードを選択する番号を入力します。

   • 「1」と入力して、スクリプトで VM インフラストラクチャを設定し、管理クラスタをインストールします。
   • VM インフラストラクチャのみをスクリプトで設定するには、「2」と入力します。

8. プロンプトが表示されたら、選択内容を確認します。

このスクリプトは、実行された各コマンドとステータスを出力します。完了すると、管理クラスタのインストールを選択したかどうかに応じて、スクリプトによって次の内容が出力されます。

管理クラスタを作成しました

✅ Installation complete. Please check the logs for any errors!!!
✅ If you do not see any errors in the output log, then you now have the following setup:

|---------------------------------------------------------------------------------------------------------|
| VM Name               | L2 Network IP (VxLAN) | INFO                                                    |
|---------------------------------------------------------------------------------------------------------|
| abm-admin-cluster-cp1 | 10.200.0.3            | Has control plane of admin cluster running inside       |
| abm-user-cluster-cp1  | 10.200.0.4            | 🌟 Ready for use as control plane for the user cluster  |
| abm-user-cluster-w1   | 10.200.0.5            | 🌟 Ready for use as worker for the user cluster         |
| abm-user-cluster-w2   | 10.200.0.6            | 🌟 Ready for use as worker for the user cluster         |
|---------------------------------------------------------------------------------------------------------|

VM のみを設定する

|---------------------------------------------------------------------------------------------------------|
| VM Name               | L2 Network IP (VxLAN) | INFO                                                    |
|---------------------------------------------------------------------------------------------------------|
| abm-admin-cluster-cp1 | 10.200.0.3            | 🌟 Ready for use as control plane for the admin cluster |
| abm-user-cluster-cp1  | 10.200.0.4            | 🌟 Ready for use as control plane for the user cluster  |
| abm-user-cluster-w1   | 10.200.0.5            | 🌟 Ready for use as worker for the user cluster         |
| abm-user-cluster-w2   | 10.200.0.6            | 🌟 Ready for use as worker for the user cluster         |
|---------------------------------------------------------------------------------------------------------|

スクリプトについて

install_admin_cluster.sh の詳細を確認するには、次の行の [スクリプトについて] をクリックします。

スクリプトについて

このスクリプトは、次の手動手順を自動化します。

1. baremetal-gcr というサービス アカウントを作成し、サービス アカウントに追加の権限を付与します。これにより、異なる API やサービスに対して複数のサービス アカウントが不要になります。
2. 次の Google Cloud APIs を有効にします。

     anthos.googleapis.com
     anthosaudit.googleapis.com
     anthosgke.googleapis.com
     cloudresourcemanager.googleapis.com
     connectgateway.googleapis.com
     container.googleapis.com
     gkeconnect.googleapis.com
     gkehub.googleapis.com
     gkeonprem.googleapis.com
     iam.googleapis.com
     logging.googleapis.com
     monitoring.googleapis.com
     opsconfigmonitoring.googleapis.com
     serviceusage.googleapis.com
     stackdriver.googleapis.com
     storage.googleapis.com

3. 次の VM を作成します。
   • 管理ワークステーション用の 1 つの VM。管理ワークステーションは、SSH を介して他のすべてのクラスタノードにアクセスできます。
   • 1 つの VM（管理クラスタのコントロール プレーン ノード用）。
   • 2 つの VM（ユーザー クラスタのワーカーノード用）。
   • 1 つの VM（ユーザー クラスタのコントロール プレーン ノード用）。
   また、スクリプトにより、すべての VM で SSH が有効になっていることも確認されます。
4. VM 間のレイヤ 2 接続用に Virtual Extensible LAN（VXLAN）オーバーレイ ネットワークを作成します。VXLAN は永続的ではないため、VM インスタンスを再起動するとネットワークは破棄されます。ネットワークは、10.200.0.0/24 サブネット上に設定されます。レイヤ 2 接続はバンドル型ロードバランサの要件です。
5. 管理ワークステーションに次のツールをインストールします。
   • bmctl
   • kubectl
   • Docker

   また、このスクリプトは、baremetal-gcr サービス アカウントのサービス アカウント キーも管理ワークステーションにダウンロードします。

6. 次のタスクを行い、管理ワークステーションからの root@10.200.0.x が機能するようにします。
   1. 管理ワークステーションで新しい SSH 認証鍵を生成します。
   2. その公開鍵を、デプロイメント内の他のすべての VM に追加します。
7. このスクリプトは、必要に応じて、次の構成ファイルを使用して管理クラスタを作成します。
   anthos-bm-gcp-bash/install_admin_cluster.sh

   GitHub で表示

     gcloud compute ssh root@"$VM_WS" --zone "${ZONE}" <<EOF
   set -x
   export PROJECT_ID=\$(gcloud config get-value project)
   ADMIN_CLUSTER_NAME=\$(curl http://metadata.google.internal/computeMetadata/v1/instance/attributes/cluster_id -H "Metadata-Flavor: Google")
   BMCTL_VERSION=\$(curl http://metadata.google.internal/computeMetadata/v1/instance/attributes/bmctl_version -H "Metadata-Flavor: Google")
   export ADMIN_CLUSTER_NAME
   export BMCTL_VERSION
   bmctl create config -c \$ADMIN_CLUSTER_NAME
   cat > bmctl-workspace/\$ADMIN_CLUSTER_NAME/\$ADMIN_CLUSTER_NAME.yaml << EOB
   ---
   gcrKeyPath: /root/bm-gcr.json
   sshPrivateKeyPath: /root/.ssh/id_rsa
   gkeConnectAgentServiceAccountKeyPath: /root/bm-gcr.json
   gkeConnectRegisterServiceAccountKeyPath: /root/bm-gcr.json
   cloudOperationsServiceAccountKeyPath: /root/bm-gcr.json
   ---
   apiVersion: v1
   kind: Namespace
   metadata:
     name: cluster-\$ADMIN_CLUSTER_NAME
   ---
   apiVersion: baremetal.cluster.gke.io/v1
   kind: Cluster
   metadata:
     name: \$ADMIN_CLUSTER_NAME
     namespace: cluster-\$ADMIN_CLUSTER_NAME
   spec:
     type: admin
     anthosBareMetalVersion: \$BMCTL_VERSION
     gkeConnect:
       projectID: \$PROJECT_ID
     controlPlane:
       nodePoolSpec:
         clusterName: \$ADMIN_CLUSTER_NAME
         nodes:
         - address: 10.200.0.3
     clusterNetwork:
       pods:
         cidrBlocks:
         - 192.168.0.0/16
       services:
         cidrBlocks:
         - 10.96.0.0/20
     loadBalancer:
       mode: bundled
       ports:
         controlPlaneLBPort: 443
       vips:
         controlPlaneVIP: 10.200.0.48
     clusterOperations:
       # might need to be this location
       location: us-central1
       projectID: \$PROJECT_ID
     storage:
       lvpNodeMounts:
         path: /mnt/localpv-disk
         storageClassName: node-disk
       lvpShare:
         numPVUnderSharedPath: 5
         path: /mnt/localpv-share
         storageClassName: local-shared
     nodeConfig:
       podDensity:
         maxPodsPerNode: 250
   EOB
   
   bmctl create cluster -c \$ADMIN_CLUSTER_NAME
   EOF

   このスクリプトに管理クラスタを作成させる場合は、スクリプトが SSH を使用して root ユーザーとして管理ワークステーションにログインします。次に、bmctl コマンドライン ツールを実行して管理クラスタを作成します。これは、管理クラスタの作成に使用できるツールの一つです。

   GKE on Bare Metal がクラスタを作成すると、管理ワークステーションに Kubernetes in Docker（kind）クラスタがデプロイされます。このブートストラップ クラスタは、クラスタの作成に必要な Kubernetes コントローラをホストし、管理クラスタの作成に使用されます。作成時に、関連するコントローラは、ブートストラップ クラスタから管理クラスタに移動されます。最後に、特に指定しない限り、ブートストラップ クラスタはクラスタの作成が正常に完了すると削除されます。ブートストラップ クラスタでは、Docker がコンテナ イメージを pull する必要があります。

必要に応じて管理クラスタを作成する

プレビュー

この機能には、サービス固有の利用規約の「一般的なサービス規約」の「pre-GA サービス規約」が適用されます。 pre-GA の機能は「現状有姿」で利用できますが、サポートが制限される場合があります。 詳しくは、リリース ステージの説明をご覧ください。

スクリプトによって管理クラスタが作成された場合は、次のセクションの管理クラスタを確認するに進みます。それ以外の場合は、このセクションの手順に沿って、ブートストラップ クラスタと管理クラスタを作成します。

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

コンソール

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

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

2. プロジェクト リストから PROJECT_ID を選択してください。

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

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

5. [ベアメタル] の横にある [構成] をクリックします。[前提条件] ページには、管理ワークステーションとクラスタノード マシンの要件が表示されます。

   [管理クラスタを作成する] がオンになっていることを確認します。

6. 左側のナビゲーション バーで、[ブートストラップ環境のインストール] をクリックします。

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

8. 管理クラスタのバージョンとして VERSION を選択します。スクリプトにより、このバージョンの bmctl コマンドライン ツールが管理ワークステーションにダウンロードされます。インストールする GKE on Bare Metal のバージョンは、bmctl バージョンと一致する必要があります。

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

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

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

コンソールに表示される手順ではなく、次のセクションの手順を使用して、ブートストラップ クラスタを作成します。管理クラスタを作成するときに戻るため、コンソール ページを表示したままにします。

gcloud CLI

新しいターミナル ウィンドウを開きます。2 つ目のターミナル ウィンドウを使用して、管理ワークステーションに接続し、ブートストラップ クラスタを作成します。1 つ目のターミナル ウィンドウを使用して、gcloud CLI コマンドを実行し、管理クラスタを作成します。

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

管理ワークステーションで次の手順を行います。

1. root として管理ワークステーションに SSH 接続します。

   gcloud compute ssh root@abm-ws --zone ZONE
   

   VM の更新に関するメッセージは無視して、このチュートリアルを完了してください。VM をテスト環境として維持する場合は、Ubuntu のドキュメントに記載されているように、OS を更新するか次のリリースにアップグレードすることをおすすめします。

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

   gcloud auth application-default login
   

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

3. ブートストラップ クラスタを作成します。

   bmctl register bootstrap \
     --ssh-key=/root/.ssh/id_rsa \
     --name=bootstrap-ADMIN_CLUSTER_NAME \
     --project-id=PROJECT_ID
   

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 コマンドを終了すると、管理クラスタの作成に失敗します。クラスタが正常に作成されると、コマンドはブートストラップ クラスタを自動的に削除して終了します。

管理クラスタを作成する

コンソール

1. [管理ワークステーションからの環境のブートストラップ] セクションの [ブートストラップ環境のインストール] ページで、[接続を確認] をクリックします。

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

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

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

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

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

2. 左側のナビゲーション バーで [ネットワーキング] をクリックします。

3. [コントロール プレーン] セクションで、[コントロール プレーン ノード IP 1] フィールドに次のように入力します。

   10.200.0.3
   

   これは、スクリプトによって作成された VXLAN にある abm-admin-cluster-cp VM の IP アドレスです。

4. [ロードバランサ] セクションで、[バンドル] が選択されていることを確認します。

5. [仮想 IP（VIP）] セクションで、[コントロール プレーン VIP] フィールドに次のように入力します。

   10.200.0.48
   

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

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

gcloud CLI

1. 以前に定義した環境変数に正しい値が設定されていることを確認します。このコマンドの例ではプレースホルダを使用していますが、プレースホルダは、スクリプトで使用した環境変数と一致する必要があります。

   echo $PROJECT_ID
   echo $ADMIN_CLUSTER_NAME
   echo $ON_PREM_API_REGION
   echo $BMCTL_VERSION
   

2. ブートストラップ クラスタがフリートのメンバーとして登録されていることを確認します。

   gcloud container fleet memberships list \
     --project=PROJECT_ID
   

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

3. バンドル型ロードバランサを使用して管理クラスタを作成します。

   gcloud container bare-metal admin-clusters create ADMIN_CLUSTER_NAME \
     --project=PROJECT_ID \
     --location=ON_PREM_API_REGION \
     --version=BMCTL_VERSION \
     --max-pods-per-node=110 \
     --control-plane-vip=10.200.0.48 \
     --control-plane-load-balancer-port=443 \
     --control-plane-node-configs node-ip=10.200.0.3 \
     --island-mode-service-address-cidr-blocks=10.96.0.0/20 \
     --island-mode-pod-address-cidr-blocks=192.168.0.0/16 \
     --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
   

   前のコマンドで:

   • --control-plane-vip: 10.200.0.48 に設定されています。これは、クラスタの Kubernetes API サーバー用のロードバランサの仮想 IP（VIP）です。

   • --control-plane-node-configs: node-ip は 10.200.0.3 に設定されています。これは、スクリプトによって作成された VXLAN にある abm-admin-cluster-cp VM の IP アドレスです。

   フラグとそれらの説明の全一覧については、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=PROJECT_ID \
     --location=ON_PREM_API_REGION
   

クラスタ作成プロセスの詳細は、管理ワークステーションに出力されます。クラスタを作成する前に、bmctl は一連のプリフライト チェックを実行して構成を確認します。プリフライト チェックに合格すると、次のように表示されます。

[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.

管理クラスタを確認する

管理ワークステーションにある管理クラスタの kubeconfig ファイルは、root アカウントの bmctl-workspace ディレクトリにあります。デプロイを確認するには次の手順を行います。

1. スクリプトによって管理クラスタが作成された場合は、root として管理ワークステーションに SSH 接続します。

   gcloud compute ssh root@abm-ws --zone ZONE
   

   VM の更新に関するメッセージを無視して、このチュートリアルを完了して問題ありません。VM をテスト環境として維持する場合は、Ubuntu のドキュメントに記載されているように、OS を更新するか次のリリースにアップグレードすることをおすすめします。

2. KUBECONFIG 環境変数にクラスタの構成ファイルへのパスを設定し、クラスタで kubectl コマンドを実行します。

   export clusterid=ADMIN_CLUSTER_NAME
   export KUBECONFIG=$HOME/bmctl-workspace/$clusterid/$clusterid-kubeconfig
   kubectl get nodes
   

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

   NAME                   STATUS   ROLES                  AGE   VERSION
   abm-admin-cluster-cp   Ready    control-plane,master   91m   v1.24.2-gke.1900
   

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

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

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

   • ユーザー アカウントにクラスタに対する Kubernetes clusterrole/cluster-admin ロールを付与します。
   • 管理ワークステーションに SSH 接続せずにローカル コンピュータで kubectl コマンドを実行できるようにクラスタを構成します。
   • Google ID を使用して、コンソールでクラスタにログインできます。

   YOUR_EMAIL_ADDRESS は、Google Cloud アカウントに関連付けられているメールアドレスに置き換えます。例: --users=[e-mail]。

   gcloud container fleet memberships generate-gateway-rbac  \
       --membership=ADMIN_CLUSTER_NAME \
       --role=clusterrole/cluster-admin \
       --users=YOUR_EMAIL_ADDRESS \
       --project=PROJECT_ID \
       --kubeconfig=$KUBECONFIG \
       --context=$CONTEXT\
       --apply
   

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

   Validating input arguments.
   Specified Cluster Role is: clusterrole/cluster-admin
   Generated RBAC policy is:
   --------------------------------------------
   ...
   
   Applying the generate RBAC policy to cluster with kubeconfig: /root/bmctl-workspace/ADMIN_CLUSTER_NAME/ADMIN_CLUSTER_NAME-kubeconfig, context: ADMIN_CLUSTER_NAME-admin@ADMIN_CLUSTER_NAME
   Writing RBAC policy for user: YOUR_EMAIL_ADDRESS to cluster.
   Successfully applied the RBAC policy to cluster.
   

5. 完了したら、「exit」と入力して管理ワークステーションからログアウトします。

6. ローカル PC で次のコマンドを実行して、Connect ゲートウェイを介してクラスタにアクセスできる kubeconfig エントリを取得します。

   gcloud container fleet memberships get-credentials ADMIN_CLUSTER_NAME
   

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

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

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

   kubectl get nodes
   

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

   NAME                   STATUS   ROLES                  AGE   VERSION
   abm-admin-cluster-cp   Ready    control-plane,master   94m   v1.24.2-gke.1900
   

8. スクリプトによって管理クラスタが作成された場合は、次のコマンドを実行して、クラスタを Anthos On-Prem API に登録します。

   gcloud container bare-metal admin-clusters enroll ADMIN_CLUSTER_NAME  \
       --project=PROJECT_ID \
       --admin-cluster-membership=projects/PROJECT_ID/locations/global/memberships/ADMIN_CLUSTER_NAME \
       --location=ON_PREM_API_REGION
   

   自分でクラスタを作成した場合は、自動的に Anthos On-Prem API に登録されます。

ユーザー クラスタを作成する

VM の L2 VXLAN がスクリプトを作成すると、10.200.0.0/24 のネットワークに次の IP アドレスが割り振られます。これらの IP アドレスは、ユーザー クラスタのネットワークとノードプールの設定を構成するときに使用します。

VM 名	ネットワーク IP	ノードの説明
abm-admin-cluster-cp1	10.200.0.3	管理クラスタのコントロール プレーン ノード
abm-user-cluster-cp1	10.200.0.4	ユーザー クラスタのコントロール プレーン ノード
abm-user-cluster-w1	10.200.0.5	ユーザー クラスタのワーカーノード
abm-user-cluster-w2	10.200.0.6	ユーザー クラスタの別のワーカーノード

Google Cloud コンソール、Google Cloud CLI、または Terraform を使用してユーザー クラスタを作成できます。

コンソール

コンソールでユーザー クラスタを作成する手順は次のとおりです。

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

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

2. 管理クラスタを作成した Google Cloud プロジェクトが選択されていることを確認します。管理クラスタがリストに表示されます。

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

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

5. [ベアメタル] の横にある [構成] をクリックします。[前提条件] ページが表示されます。

6. [クラスタタイプの選択] で、[既存の管理クラスタ用のユーザー クラスタを作成する] を選択します。

7. [次へ] をクリックします。

クラスタの基本

1. ユーザー クラスタの名前を入力するか、デフォルトを使用します。

2. 新しく作成した管理クラスタが選択されていることを確認します。このページの残りの設定には、デフォルト値を使用できます。

3. 左側のナビゲーション バーで [ネットワーキング] をクリックします。

ネットワーキング

1. [コントロール プレーン] セクションで、[コントロール プレーン ノード IP 1] フィールドに次を入力します。

   10.200.0.4
   

   これは、スクリプトによって作成された VXLAN にある abm-user-cluster-cp1 VM の IP アドレスです。

2. [ロードバランサ] セクションで、デフォルトのロードバランサ [バンドルされた MetalLB] を使用します。

3. [新しいアドレスプール] セクションで、[IP アドレス範囲 1] フィールドに次の IP アドレス範囲を入力します。

   10.200.0.51-10.200.0.70
   

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

5. [仮想 IP] セクションで、[コントロール プレーン VIP] フィールドに次の IP アドレスを入力します。

   10.200.0.50
   

6. [Ingress VIP] に、次の IP アドレスを入力します。

   10.200.0.51
   

7. [サービスと Pod の CIDR] セクションで、デフォルトの IP アドレスを使用します。

8. 左側のナビゲーション バーで [デフォルト プール] をクリックします。

ノードプールを作成

クラスタには、ワーカーノード用のノードプールが少なくとも 1 つ必要です。ノードプールは、このクラスタで作成されるワーカーノードのグループのテンプレートです。

[ノードアドレス 1] フィールドに、次の IP アドレスを入力します。

10.200.0.5

これは、スクリプトによって作成された VXLAN にある abm-user-cluster-w1 VM の IP アドレスです。

クラスタを作成する

1. [確認して作成] をクリックしてユーザー クラスタを作成します。

   ユーザー クラスタの作成には 15 分以上かかります。コンソールには、設定の確認とクラスタの作成中にステータス メッセージが表示されます。

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

   作成プロセスに関する追加情報を表示するには、[詳細を表示] をクリックしてサイドパネルを表示します。[] をクリックすると、詳細パネルが閉じます。

   クラスタが作成されると、「クラスタ ステータス: 実行中」と表示されます。

   

2. クラスタが作成されたら、 [クラスタ] をクリックして [クラスタ] ページに戻ります。

gcloud CLI

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

gcloud container bare-metal clusters create

クラスタを作成したら、次のコマンドを使用して少なくとも 1 つのノードプールを作成する必要があります。

gcloud container bare-metal node-pools create

ユーザー クラスタを作成するには:

1. 以前に定義した環境変数に正しい値が設定されていることを確認します。このコマンドの例ではプレースホルダを使用していますが、プレースホルダは、スクリプトで使用した環境変数と一致する必要があります。

   echo $PROJECT_ID
   echo $ADMIN_CLUSTER_NAME
   echo $ON_PREM_API_REGION
   echo $BMCTL_VERSION
   

2. 次のコマンドを実行して、ユーザー クラスタを作成します。次のように置き換えます。

   • USER_CLUSTER_NAME: クラスタの名前。

   • クラスタを管理できるように、--admin-users が Google アカウントに関連付けられているメールアドレスに設定されていることを確認します。

   残りのフラグ値は入力されています。必要に応じてスクロールし、--admin-cluster-membership フラグに管理クラスタ名の正しい値が設定されていることを確認します。この値が、完全に指定されたメンバーシップ名の最後のセグメントです。

   gcloud container bare-metal clusters create USER_CLUSTER_NAME \
     --project=PROJECT_ID \
     --admin-cluster-membership=projects/PROJECT_ID/locations/global/memberships/ADMIN_CLUSTER_NAME \
     --location=ON_PREM_API_REGION \
     --version=BMCTL_VERSION \
     --admin-users=YOUR_EMAIL_ADDRESS \
     --metal-lb-address-pools='pool=lb-pool-1,manual-assign=True,addresses=10.200.0.51-10.200.0.70' \
     --control-plane-node-configs='node-ip=10.200.0.4' \
     --control-plane-vip=10.200.0.50 \
     --control-plane-load-balancer-port=443 \
     --ingress-vip=10.200.0.51 \
     --island-mode-service-address-cidr-blocks=10.96.0.0/20 \
     --island-mode-pod-address-cidr-blocks=192.168.0.0/16 \
     --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
   

次のリストは、フラグの説明です。

• --project: ユーザー クラスタを登録するプロジェクトの ID。このプロジェクトはフリート ホスト プロジェクトと呼ばれます。

• --admin-cluster-membership: フリート内の管理クラスタを識別する完全に指定された管理クラスタ名。

• --location: Anthos On-Prem API が稼働しメタデータを保存する Google Cloud リージョン。

• --version: GKE on Bare Metal のバージョン。

• --admin-users: クラスタへの完全な管理者権限を与える Kubernetes のロールベース アクセス制御（RBAC）ポリシーを付与するメールアドレスを含めます。

• --metal-lb-address-pools: バンドル型 MetalLB ロードバランサのアドレスプール構成。IP アドレス範囲は、スクリプトによって作成された 10.200.0.0/24 ネットワークに存在する必要があります。アドレス範囲には、VM またはコントロール プレーン VIP に割り当てられた IP アドレスを含めることはできません。ただし、上り（内向き）VIP はこのアドレス範囲内にある必要があります。

• --control-plane-node-configs: ユーザー クラスタのコントロール プレーン ノード構成。node-ip の値は 10.200.0.4 です。これは、スクリプトが VM abm-user-cluster-cp1 に割り当てた IP アドレスです。

• --control-plane-vip: コントロール プレーンの仮想 IP。値 10.200.0.50 は、スクリプトが作成した 10.200.0.0/24 ネットワークに存在しますが、MetalLB のロードバランサ アドレスプールに使用される IP アドレス範囲とは重複しません。

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

• --ingress-vip: Ingress サービスの仮想 IP。この IP アドレスは、MetalLB のロードバランサのアドレスプールに使用される IP アドレス範囲に含まれている必要があります。

• --island-mode-service-address-cidr-blocks: ユーザー クラスタ内の Service に使用される IP アドレスの範囲（CIDR 形式）。このコマンドの例では、10.96.0.0/20 を使用しています。これは、コンソールで提供されるデフォルト値です。CIDR 範囲は /24～/12 にする必要があります（/12 の場合に IP アドレスが最多になります）。RFC 1918 で定義されているプライベート インターネットの IP アドレス空間内の範囲を使用することをおすすめします。

• --island-mode-pod-address-cidr-blocks: ユーザー クラスタにある Pod に使用される IP アドレスの範囲（CIDR 形式）。このコマンドの例では、192.168.0.0/16 を使用しています。これは、コンソールで提供されるデフォルト値です。CIDR 範囲は /18～/8 にする必要があります（/8 の場合に IP アドレスが最多になります）。RFC 1918 で定義されているプライベート インターネットの IP アドレス空間内の範囲を使用することをおすすめします。

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

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

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

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

コマンドを実行すると、次のような出力が表示されます。

Waiting for operation [projects/PROJECT_ID/locations/ON_PREM_API_REGION/operations/operation-1678304606537-5f668bde5c57e-341effde-b612ff8a] to complete...

この出力例では、operation-1678304606537-5f668bde5c57e-341effde-b612ff8a という文字列は長時間実行オペレーションの OPERATION_ID です。

オペレーションのステータスを確認するには、出力から OPERATION_ID を次のコマンドにコピーします。別のターミナル ウィンドウを開き、コマンドを実行します。

gcloud container bare-metal operations describe OPERATION_ID \
    --project=PROJECT_ID \
    --location=ON_PREM_API_REGION

クラスタの作成には 15 分以上かかります。クラスタが作成されている間、上記のコマンドを繰り返し実行することで現在のステータスを取得できます。

クラスタが作成されると、次のような出力が表示されます。

Created Anthos cluster on bare metal [https://gkeonprem.googleapis.com/v1/projects/PROJECT_ID/locations/ON_PREM_API_REGION/bareMetalClusters/USER_CLUSTER_NAME].

ノードプールを作成

クラスタが正常に作成されたら、次のコマンドを実行してノードプールを作成します。NODE_POOL_NAME をノードプールの名前に置き換え、--cluster フラグのプレースホルダがユーザー クラスタの名前に設定されていることを確認します。

gcloud container bare-metal node-pools create NODE_POOL_NAME \
  --cluster=USER_CLUSTER_NAME \
  --project=PROJECT_ID \
  --location=ON_PREM_API_REGION \
  --node-configs='node-ip=10.200.0.5'

• -node-configs: node-ip に割り当てられる値は、スクリプトによって作成された VXLAN にある abm-user-cluster-w1 VM の IP アドレスです。

コマンドを実行すると、次のような出力が表示されます。

Waiting for operation [projects/PROJECT_ID/locations/ON_PREM_API_REGION/operations/operation-1678308682052-5f669b0d132cb-6ebd1c2c-816287a7] to complete...

ノードプールは、およそ 5 分以内で作成されます。ノードプールが作成されると、次のような出力が表示されます。

Created node pool in Anthos cluster on bare metal [https://gkeonprem.googleapis.com/v1/projects/PROJECT_ID/locations/ON_PREM_API_REGION/bareMetalClusters/USER_CLUSTER_NAME/bareMetalNodePools/NODE_POOL_NAME].

その他のユーザー クラスタ コマンド

クラスタの作成以外に、次のような gcloud CLI コマンドを実行できます。

• ユーザー クラスタを一覧表示するには:

gcloud container bare-metal clusters list \
    --project=PROJECT_ID \
    --location=ON_PREM_API_REGION

• ユーザー クラスタを記述するには:

gcloud container bare-metal clusters describe USER_CLUSTER_NAME \
    --project=PROJECT_ID \
    --location=ON_PREM_API_REGION

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

その他のノードプール コマンド

ノードプールの作成以外に、次のような gcloud CLI コマンドも実行できます。

• ノードプールを一覧表示するには:

gcloud container bare-metal node-pools list \
    --cluster=USER_CLUSTER_NAME \
    --project=PROJECT_ID \
    --location=ON_PREM_API_REGION

• ノードプールを記述するには:

gcloud container bare-metal node-pools describe NODE_POOL_NAME \
    --cluster=USER_CLUSTER_NAME \
    --project=PROJECT_ID \
    --location=ON_PREM_API_REGION

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

Terraform

バンドルされた MetalLB ロードバランサを使用してユーザー クラスタを作成するには、次の基本的な構成サンプルを使用できます。詳細については、google_gkeonprem_bare_metal_cluster リファレンス ドキュメントをご覧ください。

1. anthos-samples のクローンを作成したディレクトリで、Terraform のサンプルがあるディレクトリに移動します。

   cd anthos-samples/anthos-onprem-terraform/abm_user_cluster_metallb
   

   このサンプルには、main.tf に渡すサンプル変数が用意されています。

2. terraform.tfvars.sample ファイルのコピーを作成します。

   cp terraform.tfvars.sample terraform.tfvars
   

   anthos-onprem-terraform/abm_user_cluster_metallb/terraform.tfvars.sample

   GitHub で表示

   
   project_id          = "PROJECT_ID"
   region              = "ON_PREM_API_REGION"
   admin_cluster_name  = "ADMIN_CLUSTER_NAME"
   bare_metal_version  = "VERSION"
   admin_user_emails   = ["YOUR_EMAIL_ADDRESS", "ADMIN_2_EMAIL_ADDRESS"]
   cluster_name        = "abm-user-cluster-metallb"
   control_plane_ips   = ["10.200.0.4"]
   worker_node_ips     = ["10.200.0.5", "10.200.0.6"]
   control_plane_vip   = "10.200.0.50"
   ingress_vip         = "10.200.0.51"
   lb_address_pools    = [
       { name = "lbpool_1", addresses = ["10.200.0.51-10.200.0.70"] }
   ]
   

3. terraform.tfvars でパラメータ値を変更し、ファイルを保存します。

   変数は次のリストのとおりです。

   • project_id: ユーザー クラスタを登録するプロジェクトの ID。このプロジェクトはフリート ホスト プロジェクトと呼ばれます。

   • region: チュートリアルの冒頭で設定した Google Cloud リージョン。echo $ON_PREM_API_REGION を実行して値を取得します。

   • admin_cluster_name: このチュートリアルの最初に設定した管理クラスタの名前。echo $ADMIN_CLUSTER_NAME を実行して値を取得します。

   • bare_metal_version: ユーザー クラスタの GKE on Bare Metal のバージョン。管理クラスタと同じバージョンを使用するには、echo $BMCTL_VERSION を実行して値を取得します。必要に応じて、管理クラスタのバージョンより 1 つ前のマイナー バージョン以下のバージョンを指定できます。ユーザー クラスタのバージョンは、管理クラスタのバージョンよりも大きくすることはできません。

   • cluster_name: TVARS ファイル内のユーザー クラスタの名前を使用するか、任意の名前を指定します。この名前はクラスタの作成後は変更できません。

   • admin_user_emails: クラスタに対する管理者権限を付与するユーザーのメールアドレスのリスト。クラスタを管理できるように、必ずメールアドレスを追加してください。

     クラスタが作成されると、Anthos On-Prem API によって Kubernetes のロールベースのアクセス制御（RBAC）ポリシーがクラスタに適用され、管理ユーザーに Kubernetes の clusterrole/cluster-admin ロールが付与されます。このロールは、すべての名前空間で、クラスタのすべてのリソースに対する完全アクセス権を付与します。これにより、ユーザーは Google の ID を使用してコンソールにログインできます。

   残りの変数には、terraform.tvars で定義されているデフォルト値を使用します。このスクリプトは、VM と管理クラスタの作成時に、これらの値を使用しました。

   • control_plane_ips: コントロール プレーン ノードの 1 つ以上の IPv4 アドレスのリスト。デフォルト値を使用します。これは、スクリプトが VM abm-user-cluster-cp1 に割り当てた IP アドレスです。

   • worker_node_ips: ワーカーノード マシンの 1 つ以上の IPv4 アドレスのリスト。デフォルト値を使用します。これは、スクリプトが VM abm-user-cluster-w1 と abm-user-cluster-w2 に割り当てた IP アドレスです。

   • control_plane_vip: コントロール プレーンの仮想 IP（VIP）。デフォルト値 10.200.0.50 を使用します。これは、スクリプトが作成した 10.200.0.0/24 ネットワーク内にあります。なお、この IP アドレスは、MetalLB のロードバランサ アドレスプールに使用される IP アドレス範囲とは重複しません。

   • ingress_vip: Ingress プロキシのロードバランサに構成する仮想 IP アドレス。デフォルト値 10.200.0.51 を使用します。これは、スクリプトが作成した 10.200.0.0/24 ネットワーク内にあります。なお、この IP アドレスは、MetalLB のロードバランサのアドレスプールに使用される IP アドレス範囲にあります。

   • lb_address_pools: MetallLB ロードバランサのアドレスプールを定義するマップのリスト。デフォルト値を使用します。

4. 変更を terraform.tfvars に保存します。

5. Terraform プランを初期化して作成します。

   terraform init
   

   Terraform によって、Google Cloud プロバイダなどの必要なライブラリがインストールされます。

6. 構成を確認し、必要に応じて変更を加えます。

   terraform plan
   

7. Terraform プランを適用して、ユーザー クラスタを作成します。

   terraform apply
   

   ユーザー クラスタの作成には 15 分以上かかります。クラスタは、Google Cloud コンソールの Anthos クラスタ ページで確認できます。

ユーザー クラスタに接続する

コンソールまたは gcloud CLI を使用してユーザー クラスタを作成すると、クラスタは、gcloud container fleet memberships generate-gateway-rbac の実行時に管理クラスタについて構成したのと同じ Kubernetes のロールベース アクセス制御（RBAC）ポリシーで構成されます。これらの RBAC ポリシーを使用すると、Google Cloud アカウントに関連付けられている Google Cloud ID（メールアドレス）を使用してクラスタに接続できます。これらの RBAC ポリシーを使用すると、追加の構成なしでコンソールにログインできます。

コンソールでクラスタに接続する

gcloud CLI を使用してユーザー クラスタを作成した場合は、コンソールで GKE Enterprise の [クラスタ] ページに移動します。

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

ユーザー クラスタを作成したプロジェクトが選択されていることを確認します。管理クラスタとユーザー クラスタの両方がリストに表示されます。

ユーザー クラスタには、[タイプ] 列に Anthos（Bare Metal: ユーザー）が表示されます。これは、クラスタが Anthos On-Prem API によって管理されていることを示します。

管理クラスタでは、[タイプ] 列に [外部] と表示されます。これは、そのクラスタが Anthos On-Prem API によって管理されていないことを示します。

管理クラスタは、bmctl を使用してスクリプトによって作成されたものですが、Anthos On-Prem API で管理される管理クラスタを構成できます。

クラスタにログインするには:

1. クラスタ名のリンクをクリックして、サイドパネルで [ログイン] をクリックします。

2. [Google ID を使用してログインします] を選択します。

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

管理クラスタへのログインにも同じ手順を繰り返します。

コマンドラインでクラスタに接続する

Anthos On-Prem API では、ユーザー クラスタ作成者として RBAC ポリシーが構成されます。これらのポリシーを使用すると、Connect ゲートウェイの kubeconfig を使用してローカル PC で kubectl コマンドを実行できます。

ローカル コンピュータから:

1. Connect ゲートウェイを介してクラスタにアクセスできる kubeconfig エントリを取得します。

   gcloud container fleet memberships get-credentials USER_CLUSTER_NAME
   

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

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

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

   kubectl get nodes
   

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

   NAME                  STATUS   ROLES                  AGE     VERSION
   abm-user-cluster-cp   Ready    control-plane,master   14m     v1.24.2-gke.1900
   abm-user-cluster-w1   Ready    worker                 8m28s   v1.24.2-gke.1900
   

別のノードプールをユーザー クラスタに追加する

コンソール

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

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

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

3. [ノード] タブをクリックします。

4. [ノードプールを追加] をクリックします。

5. ノードプールの名前を入力します。

6. [ノードアドレス 1] フィールドに、次の IP アドレスを入力します。

   10.200.0.6
   

   これは、スクリプトによって作成された abm-user-cluster-w2 VM の IP アドレスです。

7. [作成] をクリックします。

8. 必要に応じて、[ノード] タブをもう一度クリックします。

9. 新しいノードプールのステータスは、[整合中] になります。

10. 右上隅の をクリックして、ノードプール作成のステータスを表示します。ノードプール リストに更新されたステータスを表示するには、ページの更新が必要になる場合があります。

gcloud CLI

次のコマンドを実行して、別のノードプールを作成します。NODE_POOL_NAME_2 をノードプールの名前に置き換え、--cluster フラグのプレースホルダがユーザー クラスタの名前に設定されていることを確認します。

gcloud container bare-metal node-pools create NODE_POOL_NAME_2 \
  --cluster=USER_CLUSTER_NAME \
  --project=PROJECT_ID \
  --location=ON_PREM_API_REGION \
  --node-configs='node-ip=10.200.0.6'

• -node-configs: node-ip に割り当てられる値は、スクリプトによって作成された VXLAN にある abm-user-cluster-w2 VM の IP アドレスです。

Terraform

Terraform を使用してクラスタを作成した場合、クラスタは 2 つのノードで作成されたため、VXLAN 内に別のノードを追加できる VM はありません。ノードプールの追加については、google_gkeonprem_bare_metal_cluster リファレンス ドキュメントをご覧ください。

kubectl を使用して新しいノードを確認することもできます。まず、前述のように gcloud container fleet memberships get-credentials コマンドを実行して、クラスタ構成を取得する必要があります。

kubectl get nodes

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

NAME                  STATUS   ROLES                  AGE     VERSION
abm-user-cluster-cp   Ready    control-plane,master   24m   v1.24.2-gke.1900
abm-user-cluster-w1   Ready    worker                 18m   v1.24.2-gke.1900
abm-user-cluster-w2   Ready    worker                 52s   v1.24.2-gke.1900

クリーンアップ

ユーザー クラスタを削除する

コンソール

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

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

2. クラスタのリストで、ユーザー クラスタをクリックします。

3. [詳細] パネルで、[詳細] をクリックします。

4. ウィンドウの上部にある [削除] をクリックします。

5. 確認の入力を求められたら、クラスタ名を入力して [確認] をクリックします。

6. 右上隅にある をクリックして、削除のステータスを表示します。クラスタリストを更新するには、ページの更新が必要になる場合があります。

gcloud CLI

次のコマンドを実行してクラスタを削除します。

gcloud container bare-metal clusters delete USER_CLUSTER_NAME \
  --project=PROJECT_ID \
  --location=ON_PREM_API_REGION \
  --force

--force フラグを使用すると、ノードプールを持つクラスタを削除できます。--force フラグを使用せずに、まず ノードプールを削除 してから、クラスタを削除する必要があります。

その他のフラグの詳細については、gcloud container bare-metal clusters delete をご覧ください。

Terraform

次のコマンドを実行します。

terraform destroy

ユーザー クラスタが削除されるのを待ってから、管理クラスタと VM を削除します。

管理クラスタと VM を削除する

1. Anthos On-Prem API から管理クラスタの登録を解除します。

   gcloud container bare-metal admin-clusters unenroll ADMIN_CLUSTER_NAME \
       --project=PROJECT_ID \
       --location=ON_PREM_API_REGION
   

2. 管理ワークステーションに接続します。

   gcloud compute ssh root@abm-ws --zone ZONE
   

3. 管理クラスタを削除します。

   bmctl reset -c ADMIN_CLUSTER_NAME
   

   bmctl は、フリートからクラスタの登録を解除し、クラスタを削除します。クラスタが削除されるのを待ってから、VM を削除します。

4. 管理ワークステーションを終了します。

5. 名前に abm を含むすべての VM を一覧表示します。

   gcloud compute instances list | grep 'abm'
   

6. 名前に abm を含むすべての VM を削除しても問題がないことを確認します。

   確認後、次のコマンドを実行して abm VM を削除できます。

   gcloud compute instances list --format="value(name)" | \
     grep 'abm'  | \
     xargs gcloud --quiet compute instances delete
   

7. サービス アカウントを削除します。

   gcloud iam service-accounts delete baremetal-gcr@PROJECT_ID.iam.gserviceaccount.com
   

   確認プロンプトで、「y」と入力します。

   次のステップ

• Service と Ingress を作成する
• インストールを計画する
• 基本クラスタを作成する