Version 1.16. This version is no longer supported. For information about how to upgrade to version 1.28, see Upgrade clusters in the latest documentation. For more information about supported and unsupported versions, see the Versioning page in the latest documentation.

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

このページでは、Google Cloud コンソール、Google Cloud CLI（gcloud CLI）、または Terraform を使用してユーザークラスタを作成する方法について説明します。

GKE On-Prem API とは

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

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

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

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

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

準備

このセクションでは、GKE On-Prem API クライアントを使用してユーザークラスタを作成するための要件について説明します。

IAM 権限を付与

プロジェクトオーナーでない場合は、roles/gkeonprem.admin が付与されている必要があります。

コンソールで Google Kubernetes Engine（GKE）Enterprise エディションと Google Kubernetes Engine のページにアクセスするには、次のロールも付与されている必要があります。

クラスター作成後、プロジェクトオーナーでなく、Connect ゲートウェイを使用してコマンドラインでユーザークラスターに接続する場合は、以下のロールが必要です。

roles/gkehub.gatewayAdmin: このロールを使用すると、Connect Gateway API にアクセスできます。クラスタへの読み取り専用権限のみが必要な場合は、roles/gkehub.gatewayReader で十分です。
roles/gkehub.viewer: このロールでは、クラスタの認証情報を取得できます。

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

必要な Google API

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

gcloud CLI を使用してクラスタを作成する場合は、GKE On-Prem API を有効にする必要があります。コンソールを使用してクラスタを作成すると、GKE On-Prem API は自動で有効になります。

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

管理クラスタの前提条件

ユーザークラスタを作成するには、動作している管理クラスタが必要です。管理クラスタは次の条件を満たす必要があります。

ユーザークラスタの作成後に、Kubernetes API サーバーにアクセスできる。
ユーザークラスタの作成後、ユーザークラスタのすべてのノードに接続できる。
フリートに登録する必要がある。管理クラスタの gkeConnect.projectID フィールドで構成されているプロジェクト ID（フリートホストプロジェクトと呼ばれます）は、ユーザークラスタを作成するプロジェクトと同じである必要があります。

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

クラスタノードマシンの前提条件を確認して、ユーザークラスタを実行するマシンが前提条件を満たしていることを確認します。

コマンドラインアクセス

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

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

ユーザークラスタの作成

GKE On-Prem API で管理されるクラスタは、Terraform、Google Cloud コンソール、または Google Cloud CLI（gcloud CLI）を使用して作成できます。GKE on Bare Metal を初めてインストールする場合は、コンソールが最も使用しやすいツールです。

クラスタを作成する際に入力する必要がある情報に慣れてきたら、複数のクラスタを作成する場合は、Terraform または gcloud CLI の方が便利になるかもしれません。Terraform は、業界標準の Infrastructure as Code（IAC）ツールです。組織ですでに Terraform を使用している場合は、クラスタの作成およびクラスタライフサイクルの管理に Terraform を使用するでしょう。

gcloud CLI を使用すると、コマンドを引数とともにテキストファイルに保存し、必要に応じて追加のクラスタを作成できます。Cloud Build などの CI / CD ツールを使用している場合は、gcloud コマンドを使用してクラスタを作成し、--impersonate-service-account フラグを指定して作成を自動化できます。

コンソール

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

コンソールで、[GKE on Bare Metal クラスタの作成] ページに移動します。

[GKE on Bare Metal クラスタの作成] に移動
クラスタを作成する Google Cloud プロジェクトを選択します。選択したプロジェクトは、フリートホストプロジェクトとしても使用されます。これは、管理クラスタが登録されているプロジェクトと同じでなければなりません。ユーザークラスタを作成すると、選択したプロジェクトのフリートに自動的に登録されます。
[次へ] をクリックしてクラスタの構成を開始します。

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

クラスタの基本

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

ユーザークラスタの名前を入力します。
[管理クラスタ] で、リストから管理クラスタを選択します。
[Google Cloud API のロケーション] フィールドで、リストから Google Cloud リージョンを選択します。この設定では、GKE On-Prem API が実行されるリージョンと、以下のデータが保存されるリージョンを指定します。
- クラスタのライフサイクルを管理する際に GKE On-Prem API が必要とするユーザークラスタメタデータ
- システムコンポーネントの Cloud Logging データと Cloud Monitoring データ
- Cloud Audit Logs によって作成された管理監査ログ
クラスタ名、プロジェクト、ロケーションにより、Google Cloud でクラスタが一意に識別されます。
ユーザークラスタの GKE on Bare Metal のバージョンを選択します。ユーザークラスタは、管理クラスタと同じマイナーバージョンか、管理クラスタより 1 つ低いマイナーバージョンである必要があります。
クラスタ作成者には、クラスタに対するクラスタ管理者権限が付与されます。必要に応じて、[管理者ユーザー] フィールドに、クラスタを管理する別のユーザーのメールアドレスを入力します。

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

注: プロジェクトオーナー以外のユーザーには、Kubernetes RBAC ポリシーに加え、いくつかの Identity and Access Management（IAM）ロールを付与する必要があります。IAM ロールを付与する方法について詳しくは、必要なロールを付与するをご覧ください。
[ノード構成] セクションで、以下を指定します。
- ノードあたりの最大 Pod 数: 単一ノードで実行できる Pod の最大数を入力します。使用できる値は、32 ～ 250 です。Kubernetes は、各 Pod に一意の IP アドレスが指定されるように、クラスレスドメイン間ルーティング（CIDR）ブロックを各ノードに割り当てます。CIDR ブロックのサイズは、1 ノードあたりの最大 Pod 数と対応します。ノードあたりの最大ポッド数の設定の詳細については、ポッドネットワーキングをご覧ください。
- コンテナランタイム: containerd は、クラスタで使用できる唯一のコンテナランタイムです。
[次へ] をクリックして [ネットワーキング] セクションに移動します。

ネットワーキング

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

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

必要に応じて [+ IP アドレスを追加] をクリックし、さらに IP アドレスを追加します。
[ロードバランサ] セクションで、[モード] リストからロードバランサを選択してクラスタに設定します。詳細については、ロードバランサの概要をご覧ください。
MetalLB にバンドル済み
バンドル型 MetalLB ロードバランサを使用してロードバランシングを構成します。このオプションにより、GKE on Bare Metal は、ワーカーノードの専用プールまたはコントロールプレーンと同じノードで実行されるレイヤ 4 ロードバランサをデプロイします。
1. [ロードバランサノードプール] セクションで、次のいずれかを選択します。
  - コントロールプレーンノードを使用する: コントロールプレーンと同じノードでロードバランサを実行するには、このオプションを選択します。
  - ロードバランサノードプールを作成する: ワーカーノードの専用プールでロードバランサを実行する必要がある場合は、この詳細オプションを選択します。ロードバランサノードプール内のすべてのノードは、ロードバランサのアドレスプール セクションに構成するロードバランサの仮想 IP（VIP）と同じレイヤ 2 サブネット内に存在する必要があります。
    
    [ロードバランサノードプールの IP 1] フィールドに、ロードバランサノードプール内のノード用の IPv4 アドレスを入力します。
    
    必要に応じて [+ 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 を構成する必要があります。コントロールプレーンの外部ロードバランサはデータプレーンのトラフィックにも使用できます。また、データプレーン用に別のロードバランサを設定することもできます。詳細については、手動のロードバランシングを構成するをご覧ください。
[仮想 IP] セクションで、以下を入力します。
- コントロールプレーン VIP: ユーザークラスタの Kubernetes API サーバーに送信されるトラフィックに使用される宛先 IP アドレス。コントロールプレーンの VIP は、ロードバランサノードと同じサブネット内に存在する必要があり、ロードバランサのアドレスプールに使用されるアドレス範囲に含めることはできません。
- ポート: Kubernetes API サーバーに送信されるトラフィックに使用される宛先ポート。デフォルト値は 443 です。
- Ingress VIP: Ingress プロキシ用のロードバランサに構成する IP アドレス。ロードバランサのアドレスプールのいずれかに由来するアドレスを入力します
[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 アドレスが最多になります）。
[詳細属性] セクションで、必要に応じて次のように指定します。
- プロキシ URL: プロキシサーバーの HTTP アドレス。スキームのデフォルトポートと同じ場合でも、ポート番号を含めます（例: http://my-proxy.example.local:80）。
- URLs: プロキシサーバーを経由しない IP アドレス、IP アドレス範囲、ホスト名、ドメイン名のカンマ区切りのリスト。GKE on Bare Metal がこれらのアドレス、ホスト、ドメインのいずれかにリクエストを送信する場合、そのリクエストは直接送信されます。
[次へ] をクリックします。

ストレージ

GKE on Bare Metal は、ブロックストレージとファイルストレージインターフェースを備えています。デフォルトのオプションがありますが、構成をカスタマイズすることもできます。詳細については、ローカルストレージの構成をご覧ください。

必要に応じて、次の構成を行うことができます。
- ローカルボリュームプロビジョナーのノードマウント: マウントされたディスクを基盤とするローカル PersistentVolumes（PV）の構成を指定します。これらのディスクは、クラスタの作成前または作成後にフォーマットしてマウントする必要があります。
- ローカルボリュームプロビジョナーの共有: 共有ファイルシステム内のサブディレクトリを基盤とするローカル PersistentVolumes の構成を指定します。これらのサブディレクトリは、クラスタの作成時に自動的に作成されます。
[次へ] をクリックします。

機能

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

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

ノードプールを作成

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

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

左側のナビゲーションバーで [デフォルトプール] をクリックします。
[ノードプールのデフォルト] セクションで、ノードプール名を入力するか、「default-pool」を名前としてそのまま使用します。
[ワーカーノード] セクションに、クラスタを実行するマシンの IP アドレスを入力します。
[ノードプールのメタデータ（省略可） セクションで、Kubernetes ラベルおよび taint を追加する場合、次の操作を行います。
1. [+ Add Kubernetes Labels] をクリックします。ラベルの [キー] と [値] を入力します。以上の手順を必要なだけ繰り返してください。
2. [+ taint を追加] をクリックします。taint の [キー]、[値]、[効果] を入力します。以上の手順を必要なだけ繰り返してください。
[Verify and Complete] をクリックしてユーザークラスタを作成します。ユーザークラスタの作成には 15 分以上かかります。コンソールで設定を確認し、データセンターにクラスタを作成するときに、ステータスメッセージが表示されます。

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

gcloud CLI

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

gcloud container bare-metal clusters create

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

gcloud container bare-metal node-pools create

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

準備

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

コンポーネントを必ず更新します。
```
gcloud components update
```
ユーザークラスタにインストールするバージョンのリストを取得します。
```
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=global \
  --location=REGION
```
以下を置き換えます。
- ADMIN_CLUSTER_NAME: 管理クラスタの名前。
- FLEET_HOST_PROJECT_ID: 管理クラスタが登録されているプロジェクトの ID。
- REGION: GKE On-Prem API にクラスタを登録したときに指定した Google Cloud リージョン。

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

例

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

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

MetalLB

--admin-cluster-membership フラグの ADMIN_CLUSTER_NAME プレースホルダを入力する必要がある場合は、必ずスクロールしてください。

gcloud container bare-metal clusters create USER_CLUSTER_NAME \
  --project=FLEET_HOST_PROJECT_ID \
  --admin-cluster-membership=projects/FLEET_HOST_PROJECT_ID/locations/global/memberships/ADMIN_CLUSTER_NAME \
  --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

以下を置き換えます。

USER_CLUSTER_NAME: ユーザークラスタの任意の名前。この名前はクラスタの作成後は変更できません。名前は次の条件を満たしている必要があります。
- 最大文字数は 40 文字とする
- 小文字の英数字またはハイフン（-）のみを使用している
- 先頭が英字である
- 末尾が英数字である
FLEET_HOST_PROJECT_ID: クラスタを作成するプロジェクトの ID。指定したプロジェクトは、フリートホストプロジェクトとしても使用されます。これは、管理クラスタが登録されているプロジェクトと同じでなければなりません。ユーザークラスタを作成すると、選択したプロジェクトのフリートに自動的に登録されます。フリートホストプロジェクトは、クラスタの作成後は変更できません。
ADMIN_CLUSTER_NAME: ユーザークラスタを管理する管理クラスタの名前。--admin-cluster-membership フラグには、次の形式での完全指定のクラスタ名を使用できます。
```
    projects/FLEET_HOST_PROJECT_ID/locations/ADMIN_CLUSTER_REGION/memberships/ADMIN_CLUSTER_NAME
```
あるいは、コマンドの例のように、--admin-cluster-membership を管理クラスタの名前に設定できます。管理クラスタの名前のみを使用する場合は、管理クラスタのプロジェクト ID を --admin-cluster-membership-project で設定し、ロケーションを --admin-cluster-membership-location で設定します。管理クラスタのロケーションは、global または Google Cloud リージョンのいずれかです。リージョンを確認する必要がある場合は、gcloud container fleet memberships list を実行します。
REGION: GKE On-Prem API（gkeonprem.googleapis.com）、フリートサービス（gkehub.googleapis.com）、Connect サービス（gkeconnect.googleapis.com）が実行される Google Cloud リージョン。us-west1 または別のサポートされているリージョンを指定します。リージョンはクラスタの作成後は変更できません。この設定では、以下のデータが保存されるリージョンを指定します。
- クラスタのライフサイクルを管理する際に GKE On-Prem API が必要とするユーザークラスタメタデータ
- システムコンポーネントの Cloud Logging データと Cloud Monitoring データ
- Cloud Audit Logs によって作成された管理監査ログ
クラスタ名、プロジェクト、ロケーションの組み合わせにより、Google Cloud でクラスタが一意に識別されます。

重要 Anthos Service Mesh をインストールする場合は、バージョン 1.19.3 以降をインストールする必要があります。Fleeet サービスと Connect サービスはリージョンで実行されるため、このようにする必要があります。
VERSION: ユーザークラスタの GKE on Bare Metal のバージョン。
YOUR_EMAIL_ADDRESS と ANOTHER_EMAIL_ADDRESS: クラスタ作成者として --admin-users フラグを含めない場合、デフォルトではクラスタ管理者権限が付与されます。しかし、--admin-users を使用して別のユーザーを管理者として指定する場合は、デフォルトをオーバーライドし、自分のメールアドレスと他の管理者のメールアドレスの両方を指定する必要があります。たとえば、2 人の管理者を追加するには、次のようにします。
```
    --admin-users=sara@example.com \
    --admin-users=amal@example.com
```
クラスタが作成されると、GKE On-Prem API によって Kubernetes のロールベースアクセス制御（RBAC）ポリシーがクラスタに適用され、クラスタの作成者と他の管理者ユーザーに Kubernetes の clusterrole/cluster-admin ロールが付与されます。このロールは、すべての名前空間で、クラスタのすべてのリソースに対する完全アクセス権を付与します。

注: プロジェクトオーナー以外のユーザーには、Kubernetes RBAC ポリシーに加え、いくつかの Identity and Access Management（IAM）ロールを付与する必要があります。IAM ロールを付与する方法について詳しくは、必要なロールを付与するをご覧ください。

MetalLB アドレスプール

--metal-lb-address-pools: MetalLB ロードバランサで使用するアドレスプールの構成を指定します。フラグの値の形式は次のとおりです。

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

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

pool: ノードプールに付ける名前。
avoid-buggy-ips: True に設定すると、MetalLB コントローラは .0 または .255 で終わる IP アドレスを Service に割り当てません。これにより、バグの多いコンシューマデバイスが、これらの特別な IP アドレスに送信されたトラフィックを誤って破棄するという問題を回避できます。指定しない場合、デフォルトで False になります。
manual-assign: MetalLB コントローラによってこのプールから Service に IP アドレスが自動的に割り当てられるようにしない場合は、True に設定します。次に、デベロッパーは、LoadBalancer タイプの Service を作成し、プールからアドレスのいずれか 1 つを手動で指定します。指定しない場合、manual-assign は False に設定されます。
addresses のリスト内: 各アドレスは CIDR 形式またはハイフン付きの範囲で指定する必要があります。プール内の単一の IP アドレス（Ingress VIP など）を指定するには、CIDR 表記の /32 を使用します（例: 192.0.2.1/32）。

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

値全体を単一引用符で囲みます。
空白文字は使用できません。
各 IP アドレス範囲をセミコロンで区切ります。

次の例に示すように、複数のフラグインスタンスを指定できます。

--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'

MetalLB ノード

省略可: --metal-lb-load-balancer-node-configs: ロードバランサはデフォルトで、コントロールプレーンと同じノードで実行されます。ワーカーノードの専用プールでロードバランサを実行する必要がある場合は、ノードごとにこのフラグを指定します。ロードバランサノードプール内のすべてのノードは、ロードバランサの仮想 IP（VIP）と同じレイヤ 2 サブネット内にある必要があります。

重要: 専用のロードバランサノードプールなしでクラスタを作成すると、後で追加することはできません。少なくとも 1 つのロードバランサノードを使用して構成されたクラスタでは、クラスタを更新してロードバランサノードプールにノードを追加できます。

フラグの値の形式は次のとおりです。
```
'node-ip=LB_IP_ADDRESS_1,labels=LB_KEY_1.1=LB_VALUE_1.1;LB_KEY_1.2=LB_VALUE_1.2;...' \
```
この値には、node-ip と labels というキーワードで始まるセグメントがあります。各セグメントをカンマで区切ります。
- node-ip: ロードバランサノードプール内のノードの IP アドレス。フラグごとに 1 つの node-ip しか指定できません。複数のノードを指定する必要がある場合は、ノードごとにフラグを指定し直してください。
- labels: ノードに付加される 1 つ以上の Key-Value ペア。
次の構文ルールに注意してください。
- 値全体を単一引用符で囲みます。
- 空白文字は使用できません。
- labels セグメントの各 Key-Value ペアはセミコロンで区切ります。
--metal-lb-load-balancer-node-configs を指定する場合は、必要に応じて次のフラグを指定できます。
- --metal-lb-load-balancer-node-labels: このフラグを使用して、ロードバランサノードプール内のすべてのノードにラベルを追加します。Key-Value ペアのリストをカンマで区切ります。
```
--metal-lb-load-balancer-node-labels=KEY_1=VALUE_1,KEY_2=VALUE_2
```
- --metal-lb-load-balancer-node-taints: このフラグを使用して、ロードバランサノードプール内のすべてのノードに taint を追加します。各 taint は、効果に関連付けられた Key-Value ペアです。PreferNoSchedule、NoSchedule、NoExecute のいずれかにする必要があります。
```
--metal-lb-load-balancer-node-taints=KEY_1=VALUE_1:EFFECT_1,KEY_2=VALUE_2:EFFECT_2
```
次の例では、3 つのノードをロードバランサノードプールに追加します。すべてのノードに lb-pool-key=lb-pool-value というラベルが付けられ、taint dedicated=experimental:PreferNoSchedule が設定されています。
```
--metal-lb-load-balancer-node-configs='node-ip=192.0.2.1' \
--metal-lb-load-balancer-node-configs='node-ip=192.0.2.2,labels=key2.1=value2.1' \
--metal-lb-load-balancer-node-configs='node-ip=192.0.2.3,labels=key3.1=value3.1;key3.2=value3.2' \
--metal-lb-load-balancer-node-labels=lb-pool-key=lb-pool-value \
--metal-lb-load-balancer-node-taints=dedicated=experimental:PreferNoSchedule \
```

コントロールプレーンノード

--control-plane-node-configs: コントロールプレーンノードの 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-labels: このフラグを使用して、すべてのコントロールプレーンノードにラベルを追加します。Key-Value ペアのリストはカンマで区切ります。
```
  --control-plane-node-labels=KEY_1=VALUE_1,KEY_2=VALUE_2
```
--control-plane-node-taints: このフラグを使用して、すべてのコントロールプレーンノードに taints を追加します。各 taint は、効果に関連付けられた Key-Value ペアです。PreferNoSchedule、NoSchedule、NoExecute のいずれかにする必要があります。
次の例では、3 つのノードをコントロールプレーンノードに追加します。すべてのノードに cp-node-pool-key=cp-node-pool-value というラベルが付けられ、taint dedicated=experimental:PreferNoSchedule が設定されています。
```
  --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-planer-node-configs='node-ip=192.0.2.3,labels=key3.1=value3.1;key3.2=value3.2' \
  --control-plane-node-labels=cp-node-pool-key=cp-node-pool-value \
  --control-plane-node-taints=dedicated=experimental:PreferNoSchedule \
```

仮想 IP

CONTROL_PLANE_VIP: ユーザークラスタの Kubernetes API サーバー用にロードバランサ上に構成することを選択した IP アドレス。
例: --control-plane-vip=203.0.113.3
CONTROL_PLANE_LB_PORT: ロードバランサが Kubernetes API サーバーに対応するポート。
例: -control-plane-load-balancer-port=443
INGRESS_VIP: Ingress プロキシのロードバランサを構成するために選択した IP アドレス。
例: --ingress-vip=10.251.134.80

Ingress VIP の IP アドレスが MetalLB アドレスプールのいずれかにある必要があります。

Service CIDR と Pod CIDR

SERVICE_CIDR_BLOCK: クラスタ内の Service に使用される IP アドレスの範囲（CIDR 形式）。CIDR 範囲は /24～/12 にする必要があります（/12 の場合に IP アドレスが最多になります）。
例: --island-mode-service-address-cidr-blocks=10.96.0.0/20
POD_CIDR_BLOCK: クラスタ内の Pod に使用される IP アドレスの範囲（CIDR 形式）。CIDR 範囲は /18～/8 にする必要があります（/8 の場合に IP アドレスが最多になります）。
例: --island-mode-pod-address-cidr-blocks=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 が作成されるストレージクラスです。

ストレージの詳細については、ローカルストレージの構成をご覧ください。

手動

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

--admin-cluster-membership フラグの ADMIN_CLUSTER_NAME プレースホルダを入力する必要がある場合は、必ずスクロールしてください。

gcloud container bare-metal clusters create USER_CLUSTER_NAME \
  --project=FLEET_HOST_PROJECT_ID \
  --admin-cluster-membership=projects/FLEET_HOST_PROJECT_ID/locations/global/memberships/ADMIN_CLUSTER_NAME \
  --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

以下を置き換えます。

USER_CLUSTER_NAME: ユーザークラスタの任意の名前。この名前はクラスタの作成後は変更できません。名前は次の条件を満たしている必要があります。
- 最大文字数は 40 文字とする
- 小文字の英数字またはハイフン（-）のみを使用している
- 先頭が英字である
- 末尾が英数字である
FLEET_HOST_PROJECT_ID: クラスタを作成するプロジェクトの ID。指定したプロジェクトは、フリートホストプロジェクトとしても使用されます。これは、管理クラスタが登録されているプロジェクトと同じでなければなりません。ユーザークラスタを作成すると、選択したプロジェクトのフリートに自動的に登録されます。フリートホストプロジェクトは、クラスタの作成後は変更できません。
ADMIN_CLUSTER_NAME: ユーザークラスタを管理する管理クラスタの名前。--admin-cluster-membership フラグには、次の形式での完全指定のクラスタ名を使用できます。
```
    projects/FLEET_HOST_PROJECT_ID/locations/ADMIN_CLUSTER_REGION/memberships/ADMIN_CLUSTER_NAME
```
あるいは、コマンドの例のように、--admin-cluster-membership を管理クラスタの名前に設定できます。管理クラスタの名前のみを使用する場合は、管理クラスタのプロジェクト ID を --admin-cluster-membership-project で設定し、ロケーションを --admin-cluster-membership-location で設定します。管理クラスタのロケーションは、global または Google Cloud リージョンのいずれかです。リージョンを確認する必要がある場合は、gcloud container fleet memberships list を実行します。
REGION: GKE On-Prem API（gkeonprem.googleapis.com）、フリートサービス（gkehub.googleapis.com）、Connect サービス（gkeconnect.googleapis.com）が実行される Google Cloud リージョン。us-west1 または別のサポートされているリージョンを指定します。リージョンはクラスタの作成後は変更できません。この設定では、以下のデータが保存されるリージョンを指定します。
- クラスタのライフサイクルを管理する際に GKE On-Prem API が必要とするユーザークラスタメタデータ
- システムコンポーネントの Cloud Logging データと Cloud Monitoring データ
- Cloud Audit Logs によって作成された管理監査ログ
クラスタ名、プロジェクト、ロケーションの組み合わせにより、Google Cloud でクラスタが一意に識別されます。

重要 Anthos Service Mesh をインストールする場合は、バージョン 1.19.3 以降をインストールする必要があります。Fleeet サービスと Connect サービスはリージョンで実行されるため、このようにする必要があります。
VERSION: ユーザークラスタの GKE on Bare Metal のバージョン。
YOUR_EMAIL_ADDRESS と ANOTHER_EMAIL_ADDRESS: クラスタ作成者として --admin-users フラグを含めない場合、デフォルトではクラスタ管理者権限が付与されます。しかし、--admin-users を使用して別のユーザーを管理者として指定する場合は、デフォルトをオーバーライドし、自分のメールアドレスと他の管理者のメールアドレスの両方を指定する必要があります。たとえば、2 人の管理者を追加するには、次のようにします。
```
    --admin-users=sara@example.com \
    --admin-users=amal@example.com
```
クラスタが作成されると、GKE On-Prem API によって Kubernetes のロールベースアクセス制御（RBAC）ポリシーがクラスタに適用され、クラスタの作成者と他の管理者ユーザーに Kubernetes の clusterrole/cluster-admin ロールが付与されます。このロールは、すべての名前空間で、クラスタのすべてのリソースに対する完全アクセス権を付与します。

注: プロジェクトオーナー以外のユーザーには、Kubernetes RBAC ポリシーに加え、いくつかの Identity and Access Management（IAM）ロールを付与する必要があります。IAM ロールを付与する方法について詳しくは、必要なロールを付与するをご覧ください。

コントロールプレーンノード

--control-plane-node-configs: コントロールプレーンノードの 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-labels: このフラグを使用して、すべてのコントロールプレーンノードにラベルを追加します。Key-Value ペアのリストはカンマで区切ります。
```
  --control-plane-node-labels=KEY_1=VALUE_1,KEY_2=VALUE_2
```
--control-plane-node-taints: このフラグを使用して、すべてのコントロールプレーンノードに taints を追加します。各 taint は、効果に関連付けられた Key-Value ペアです。PreferNoSchedule、NoSchedule、NoExecute のいずれかにする必要があります。
次の例では、3 つのノードをコントロールプレーンノードに追加します。すべてのノードに cp-node-pool-key=cp-node-pool-value というラベルが付けられ、taint dedicated=experimental:PreferNoSchedule が設定されています。
```
  --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-planer-node-configs='node-ip=192.0.2.3,labels=key3.1=value3.1;key3.2=value3.2' \
  --control-plane-node-labels=cp-node-pool-key=cp-node-pool-value \
  --control-plane-node-taints=dedicated=experimental:PreferNoSchedule \
```

仮想 IP

CONTROL_PLANE_VIP: ユーザークラスタの Kubernetes API サーバー用にロードバランサ上に構成することを選択した IP アドレス。
例: --control-plane-vip=203.0.113.3
CONTROL_PLANE_LB_PORT: ロードバランサが Kubernetes API サーバーに対応するポート。
例: -control-plane-load-balancer-port=443
INGRESS_VIP: Ingress プロキシのロードバランサを構成するために選択した IP アドレス。
例: --ingress-vip=10.251.134.80

Ingress VIP の IP アドレスが MetalLB アドレスプールのいずれかにある必要があります。

Service CIDR と Pod CIDR

SERVICE_CIDR_BLOCK: クラスタ内の Service に使用される IP アドレスの範囲（CIDR 形式）。CIDR 範囲は /24～/12 にする必要があります（/12 の場合に IP アドレスが最多になります）。
例: --island-mode-service-address-cidr-blocks=10.96.0.0/20
POD_CIDR_BLOCK: クラスタ内の Pod に使用される IP アドレスの範囲（CIDR 形式）。CIDR 範囲は /18～/8 にする必要があります（/8 の場合に IP アドレスが最多になります）。
例: --island-mode-pod-address-cidr-blocks=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 コマンドを実行してクラスタを作成する前に、--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

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

準備

コンポーネントを必ず更新します。
```
gcloud components update
```
ユーザークラスタにインストールするバージョンのリストを取得します。
```
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=global \
  --location=REGION
```
以下を置き換えます。
- ADMIN_CLUSTER_NAME: 管理クラスタの名前。
- FLEET_HOST_PROJECT_ID: 管理クラスタが登録されているプロジェクトの ID。
- REGION: GKE On-Prem API にクラスタを登録したときに指定した Google Cloud リージョン。

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

例

anthos-samples リポジトリのクローンを作成し、Terraform サンプルがあるディレクトリに変更します。
```
git clone https://github.com/GoogleCloudPlatform/anthos-samples
cd anthos-samples/anthos-onprem-terraform/abm_user_cluster_metallb
```
このサンプルには、main.tf に渡すサンプル変数が用意されています。

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

cp terraform.tfvars.sample 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"] }
]

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

変数は次のリストのとおりです。
- project_id: クラスタを作成するプロジェクトの ID。指定したプロジェクトは、フリートホストプロジェクトとしても使用されます。これは、管理クラスタが登録されているプロジェクトと同じでなければなりません。ユーザークラスタを作成すると、選択したプロジェクトのフリートに自動的に登録されます。フリートホストプロジェクトは、クラスタの作成後は変更できません。
- region: GKE On-Prem API が実行される Google Cloud リージョン。us-west1 または別のサポートされているリージョンを指定します。
- admin_cluster_name: ユーザークラスタを管理する管理クラスタの名前。
- bare_metal_version: ユーザークラスタの GKE on Bare Metal のバージョン。管理クラスタと同じバージョン、または管理クラスタより 1 つ低いマイナーバージョン以下のバージョンを指定します。
- 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: MetalLB ロードバランサで使用するアドレスプールを定義するマップのリスト。Ingress VIP をプールの 1 つに含める必要があります。
- admin_user_emails: クラスタに対する管理者権限を付与するユーザーのメールアドレスのリスト。自分でクラスタを管理する場合は、必ず自分のメールアドレスを追加してください。
クラスタが作成されると、GKE On-Prem API によって Kubernetes のロールベースアクセス制御（RBAC）ポリシーがクラスタに適用され、管理者ユーザーに Kubernetes の clusterrole/cluster-admin ロールが付与されます。このロールにより、すべての名前空間で、クラスタのすべてのリソースに対する完全アクセス権が付与されます。これにより、ユーザーは Google の ID を使用してコンソールにログインできます。
変更を terraform.tfvars に保存します。
Terraform プランを初期化して作成します。
```
terraform init
```
Terraform によって、Google Cloud プロバイダなどの必要なライブラリがインストールされます。
構成を確認し、必要に応じて変更を加えます。
```
terraform plan
```
Terraform プランを適用して、ユーザークラスタを作成します。
```
terraform apply
```
ユーザークラスタの作成には 15 分以上かかります。クラスタは、Google Cloud コンソールの [GKE クラスタ] ページで確認できます。

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

コンソールでユーザークラスタを作成すると、クラスタは Kubernetes のロールベースのアクセス制御（RBAC）ポリシーで構成され、Google Cloud ID を使用してクラスタにログインできます。gcloud CLI を使用してユーザークラスタを作成する場合、--admin-users フラグを含めないと、デフォルトでこれらの RBAC ポリシーが付与されます。--admin-users を使用して別のユーザーを管理者として指定する場合は、デフォルトをオーバーライドし、自分のメールアドレスと他の管理者のメールアドレスの両方を指定する必要があります。必要な IAM ポリシーと RBAC ポリシーの詳細については、Google ID 認証の設定をご覧ください。

すべてのクラスタには正規のエンドポイントがあります。このエンドポイントは、kubectl や他のサービスと TCP ポート 443 経由でクラスタコントロールプレーンと通信するために使用する Kubernetes API サーバーを公開します。このエンドポイントには、公共のインターネットからはアクセスできません。VPC を介してクラスタのプライベートエンドポイントにアクセスできる場合は、プライベートエンドポイントに直接接続して kubeconfig ファイルを直接生成できます。そうでない場合は、Connect Gateway を使用できます。

コマンドラインからユーザークラスタにアクセスするには、kubeconfig ファイルが必要です。kubeconfig ファイルを取得するには、2 つの方法があります。

Connect Gateway を使用して、Google Cloud CLI がインストールされているコンピュータからクラスタにアクセスします。この場合、kubectl は、Connect Gateway の kubeconfig を使用して、ユーザーの代わりにプライベートエンドポイントにトラフィックを安全に転送します。
プライベートエンドポイントに直接アクセスするために、管理ワークステーションで kubeconfig ファイルを作成し、管理ワークステーションからクラスタを管理します。

Google Cloud コンソールでユーザークラスタのステータスが正常と表示されるまで待ちます。

Connect ゲートウェイ

フリートホストプロジェクトで使用する gcloud CLI を初期化するか、次のコマンドを実行して Google アカウントでログインし、フリートホストプロジェクトをデフォルトに設定して、コンポーネントを更新します。
```
gcloud auth login
gcloud config set project PROJECT_ID
gcloud components update
```
Connect ゲートウェイとのやり取りに使用するクラスタ認証情報を取得します。次のコマンドでは、MEMBERSHIP_NAME をクラスタの名前に置き換えます。GKE on Bare Metal では、メンバーシップ名はクラスタ名と同じです。
```
gcloud container fleet memberships get-credentials MEMBERSHIP_NAME
```
このコマンドは、特別なConnect ゲートウェイ特有の kubeconfig を返します。これにより、ゲートウェイを介してクラスタに接続できます。

必要な認証情報を取得したら、通常の 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 は、ファイルが作成された日時を示します。

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

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

GKE On-Prem API とは

準備

IAM 権限を付与

必要な Google API

管理クラスタの前提条件

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

コマンドライン アクセス

ユーザー クラスタの作成

コンソール

クラスタの基本

ネットワーキング

MetalLB にバンドル済み

手動ロードバランサ

ストレージ

機能

ノードプールを作成

gcloud CLI

準備

例

MetalLB

MetalLB アドレスプール

MetalLB ノード

コントロール プレーン ノード

仮想 IP

Service CIDR と Pod CIDR

ストレージ

手動

コントロール プレーン ノード

仮想 IP

Service CIDR と Pod CIDR

ストレージ

ノードプールを作成

Terraform

準備

例

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

Connect ゲートウェイ

管理ワークステーション

次のステップ

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

コマンドラインアクセス

ユーザークラスタの作成

コントロールプレーンノード

コントロールプレーンノード

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