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

コンソール

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

1. コンソールで、ベアメタル クラスタの作成ページに移動します。

   ベアメタル クラスタの作成ページに移動

2. クラスタを作成する Google Cloud プロジェクトを選択します。選択したプロジェクトは、フリート ホスト プロジェクトとしても使用されます。これは、管理クラスタが登録されているプロジェクトと同じでなければなりません。ユーザー クラスタを作成すると、選択したプロジェクトのフリートに自動的に登録されます。

3. [次へ] をクリックしてクラスタの構成を開始します。

次のセクションでは、ユーザー クラスタの構成について説明します。

クラスタの基本

クラスタの基本情報を入力します。

1. ユーザー クラスタの名前を入力します。

2. [管理クラスタ] で、リストから管理クラスタを選択します。

3. [Google Cloud API のロケーション] フィールドで、リストから Google Cloud リージョンを選択します。この設定では、次の API とサービスが実行されるリージョンを指定します。

   • GKE On-Prem API（gkeonprem.googleapis.com）
   • Fleet サービス（gkehub.googleapis.com）
   • Connect サービス（gkeconnect.googleapis.com）

   この設定では、以下のものが保存されるリージョンも制御されます。

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

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

4. ユーザー クラスタのバージョンを選択します。ユーザー クラスタは、管理クラスタと同じマイナー バージョンか、管理クラスタより 1 つ低いマイナー バージョンである必要があります。

5. クラスタ作成者には、クラスタに対するクラスタ管理者権限が付与されます。必要に応じて、[管理者ユーザー] フィールドに、クラスタを管理する別のユーザーのメールアドレスを入力します。

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

6. [ノード構成] セクションで、次のように指定します。

   • ノードあたりの最大 Pod 数: 単一ノードで実行できる Pod の最大数を入力します。使用できる値は、32 ～ 250 です。Kubernetes は、各 Pod に一意の IP アドレスが指定されるように、クラスレス ドメイン間ルーティング（CIDR）ブロックを各ノードに割り当てます。CIDR ブロックのサイズは、1 ノードあたりの最大 Pod 数と対応します。ノードあたりの最大ポッド数の設定の詳細については、ポッド ネットワーキングをご覧ください。

   • コンテナ ランタイム: クラスタで使用できるコンテナ ランタイムは containerd のみです。

7. [次へ] をクリックして [ネットワーキング] セクションに移動します。

ネットワーキング

このセクションでは、クラスタのノード、Pod、Service の IP アドレスを指定します。Metal LB によるバンドルされたロード バランシングを使用している場合は、それも構成します。

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

   必要に応じて [+ IP アドレスを追加] をクリックし、さらに IP アドレスを追加します。

2. [ロードバランサ] セクションで、[モード] リストからロードバランサを選択して、クラスタに設定します。詳細については、ロードバランサの概要をご覧ください。

   MetalLB にバンドル済み

   バンドル型 MetalLB ロードバランサを使用してロード バランシングを構成します。このオプションにより、Google Distributed Cloud は、ワーカーノードの専用プールまたはコントロール プレーンと同じノードで実行されるレイヤ 4 ロードバランサをデプロイします。

   1. [ロードバランサ ノードプール] セクションで、次のいずれかを選択します。

      • コントロール プレーン ノードを使用する: このオプションを選択すると、コントロール プレーンと同じノードでロードバランサを実行できます。

      • ロードバランサ ノードプールを作成する: ワーカーノードの専用プールでロードバランサを実行する必要がある場合は、この詳細オプションを選択します。ロードバランサ ノードプール内のすべてのノードは、ロードバランサのアドレスプール セクションに構成するロードバランサの仮想 IP（VIP）と同じレイヤ 2 サブネット内に存在する必要があります。

        1. [ロードバランサ ノードプールの IP 1] フィールドに、ロードバランサ ノードプール内のノード用の IPv4 アドレスを入力します。

        2. 必要に応じて [+ IP アドレスを追加] をクリックし、さらに IP アドレスを追加します。

   2. [ロードバランサのアドレスプール] セクションで、選択肢とする MetaLB コントローラ用の 1 つ以上のアドレスプールを追加して、LoadBalancer タイプの Service に割り当てます。仮想 IP セクションで指定する Ingress VIP は、これらのプールのいずれかに存在する必要があります。

      1. [名前] に、アドレスプールの名前を入力します。

      2. IP アドレス範囲を CIDR 表記（例: 192.0.2.0/26）または範囲表記（例: 192.0.2.64-192.0.2.72）で入力します。プール内の IP アドレスを 1 つ指定するには、CIDR 表記で /32 を使用します（例: 192.0.2.1/32）。

      3. Ingress VIP がアドレス範囲にない場合は、[+ IP アドレス範囲を追加] を選択し、Ingress VIP を含む別のアドレス範囲を入力します。

         各プール内での IP アドレスは重複してはならず、かつクラスタノードと同じサブネット内に存在する必要があります。

      4. [IP アドレスの割り当て] で、次のいずれかを選択します。

         • 自動: MetalLB コントローラでアドレスプールから IP アドレスを LoadBalancer タイプのサービスに自動的に割り振るには、このオプションを選択します。
         • 手動: プール内のアドレスを LoadBalancer タイプの Service に手動で指定する場合は、このオプションを選択します。

      5. 末尾が .0 または .255 のプールのアドレスを MetalLB コントローラで使用しないようにするには、[バグのある IP アドレスを避ける] をクリックします。これにより、バグの多いコンシューマ デバイスが、これらの特別な IP アドレスに送信されたトラフィックを誤って破棄するという問題を回避できます。

      6. 設定を終えたら、[完了] をクリックします。

      7. 必要に応じて、[アドレスプールを追加する] をクリックします。

   手動ロードバランサ

   手動ロード バランシングでは、コントロール プレーンとデータプレーンのトラフィックを対象とした独自のロード バランシング ソリューションを構成します。クラスタを作成する前に、外部ロードバランサでコントロール プレーン VIP を構成する必要があります。コントロール プレーンの外部ロードバランサはデータプレーンのトラフィックにも使用できます。また、データプレーン用に別のロードバランサを設定することもできます。詳細については、手動のロード バランシングを構成するをご覧ください。

3. [仮想 IP] セクションで、以下を入力します。

   • コントロール プレーン VIP: ユーザー クラスタの Kubernetes API サーバーに送信されるトラフィックに使用する宛先 IP アドレス。コントロール プレーンの VIP は、ロードバランサ ノードと同じサブネット内に存在する必要があり、ロードバランサのアドレスプールに使用されるアドレス範囲に含めることはできません。

   • ポート: Kubernetes API サーバーに送信されるトラフィックに使用される宛先ポート。デフォルト値は 443 です。

   • Ingress VIP: Ingress プロキシ用のロードバランサに構成する IP アドレス。ロードバランサのアドレスプールのいずれかに由来するアドレスを入力します

4. [Service と Pod CIDR] セクションで、Kubernetes Service と Pod の IP アドレス範囲を CIDR 表記で指定します。これらを互いに重複させたり、クラスタ内部からアクセスするクラスタ外のアドレスと重複させたりすることはできません。RFC 1918 で定義されているプライベート IP アドレス範囲を使用することをおすすめします。コンソールにはデフォルトのアドレス範囲が用意されていますが、変更できます。

   • サービス CIDR: 10.96.0.0/20デフォルトをそのまま使用しない場合は、/24 から /12 までの CIDR 範囲を入力します（/12 の場合に IP アドレスが最多になります）。

   • Pod CIDR: 192.168.0.0/16: デフォルトをそのまま使用しない場合は、/18 から /8 までの CIDR 範囲を入力します（/8 の場合に IP アドレスが最多になります）。

5. [詳細属性] セクションで、必要に応じて次のように指定します。

   • プロキシの URL: プロキシ サーバーの HTTP アドレス。スキームのデフォルト ポートと同じ場合でも、ポート番号を含めます（例: http://my-proxy.example.local:80）。

   • URLs: プロキシ サーバーを経由しない IP アドレス、IP アドレス範囲、ホスト名、ドメイン名のカンマ区切りのリスト。Google Distributed Cloud がこれらのアドレス、ホスト、ドメインのいずれかにリクエストを送信する場合、そのリクエストは直接送信されます。

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

ストレージ

Google Distributed Cloud ソフトウェアのみには、ブロック ストレージとファイル ストレージのインターフェースが用意されています。デフォルトのオプションがありますが、構成をカスタマイズすることもできます。詳細については、ローカル ストレージの構成をご覧ください。

1. 必要に応じて、次のものを構成できます。

   • ローカル ボリューム プロビジョナーのノードマウント: マウントされたディスクを基盤とするローカル PersistentVolumes（PV）の構成を指定します。これらのディスクは、クラスタの作成前または作成後にフォーマットしてマウントする必要があります。

   • ローカル ボリューム プロビジョナーの共有: 共有ファイル システムのサブディレクトリで使用するローカル PersistentVolumes の構成を指定します。これらのサブディレクトリは、クラスタの作成時に自動的に作成されます。

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

機能

クラスタのモニタリング、トラブルシューティング、運用に役立つよう、以下は自動的に有効になり、無効にすることはできません。

• システム サービスの Cloud Logging
• システム サービスの Cloud Monitoring
• 管理アクティビティ監査ログ

コンソールでノードプールを作成する

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

コンソールで、少なくとも 1 つのノードプールを構成するか（またはデフォルト値をそのまま使用）、クラスタを作成します。クラスタの作成後に、ノードプールを追加できます。gcloud CLI では、まずクラスタを作成してから、新しく作成したクラスタに 1 つ以上のノードプールを追加します。

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

2. [ノードプールのデフォルト] セクションで、ノードプール名を入力するか、「default-pool」を名前としてそのまま使用します。

3. [ワーカーノード] セクションで、クラスタが実行されるマシンの IP アドレスを入力します。

4. [ノードプールのメタデータ（省略可） セクションで、Kubernetes ラベルおよび taint を追加する場合、次の操作を行います。

   1. [+ Add Kubernetes Labels] をクリックします。ラベルの [キー] と [値] を入力します。以上の手順を必要なだけ繰り返してください。
   2. [+ taint を追加] をクリックします。taint の [キー]、[値]、[効果] を入力します。以上の手順を必要なだけ繰り返してください。

5. [Verify and Complete] をクリックしてユーザー クラスタを作成します。ユーザー クラスタの作成には 15 分以上かかります。コンソールで設定を確認し、データセンターにクラスタを作成するときに、ステータス メッセージが表示されます。

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

gcloud CLI

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

gcloud container bare-metal clusters create

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

gcloud container bare-metal node-pools create

クラスタとノードプールを作成するフラグのほとんどは、ユーザー クラスタ構成ファイルのフィールドに対応しています。 すぐに始められるように、例セクションで完全なコマンドをテストできます。フラグの詳細については、例に従うセクション、または gcloud CLI リファレンスをご覧ください。

始める前に

ユーザー クラスタの作成時に選択するバージョンは、管理クラスタがサポートするバージョンである必要があります。さらに、最新のマイナー バージョンまたはパッチ バージョンは、リリースから 7 ～ 14 日後まで GKE On-Prem API では使用できません。gcloud コマンドを実行して、インストールできるサポート対象のクラスタ バージョンのリストを取得できます。

1. コンポーネントを必ず更新します。

   gcloud components update
   

2. 管理クラスタの名前とフリート メンバーシップのロケーションを取得します。

   gcloud container fleet memberships list \
     --project=FLEET_HOST_PROJECT_ID
   

   FLEET_HOST_PROJECT_ID は、管理クラスタが登録されているプロジェクトの ID に置き換えます。

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

   NAME             EXTERNAL_ID                           LOCATION
   admin-cluster-1  bb7803b4-8438-4b22-859f-4559b4b29072  global
   admin-cluster-2  ee16ee2b-6ec0-49fc-9413-3c89cbc70854  global
   admin-cluster-3  fc2b7ef5-39ff-4b63-b919-04c5adc67be4  us-west1
   

   ロケーションには、フリート サービスと接続サービスが実行されるロケーションを指定します。1.28 より前に作成された管理クラスタは、グローバルの Fleet と Connect サービスによって管理されます。1.28 以降では、管理クラスタの作成時に global と Google Cloud リージョンのいずれかを指定できます。続くコマンドの例では、--admin-cluster-membership-location フラグにリージョンを指定します。

3. ユーザー クラスタにインストールする利用可能なバージョンのリストを取得します。

   gcloud container bare-metal clusters query-version-config \
     --admin-cluster-membership=ADMIN_CLUSTER_NAME \
     --admin-cluster-membership-project=FLEET_HOST_PROJECT_ID \
     --admin-cluster-membership-location=ADMIN_CLUSTER_REGION \
     --location=REGION
   

   以下を置き換えます。

   • ADMIN_CLUSTER_NAME: 管理クラスタの名前。

   • FLEET_HOST_PROJECT_ID: 管理クラスタが登録されているプロジェクトの ID。

   • ADMIN_CLUSTER_REGION: 管理クラスタのフリート メンバーシップ リージョン。これは、グローバルまたは Google Cloud リージョンのいずれかです。gcloud container fleet memberships list の出力にある管理クラスタのロケーションを使用します。

   • REGION: クラスタの作成時に使用する Google Cloud リージョン。これが GKE On-Prem API とフリート サービスと Connect サービスが実行されるリージョンです。us-west1 または別のサポートされているリージョンを指定します。

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

   versions:
   - version: 1.16.2
   - version: 1.16.1
   - version: 1.16.0
   - version: 1.15.7
   - version: 1.15.6
   - version: 1.15.5
   

最新のバグの修正と改善点を適用するため、サポートされている最も高いバージョンを使用することをおすすめします。

例

このセクションでは、MetalLB ロードバランサを使用してクラスタを作成するコマンドの例と、手動ロードバランサを使用する例を示します。指定する情報は、使用するロードバランサのタイプによって異なります。詳細については、ロードバランサの概要をご覧ください。

これらの例では、ノードプールのないクラスタを作成します。クラスタの稼働後、ワークロードをデプロイする前にノードプールを追加する必要があります。

gcloud container bare-metal clusters create USER_CLUSTER_NAME \
  --project=FLEET_HOST_PROJECT_ID \
  --admin-cluster-membership=ADMIN_CLUSTER_NAME \
  --admin-cluster-membership-project=FLEET_HOST_PROJECT_ID \
  --admin-cluster-membership-location=ADMIN_CLUSTER_REGION \
  --location=REGION \
  --version=VERSION \
  --admin-users=YOUR_EMAIL_ADDRESS \
  --admin-users=ANOTHER_EMAIL_ADDRESS \
  --metal-lb-address-pools='pool=NAME,avoid-buggy-ips=True|False,manual-assign=True|False,addresses=IP_ADDRESS_RANGE_1;IP_ADDRESS_RANGE_2;...' \
  --control-plane-node-configs='node-ip=CP_IP_ADDRESS_1,labels=CP_KEY_1.1=CP_VALUE_1.1;CP_KEY_1.2=CP_VALUE_1.2;...' \
  --control-plane-vip=CONTROL_PLANE_VIP \
  --control-plane-load-balancer-port=CONTROL_PLANE_LB_PORT \
  --ingress-vip=INGRESS_VIP \
  --island-mode-service-address-cidr-blocks=SERVICE_CIDR_BLOCK \
  --island-mode-pod-address-cidr-blocks=POD_CIDR_BLOCK \
  --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

'pool=NAME,avoid-buggy-ips=True|False,manual-assign=True|False,addresses=IP_ADDRESS_RANGE_1;IP_ADDRESS_RANGE_2;...' \

--metal-lb-address-pools='pool=pool1,avoid-buggy-ips=False,manual-assign=True,addresses=192.0.2.0/26;192.0.2.64-192.0.2.72'
--metal-lb-address-pools='pool=pool2,avoid-buggy-ips=True,manual-assign=True,addresses=10.251.133.0/24;10.251.134.80/32'

gcloud container bare-metal clusters create USER_CLUSTER_NAME \
  --project=FLEET_HOST_PROJECT_ID \
  --admin-cluster-membership=ADMIN_CLUSTER_NAME \
  --admin-cluster-membership-project=FLEET_HOST_PROJECT_ID \
  --admin-cluster-membership-location=ADMIN_CLUSTER_REGION \
  --location=REGION \
  --version=VERSION \
  --admin-users=YOUR_EMAIL_ADDRESS \
  --admin-users=ANOTHER_EMAIL_ADDRESS \
  --enable-manual-lb \
  --control-plane-node-configs='node-ip=CP_IP_ADDRESS_1,labels=CP_KEY_1.1=CP_VALUE_1.1;CP_KEY_1.2=CP_VALUE_1.2;...' \
  --control-plane-vip=CONTROL_PLANE_VIP \
  --control-plane-load-balancer-port=CONTROL_PLANE_LB_PORT \
  --ingress-vip=INGRESS_VIP \
  --island-mode-service-address-cidr-blocks=SERVICE_CIDR_BLOCK \
  --island-mode-pod-address-cidr-blocks=POD_CIDR_BLOCK \
  --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

gcloud コマンドを実行してクラスタを作成する前に、--validate-only を含めることで gcloud コマンドのフラグで指定された構成を検証できます。クラスタを作成する準備ができたら、このフラグを削除してコマンドを実行します。

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

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

ユーザー クラスタの作成には 15 分以上かかります。Google Cloud コンソールの [GKE クラスタ] ページでクラスタを表示できます。

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

ノードプールを作成

クラスタを作成したら、ワークロードをデプロイする前に少なくとも 1 つのノードプールを作成する必要があります。ノードプールは、このクラスタで作成されるワーカーノードのグループのテンプレートです。gcloud CLI では、まずクラスタを作成してから、新しく作成したクラスタに 1 つ以上のノードプールを追加します。

gcloud container bare-metal node-pools create NODE_POOL_NAME \
  --cluster=USER_CLUSTER_NAME \
  --project=FLEET_HOST_PROJECT_ID \
  --location=REGION \
  --node-configs='node-ip=NP_IP_ADDRESS_1,labels=NP_KEY_1.1=NP_VALUE_1.1;NP_KEY_1.2=NP_VALUE_1.2;...'

以下を置き換えます。

• NODE_POOL_NAME: ノードプールに付ける名前。名前は次の条件を満たしている必要があります。

  • 最大文字数は 40 文字とする
  • 小文字の英数字またはハイフン（-）のみを使用している
  • 先頭が英字である
  • 末尾が英数字である

• USER_CLUSTER_NAME: 新しく作成されたユーザー クラスタの名前。

• FLEET_HOST_PROJECT_ID: 管理クラスタが登録されているプロジェクトの ID。

• REGION: クラスタの作成時に指定した Google Cloud リージョン。

• --node-configs: ワーカーノード マシンの IPv4 アドレス。ノードごとにこのフラグを指定します。フラグの値の形式は次のとおりです。

  'node-ip=NP_IP_ADDRESS_1,labels=NP_KEY_1.1=NP_VALUE_1.1;NP_KEY_1.2=NP_VALUE_1.2;...' \
  

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

  • node-ip: ワーカーノードの IP アドレス。フラグごとに 1 つの node-ip しか指定できません。ノードプールの各ノードに対して、このフラグを再度追加します。

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

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

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

  必要に応じて、次を指定できます。

  • --node-labels=KEY=VALUE,...: プール内の各ノードに適用される Kubernetes ラベル（Key-Value ペア）のカンマ区切りのリスト。

  • --node-taints=KEY=VALUE:EFFECT,...プール内の各ノードに適用される Kubernetes taint のカンマ区切りのリスト。taint は、1 つの効果に関連付けられた Key-Value ペアです。taint は、Pod のスケジューリングの toleration で使用されます。EFFECT には 次の NoSchedule、PreferNoSchedule、NoExecute のいずれかを指定します。

次の例では、user-cluster- に default-pool というノードプールを作成し、そのノードプールに 2 つのノードを追加しています。両方のノードに node-pool-key=node-pool-value というラベルが付けられ、taint dedicated=experimental:PreferNoSchedule が設定されています。

gcloud container bare-metal node-pools create default-pool \
  --cluster=user-cluster-1  \
  --project=example-project-12345 \
  --location=us-west1 \
  --node-configs='node-ip=10.200.0.10' \
  --node-configs='node-ip=10.200.0.11,labels=key2.1=value2.1' \
  --node-labels=node-pool-key=node-pool-value \
  --node-taints=dedicated=experimental:PreferNoSchedule

詳細については、gcloud CLI リファレンスをご覧ください。

Terraform

始める前に

ユーザー クラスタの作成時に選択するベアメタル上の Google Distributed Cloud（ソフトウェアのみ）のバージョンは、管理クラスタがサポートするバージョンである必要があります。さらに、最新のマイナー バージョンまたはパッチ バージョンは、リリースから 7 ～ 14 日後まで GKE On-Prem API では使用できません。gcloud コマンドを実行して、ユーザー クラスタのインストールに使用できるサポート対象バージョンのリストを取得できます。

1. コンポーネントを必ず更新します。

   gcloud components update
   

2. 管理クラスタの名前とフリート メンバーシップのロケーションを取得します。

   gcloud container fleet memberships list \
     --project=FLEET_HOST_PROJECT_ID
   

   FLEET_HOST_PROJECT_ID は、管理クラスタが登録されているプロジェクトの ID に置き換えます。

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

   NAME             EXTERNAL_ID                           LOCATION
   admin-cluster-1  bb7803b4-8438-4b22-859f-4559b4b29072  global
   admin-cluster-2  ee16ee2b-6ec0-49fc-9413-3c89cbc70854  global
   admin-cluster-3  fc2b7ef5-39ff-4b63-b919-04c5adc67be4  us-west1
   

   ロケーションには、フリート サービスと接続サービスが実行されるロケーションを指定します。1.28 より前に作成された管理クラスタは、グローバルの Fleet と Connect サービスによって管理されます。1.28 以降では、管理クラスタの作成時に global と Google Cloud リージョンのいずれかを指定できます。続くコマンドの例では、--admin-cluster-membership-location フラグにリージョンを指定します。

3. ユーザー クラスタにインストールする利用可能なバージョンのリストを取得します。

   gcloud container bare-metal clusters query-version-config \
     --admin-cluster-membership=ADMIN_CLUSTER_NAME \
     --admin-cluster-membership-project=FLEET_HOST_PROJECT_ID \
     --admin-cluster-membership-location=ADMIN_CLUSTER_REGION \
     --location=REGION
   

   以下を置き換えます。

   • ADMIN_CLUSTER_NAME: 管理クラスタの名前。

   • FLEET_HOST_PROJECT_ID: 管理クラスタが登録されているプロジェクトの ID。

   • ADMIN_CLUSTER_REGION: 管理クラスタのフリート メンバーシップ リージョン。これは、グローバルまたは Google Cloud リージョンのいずれかです。gcloud container fleet memberships list の出力にある管理クラスタのロケーションを使用します。

   • REGION: クラスタの作成時に使用する Google Cloud リージョン。これが GKE On-Prem API とフリート サービスと Connect サービスが実行されるリージョンです。us-west1 または別のサポートされているリージョンを指定します。

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

   versions:
   - version: 1.16.2
   - version: 1.16.1
   - version: 1.16.0
   - version: 1.15.7
   - version: 1.15.6
   - version: 1.15.5
   

最新のバグの修正と改善点を適用するため、サポートされている最も高いバージョンを使用することをおすすめします。

例

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

変数を terraform.tfvars に設定する

このサンプルでは、main.tf に渡す変数ファイルの例により、バンドルされた MetalLB ロードバランサを構成する方法を示します。

1. anthos-samples リポジトリのクローンを作成し、Terraform サンプルがあるディレクトリに変更します。

   git clone https://github.com/GoogleCloudPlatform/anthos-samples
   cd anthos-samples/anthos-onprem-terraform/abm_user_cluster_metallb
   

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

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

   cp terraform.tfvars.sample terraform.tfvars
   

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

   
   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"] }
   ]
   

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

   • project_id: クラスタを作成するプロジェクトの ID。指定したプロジェクトは、フリート ホスト プロジェクトとしても使用されます。これは、管理クラスタが登録されているプロジェクトと同じでなければなりません。ユーザー クラスタを作成すると、選択したプロジェクトのフリートに自動的に登録されます。フリートホスト プロジェクトは、クラスタの作成後は変更できません。

   • region: GKE On-Prem API（gkeonprem.googleapis.com）、フリート サービス（gkehub.googleapis.com）、Connect サービス（gkeconnect.googleapis.com）が実行される Google Cloud リージョン。us-west1 または別のサポートされているリージョンを指定します。

   • admin_cluster_name: ユーザー クラスタを管理する管理クラスタの名前。この例では、管理クラスタがリージョンとして global を使用することを前提としています。リージョン管理クラスタがある場合:

     1. テキスト エディタで main.tf を開きます。

     2. 次のように admin_cluster_membership を検索します。

        admin_cluster_membership = "projects/${var.project_id}/locations/global/memberships/${var.admin_cluster_name}"

     3. global を管理クラスタが使用するリージョンに変更して、ファイルを保存します。

   • bare_metal_version: ユーザー クラスタの Google Distributed Cloud のバージョン。管理クラスタと同じバージョン、または管理クラスタより 1 つ低いマイナー バージョン以下のバージョンを指定します。

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

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

   • cluster_name: ユーザー クラスタの任意の名前。この名前はクラスタの作成後は変更できません。名前は次の条件を満たしている必要があります。

     • 最大文字数は 40 文字とする
     • 小文字の英数字またはハイフン（-）のみを使用している
     • 先頭が英字である
     • 末尾が英数字である

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

   • worker_node_ips: ワーカーノード マシンの 1 つ以上の IPv4 アドレスのリスト。

   • control_plane_vip: ユーザー クラスタの Kubernetes API サーバー用のロードバランサ上に構成するために選択した仮想 IP アドレス（VIP）。

   • ingress_vip: Ingress プロキシ用のロードバランサ上に構成するために選択した IP アドレス。

   • lb_address_pools: MetallLB ロードバランサのアドレスプールを定義するマップのリスト。Ingress VIP をプールの 1 つに含める必要があります。

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

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

   terraform init
   

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

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

   terraform plan
   

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

   terraform apply
   

   ユーザー クラスタの作成には 15 分以上かかります。Google Cloud コンソールの [GKE クラスタ] ページでクラスタを表示できます。

Connect Gateway

1. フリートホスト プロジェクトで使用する gcloud CLI を初期化するか、次のコマンドを実行して Google アカウントでログインし、フリートホスト プロジェクトをデフォルトに設定して、コンポーネントを更新します。

   gcloud auth login
   gcloud config set project PROJECT_ID
   gcloud components update
   

2. Connect ゲートウェイとのやり取りに使用するクラスタ認証情報を取得します。次のコマンドでは、MEMBERSHIP_NAME をクラスタの名前に置き換えます。ベアメタル上の Google Distributed Cloud（ソフトウェアのみ）の場合、メンバーシップ名はクラスタ名と同じです。

   gcloud container fleet memberships get-credentials MEMBERSHIP_NAME
   

   このコマンドは、特別な Connect Gateway 固有の kubeconfig を返します。これにより、Gateway を介してクラスタに接続できます。

必要な認証情報を取得したら、通常の Kubernetes クラスタの場合と同様に kubectl を使用してコマンドを実行できます。kubeconfig ファイルの名前を指定する必要はありません。次に例を示します。

kubectl get namespaces

管理ワークステーション

bmctl get credentials コマンドを使用して、新しく作成されたユーザー クラスタの kubeconfig ファイルを取得します。

bmctl get credentials --cluster CLUSTER_NAME --admin-kubeconfig ADMIN_KUBECONFIG_PATH

以下を置き換えます。

• CLUSTER_NAME: 対象とするユーザー クラスタの名前。

• ADMIN_KUBECONFIG_PATH: 管理クラスタの kubeconfig ファイルのパス。

ユーザー クラスタの認証情報を含む kubeconfig がファイル bmctl-workspace/CLUSTER_NAME/CLUSTER_NAME-TIMESTAMP-kubeconfig に書き込まれます。ファイル名の TIMESTAMP は、ファイルが作成された日時を示します。

このファイルにはクラスタの認証情報が含まれているため、アクセスが制限された安全なロケーションに保存する必要があります。