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

Google Distributed Cloud では、ワークロードは 1 つ以上のユーザー クラスタで実行されます。このドキュメントでは、ユーザー クラスタの作成方法について説明します。このページは、技術インフラストラクチャの設定、モニタリング、管理を行う管理者、アーキテクト、オペレーターを対象としています。Google Cloud のコンテンツで参照する一般的なロールとタスク例の詳細については、一般的な GKE Enterprise ユーザーロールとタスクをご覧ください。

ユーザー クラスタの作成に使用できるツールはいくつかあります。

  • gkectl
  • Google Cloud コンソール
  • Google Cloud CLI
  • Terraform

これらのツールのうち 3 つ（コンソール、gcloud CLI、Terraform）は、GKE On-Prem API のクライアントです。

使用するツールのガイダンスについては、クラスタのライフサイクルを管理するツールを選択するをご覧ください。

始める前に

  • Google Cloud リソースをまだ設定していない場合には、次のドキュメントの説明に従ってリソースを設定してください。

    フリート ホスト プロジェクトを設定する際は、ツールの選択に注意してください。GKE On-Prem API クライアントを選択した場合、追加の API を有効にする必要があります。API のリストについては、フリート ホスト プロジェクトで API を有効にするをご覧ください。

  • ユーザー クラスタを作成するには、ユーザー クラスタを管理する管理クラスタが必要です。まだ作成していない場合は、管理ワークステーションと管理クラスタを作成します。

  • インストールするユーザー クラスタのバージョンを決めます。通常、ユーザー クラスタを作成するときに、管理クラスタと同じバージョンをインストールします。ただし、それ以降のパッチ バージョンをインストールすることは可能です。バージョン 1.28 以降では、ユーザー クラスタは管理クラスタよりも 2 つ後までのマイナー バージョンにできます。

  • Controlplane V2 を有効にすることを強くおすすめします。Controlplane V2 が有効になっている場合、ユーザー クラスタのコントロール プレーンは、そのユーザー クラスタの 1 つ以上のノードで実行されます。バージョン 1.30 以降をインストールする場合は、Controlplane V2 が必要です。また、kubeception を使用するユーザー クラスタを作成することもできます。kubeception の場合、ユーザー クラスタのコントロール プレーンは管理クラスタ内の 1 つ以上のノードで実行されます。

  • IP アドレスの計画に関するドキュメントを参照して、十分な IP アドレスが利用できることを確認します。

  • ロード バランシングの概要を参照して、使用するロードバランサの種類を再度確認します。バンドルされた MetalLB ロードバランサを使用することも、独自のロードバランサを手動で構成することもできます。手動ロード バランシングの場合は、ユーザー クラスタを作成する前にロードバランサを設定する必要があります。

  • 必要なノードプールの数と、各プールで実行するオペレーティング システムについて検討します。

  • 管理クラスタとユーザー クラスタに別々の vSphere クラスタを使用するかどうか検討します。また、別々のデータセンターを使用するかどうかも検討します。さらに、vCenter Server の別々のインスタンスを使用するかどうか検討します。

  • バージョン 1.29 以降では、サーバーサイドのプリフライト チェックはデフォルトで有効になっています。サーバーサイドのプリフライト チェックには、追加のファイアウォール ルールが必要です。管理クラスタのファイアウォール ルールでプリフライト チェックを検索し、必要なファイアウォール ルールがすべて構成されていることを確認します。

    gkectl を使用してユーザー クラスタを作成した場合、サーバーサイドのプリフライト チェックは管理ワークステーションのローカルではなく、管理クラスタで実行されます。サーバーサイドのプリフライト チェックは、Google Cloud コンソール、Google Cloud CLI、または Terraform を使用してユーザー クラスタを作成する場合にも実行されます。

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

gkectl

手順の概要

gkectl を使用してユーザー クラスタを作成する主な手順は以下のとおりです。

  1. 管理ワークステーションに接続する
    管理ワークステーションは、ユーザー クラスタの作成に必要なツールを備えたマシンです。
  2. 構成ファイルを完成させる
    ユーザー クラスタの構成ファイル、認証情報の構成ファイル、IP ブロック ファイル（必要な場合）を完成させて、新しいクラスタの詳細を指定します。
  3. （省略可）OS イメージを vSphere にインポートし、必要に応じてコンテナ イメージをプライベート レジストリに push する
    gkectl prepare を実行します。
  4. ユーザー クラスタを作成する
    gkectl create cluster を実行して、構成ファイルに指定されたとおりにクラスタを作成します。
  5. ユーザー クラスタが実行されていることを確認する
    kubectl を使用してクラスタノードを表示します。

ユーザー クラスタが実行中になっていれば、そのクラスタにワークロードをデプロイできます。

VPC Service Controls を使用している場合、"Validation Category: GCP - [UNKNOWN] GCP service: [Stackdriver] could not get GCP services" などの一部の gkectl コマンドを実行するとエラーが表示されることがあります。これらのエラーを回避するには、コマンドに --skip-validation-gcp パラメータを追加します。

構成ファイルを完成させる

この操作は管理ワークステーションで行います。

gkeadm は、管理ワークステーションを作成する際に user-cluster.yaml という構成ファイルを生成します。この構成ファイルはユーザー クラスタの作成用です。

ユーザー クラスタの構成ファイルのドキュメントを参照して、構成ファイルについてよく理解してください。以降の操作で参照できるように、このドキュメントは別のタブまたはウィンドウで開いておくことをおすすめします。

name

name フィールドにユーザー クラスタの名前を設定します。

gkeOnPremVersion

このフィールドの値は、あらかじめ設定されています。ここには Google Distributed Cloud のバージョンを指定します。たとえば、1.30.100-gke.96 のようにします。

enableControlplaneV2

Controlplane V2 が有効になっているユーザー クラスタを作成するには、enableControlplaneV2 を true に設定します。

Controlplane V2 が有効になっている場合、ユーザー クラスタのコントロール プレーンはそのユーザー クラスタのノードで実行されます。Controlplane V2 を有効にすることを強くおすすめします。

kubeception

このフィールドを false に設定すると、クラスタは kubecetption を使用します。kubeception では、ユーザー クラスタのコントロール プレーンが管理クラスタ内のノードで実行されます。

kubeception クラスタの場合:

  • enableControlplaneV2 を false に設定します。

  • controlPlaneIPBlock セクションには値を設定しません。

  • 管理クラスタの IP ブロック ファイルで、ユーザー クラスタのコントロール プレーン ノードの IP アドレスを指定します。

enableDataplaneV2

enableDataplaneV2 を true に設定します。

vCenter

管理クラスタの構成ファイルの vCenter セクションに設定する値はグローバルです。つまり、管理クラスタと管理クラスタに関連付けられたユーザー クラスタに適用されます。

作成する各ユーザー クラスタで、一部のグローバル vCenter 値をオーバーライドできます。

グローバルな vCenter 値をオーバーライドする場合は、ユーザー クラスタの構成ファイルで vCenter セクションの関連するフィールドに値を指定します。

管理クラスタとユーザー クラスタに別々の vSphere クラスタや、別々のデータセンターを使用する必要がある場合もあります。

1 つのデータセンターと 1 つの vSphere クラスタの使用

デフォルトのオプションでは、管理クラスタとユーザー クラスタに 1 つのデータセンターと 1 つの vSphere クラスタを使用します。このオプションを使用する場合は、ユーザー クラスタの構成ファイルに vCenter 値を設定しないでください。vCenter 値は管理クラスタから継承されます。

個別の vSphere クラスタの使用

独自の vSphere クラスタ内にユーザー クラスタを作成する場合は、ユーザー クラスタの構成ファイルで vCenter.cluster の値を指定します。

管理クラスタとユーザー クラスタが別々の vSphere クラスタにある場合、これらのクラスタを同じデータセンターに配置することも、別のデータセンターに配置することもできます。

別々の vSphere データセンターの使用

ユーザー クラスタと管理クラスタは別々のデータセンターに配置できます。この場合、これらのクラスタは別々の vSphere クラスタに存在します。

ユーザー クラスタの構成ファイルで vCenter.datacenter を指定する場合は、次も指定する必要があります。

  • vCenter.networkName
  • vCenter.datastore または vCenter.storagePolicyName を指定します。
  • vCenter.cluster または vCenter.resourcePool を指定します。

別々の vCenter アカウントの使用

ユーザー クラスタは、管理クラスタとは異なる vCenter.credentials を持つ別の vCenter アカウントを使用できます。管理クラスタの vCenter アカウントは管理クラスタのデータセンターにアクセスする必要がありますが、ユーザー クラスタの vCenter アカウントはユーザー クラスタのデータセンターにのみアクセスする必要があります。

別々の vCenter Server インスタンスの使用

特定の状況では、vCenter Server の独自のインスタンスを使用するユーザー クラスタを作成したほうが合理的な場合があります。この環境では、管理クラスタとそれに関連するユーザー クラスタが別々の vCenter Server インスタンスを使用することになります。

たとえば、エッジ ロケーションで、vCenter Server を実行する 1 台の物理マシンと ESXi を実行する 1 台以上の物理マシンが必要になる場合があります。この場合、vCenter Server のローカル インスタンスを使用して、データセンター、クラスタ、リソースプール、データストア、フォルダなど、vSphere オブジェクト階層を作成できます。

ユーザー クラスタの構成ファイルで、vCenter セクション全体を設定します。vCenter.address には、管理クラスタの構成ファイルで指定した vCenter Server アドレスとは異なる値を指定します。例:

vCenter:
  address: "vc-edge.example"
  datacenter: "vc-edge"
  cluster: "vc-edge-workloads"
  resourcePool: "vc-edge-pool
  datastore: "vc-edge-datastore
  caCertPath: "/usr/local/google/home/me/certs/edge-cacert.pem"
  credentials:
    fileRef:
      path: "credential.yaml"
      entry: "vCenter-edge"
  folder: "edge-vm-folder"

また、network.vCenter.networkName フィールドも設定します。

network

クラスタノードが IP アドレスを取得する方法を決めます。次のオプションがあります。

  • 事前に設定した DHCP サーバーから取得する。network.ipMode.type を "dhcp" に設定します。

  • 指定した静的 IP アドレスのリストから取得する。network.ipMode.type を "static" に設定し、静的 IP アドレスを含む IP ブロック ファイルを作成します。IP ブロック ファイルの例については、設定後の構成ファイルの例をご覧ください。

ワーカーノードに静的 IP アドレスを使用する場合は、network.ipMode.ipBlockFilePath フィールドを設定します。

ユーザー クラスタのコントロール プレーン ノードは、指定した静的アドレスのリストから IP アドレスを取得する必要があります。これは、ワーカーノードが DHCP サーバーからアドレスを取得する場合も同様です。コントロール プレーン ノードの静的 IP アドレスを指定するには、network.controlPlaneIPBlock セクションを設定します。高可用性（HA）ユーザー クラスタが必要な場合は、3 個の IP アドレスを指定します。それ以外の場合は、1 個の IP アドレスを指定します。

hostConfig セクションで DNS サーバーと NTP サーバーを設定します。この DNS サーバーと NTP サーバーはコントロール プレーン ノード用です。ワーカーノードに静的 IP アドレスを使用している場合、これらの DNS サーバーと NTP サーバーもワーカーノードで使用されます。

network.podCIDR と network.serviceCIDR には、値が事前に設定されています。ネットワークですでに使用されているアドレスと競合しない限り、この値は変更できません。Kubernetes では、これらの範囲を使用してクラスタ内の Pod と Service に IP アドレスを割り当てます。

DHCP サーバーを使用するか、静的 IP アドレスのリストを指定するかにかかわらず、管理クラスタノードに十分な数の IP アドレスが必要です。必要な IP アドレスの数については、IP アドレスを計画するをご覧ください。

loadBalancer

ユーザー クラスタの Kubernetes API サーバー用に VIP を確保します。ユーザー クラスタの Ingress サービス用に別の VIP を確保します。loadBalancer.vips.controlPlaneVIP と loadBalancer.vips.ingressVIP の値として VIP を指定します。

使用するロード バランシングの種類を決めます。次のオプションがあります。

ロード バランシングのオプションの詳細については、ロード バランシングの概要をご覧ください。

advancedNetworking

下り（外向き）NAT ゲートウェイを作成する場合は、advancedNetworking を true に設定します。

multipleNetworkInterfaces

Pod に複数のネットワーク インターフェースを構成するかどうかを決定します。それに応じて multipleNetworkInterfaces を設定します。

storage

vSphere CSI コンポーネントのデプロイを無効にする場合は、storage.vSphereCSIDisabled を true に設定します。

masterNode

masterNode セクションで、ユーザー クラスタに必要なコントロール プレーン ノードの数（1 または 3）を指定できます。コントロール プレーン ノードのデータストアと、コントロール プレーン ノードで自動サイズ変更を有効にするかどうかも指定できます。

network.controlPlaneIPBlock セクションでコントロール プレーン ノードの IP アドレスを指定したことを思い出してください。

nodePools

ノードプールとは、クラスタ内で同じ構成を持つノードのグループのことです。たとえば、あるプールのノードは Windows を実行し、別のプールのノードは Linux を実行します。

nodePools セクションに、少なくとも 1 つのノードプールを指定する必要があります。

詳細については、ノードプールとノードプールの作成と管理をご覧ください。

antiAffinityGroups

antiAffinityGroups.enabled を true または false に設定します。

このフィールドは、Google Distributed Cloud がワーカーノード用に Distributed Resource Scheduler（DRS）のアンチアフィニティ ルールを作成し、データセンターで 3 台以上の物理ホストに分散させるかどうかを指定します。

stackdriver

クラスタで Cloud Logging と Cloud Monitoring を有効にする場合は、stackdriver セクションを設定します。

デフォルトでは、このセクションは必須です。このセクションを設定しない場合は、gkectl create cluster を実行するときに --skip-validation-stackdriver フラグを使用する必要があります。

新しいクラスタについては、次の要件に注意してください。

  • stackdriver.projectID の ID は、gkeConnect.projectID と cloudAuditLogging.projectID の ID と同じにする必要があります。

  • stackdriver.clusterLocation で設定された Google Cloud リージョンは、cloudAuditLogging.clusterLocation と gkeConnect.location で設定されたリージョンと同じである必要があります（フィールドが構成ファイルに含まれている場合）。さらに、gkeOnPremAPI.enabled が true の場合、gkeOnPremAPI.location に同じリージョンを設定する必要があります。

プロジェクト ID とリージョンが同じでない場合、クラスタの作成は失敗します。

gkeConnect

ユーザー クラスタは Google Cloud フリートに登録されている必要があります。

gkeConnect セクションで、フリート ホスト プロジェクトとそれに関連するサービス アカウントを指定します。gkeConnect.projectID の ID は、stackdriver.projectID と cloudAuditLogging.projectID に設定された ID と同じでなければなりません。プロジェクト ID が同じでない場合、クラスタの作成は失敗します。

1.28 以降では、必要に応じて、gkeConnect.location で Fleet と Connect サービスを実行するリージョンを指定できます。このフィールドを含めない場合、クラスタはこれらのサービスのグローバル インスタンスを使用します。

構成ファイルに gkeConnect.location を含める場合、指定するリージョンは、cloudAuditLogging.clusterLocation、stackdriver.clusterLocation、gkeOnPremAPI.location で構成されたリージョンと同じにする必要があります。リージョンが同じでない場合、クラスタの作成は失敗します。

gkeOnPremAPI

1.16 以降では、Google Cloud プロジェクトで GKE On-Prem API が有効になっている場合、プロジェクト内のすべてのクラスタが、stackdriver.clusterLocation で構成されたリージョンの GKE On-Prem API に自動的に登録されます。gkeOnPremAPI.location リージョンは、cloudAuditLogging.clusterLocation、gkeConnect.location（フィールドが構成ファイルに含まれている場合）、stackdriver.clusterLocation で指定されたリージョンと同じにする必要があります。

  • GKE On-Prem API のプロジェクトにすべてのクラスタを登録する場合は、始める前にの手順に沿って、プロジェクト内の GKE On-Prem API を有効にして使用します。

  • GKE On-Prem API にクラスタを登録しない場合は、このセクションを追加して、gkeOnPremAPI.enabled を false に設定します。プロジェクトにクラスタを登録しない場合は、プロジェクトで gkeonprem.googleapis.com（GKE On-Prem API のサービス名）を無効にします。手順については、サービスの無効化をご覧ください。

usageMetering

クラスタで使用状況測定を有効にする場合は、usageMetering セクションを設定します。

cloudAuditLogging

クラスタの Kubernetes API サーバーの監査ログを Cloud Audit Logs と統合する場合は、cloudAuditLogging セクションを設定します。

新しいクラスタについては、次の要件に注意してください。

  • cloudAuditLogging.projectID の ID は、gkeConnect.projectID と stackdriver.projectID の ID と同じにする必要があります。

  • cloudAuditLogging.clusterLocation のリージョンは、gkeConnect.location（フィールドが構成ファイルに含まれている場合）と stackdriver.clusterLocation で設定されたリージョンと同じにする必要があります。さらに、gkeOnPremAPI.enabled が true の場合、gkeOnPremAPI.location に同じリージョンを設定する必要があります。

プロジェクト ID とリージョンが同じでない場合、クラスタの作成は失敗します。

設定後の構成ファイルの例

以下に、IP ブロック ファイルとユーザー クラスタの構成ファイルの例を示します。

user-ipblock.yaml

blocks:
  - netmask: 255.255.255.0
    gateway: 172.16.21.1
    ips:
    - ip: 172.16.21.2
      hostname: worker-vm-1
    - ip: 172.16.21.3
      hostname: worker-vm-2
    - ip: 172.16.21.4
      hostname: worker-vm-3
    - ip: 172.16.21.5
      hostname: worker-vm-4

user-cluster.yaml

cat user-cluster.yaml
apiVersion: v1
kind: UserCluster
name: "my-user-cluster"
gkeOnPremVersion: 1.30.100-gke.96
enableControlplaneV2: true
enableDataplaneV2: true
network:
  hostConfig:
    dnsServers:
    - "203.0.113.2"
    - "198.51.100.2"
    ntpServers:
    - "216.239.35.4"
  ipMode:
    type: "static"
    ipBlockFilePath: "user-ipblock.yaml"
  serviceCIDR: 10.96.0.0/20
  podCIDR: 192.168.0.0/16
  controlPlaneIPBlock:
    netmask: "255.255.255.0"
    gateway: "172.16.21.1"
    ips:
    - ip: "172.16.21.6"
      hostname: "cp-vm-1"
    - ip: "172.16.21.7"
      hostname: "cp-vm-2"
    - ip: "172.16.21.8"
      hostname: "cp-vm-3"
loadBalancer:
  vips:
    controlPlaneVIP: "172.16.21.40"
    ingressVIP: "172.16.21.30"
  kind: MetalLB
  metalLB:
    addressPools:
    - name: "address-pool-1"
      addresses:
      - "172.16.21.30-172.16.21.39"
masterNode:
  cpus: 4
  memoryMB: 8192
  replicas: 3
nodePools:
- name: "worker-node-pool"
  cpus: 4
  memoryMB: 8192
  replicas: 3
  enableLoadBalancer: true
antiAffinityGroups:
  enabled: true
gkeConnect:
  projectID: "my-project-123"
  location: "us-central1"
  registerServiceAccountKeyPath: "connect-register-sa-2203040617.json"
stackdriver:
  projectID: "my-project-123"
  clusterLocation: "us-central1"
  enableVPC: false
  serviceAccountKeyPath: "log-mon-sa-2203040617.json"
autoRepair:
  enabled: true

これらの例で注意すべき重要なポイントは次のとおりです。

  • ワーカーノードの静的 IP アドレスは、IP ブロック ファイルに指定されています。IP ブロック ファイルには、ワーカーノードが 3 個しかない場合でも 4 個のアドレスが記述されています。この余分な IP アドレスは、クラスタのアップグレード、更新、自動修復で必要になります。

  • DNS サーバーと NTP サーバーは hostConfig セクションで指定されています。この例では、これらの DNS サーバーと NTP サーバーはコントロール プレーン ノードとワーカーノードに使用されます。これは、ワーカーノードが静的 IP アドレスを使用するためです。ワーカーノードが DHCP サーバーから IP アドレスを取得する場合、この DNS サーバーと NTP サーバーはコントロール プレーン ノードでのみ使用されます。

  • コントロール プレーン ノード 3 個の静的 IP アドレスは、ユーザー クラスタの構成ファイルの network.controlPlaneIPBlock セクションで指定されています。このブロックには、追加の IP アドレスは必要ありません。

  • Controlplane V2 が有効になっています。

  • masterNode.replicas フィールドが 3 に設定されているため、クラスタには高可用性コントロール プレーンがあります。

  • コントロール プレーンと Ingress の VIP は、どちらもワーカーノードとコントロール プレーン ノードと同じ VLAN にあります。

  • LoadBalancer タイプの Service 用に確保された VIP は、ユーザー クラスタの構成ファイルの loadBalancer.metalLB.addressPools セクションで指定されています。これらの VIP は、ワーカーノードやコントロール プレーン ノードと同じ VLAN にあります。このセクションで指定する VIP のセットには Ingress VIP を含める必要があります。コントロール プレーン VIP を含めることはできません。

  • ユーザー クラスタの構成ファイルには、vCenter セクションがありません。ユーザー クラスタは、管理クラスタと同じ vSphere リソースを使用します。

構成ファイルを検証する

ユーザー クラスタの構成ファイルを設定したら、gkectl check-config を実行して、ファイルが有効であることを検証します。

gkectl check-config --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

次のように置き換えます。

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

  • USER_CLUSTER_CONFIG: ユーザー クラスタの構成ファイルのパス

コマンドがエラー メッセージを返した場合は、問題を修正してファイルを再度検証します。

時間のかかる検証をスキップする場合は、--fast フラグを渡します。個別の検証をスキップするには、--skip-validation-xxx フラグを使用します。check-config コマンドについて詳しくは、プリフライト チェックの実行をご覧ください。

3. （省略可）OS イメージを vSphere にインポートし、コンテナ イメージをプライベート レジストリに push する

次のいずれかに該当する場合は、gkectl prepare を実行します。

  • ユーザー クラスタが、管理クラスタと異なる vSphere データセンターにある。

  • ユーザー クラスタが、管理クラスタとは異なる vCenter Server を使用している。

  • ユーザー クラスタが、管理クラスタとは異なる非公開コンテナ レジストリを使用している。

gkectl prepare --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --bundle-path BUNDLE \
    --user-cluster-config USER_CLUSTER_CONFIG

次のように置き換えます。

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

  • BUNDLE: バンドル ファイルのパス。このファイルは管理ワークステーションの /var/lib/gke/bundles/ にあります。例:

    /var/lib/gke/bundles/gke-onprem-vsphere-1.30.100-gke.96-full.tgz

  • USER_CLUSTER_CONFIG: ユーザー クラスタの構成ファイルのパス

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

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

gkectl create cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

VPC Service Controls を使用している場合、"Validation Category: GCP - [UNKNOWN] GCP service: [Stackdriver] could not get GCP services" などの一部の gkectl コマンドを実行するとエラーが表示されることがあります。これらのエラーを回避するには、コマンドに --skip-validation-gcp パラメータを追加します。

ユーザー クラスタの kubeconfig ファイルを見つける

gkectl create cluster コマンドで、現在のディレクトリに USER_CLUSTER_NAME-kubeconfig という名前の kubeconfig ファイルが作成されます。この kubeconfig ファイルは後でユーザー クラスタとやり取りする際に必要になります。

kubeconfig ファイルには、ユーザー クラスタの名前が含まれています。クラスタ名を表示するには、次のコマンドを実行します。

kubectl config get-clusters --kubeconfig USER_CLUSTER_KUBECONFIG

出力にクラスタの名前が表示されます。例:

NAME
my-user-cluster

kubeconfig ファイルの名前と場所は、必要に応じて変更できます。

5. ユーザー クラスタが実行されていることを確認する

ユーザー クラスタが実行されていることを確認します。

kubectl get nodes --kubeconfig USER_CLUSTER_KUBECONFIG

USER_CLUSTER_KUBECONFIG は、ユーザー クラスタの kubeconfig ファイルのパスに置き換えます。

出力には、ユーザー クラスタノードが表示されます。例:

cp-vm-1       Ready    control-plane,master   18m
cp-vm-2       Ready    control-plane,master   18m
cp-vm-3       Ready    control-plane,master   18m
worker-vm-1   Ready                           6m7s
worker-vm-2   Ready                           6m6s
worker-vm-3   Ready                           6m14s

コンソール

始める

  1. Google Cloud コンソールで、[Create a Google Distributed Cloud cluster] ページに移動します。

    [Create a Google Distributed Cloud cluster] に移動

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

クラスタの基本

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

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

  2. [管理クラスタ] で、リストから管理クラスタを選択します。管理クラスタの作成時に名前を指定しなかった場合、名前は gke-admin-[HASH] の形式で生成されます。管理クラスタ名が確認できない場合は、管理ワークステーションで次のコマンドを実行します。

    KUBECONFIG=ADMIN_CLUSTER_KUBECONFIG
kubectl get OnPremAdminCluster -n kube-system -o=jsonpath='{.items[0].metadata.name}'

    使用する管理クラスタが表示されない場合は、トラブルシューティングのセクション管理クラスタが [クラスタの基本] プルダウン リストに表示されないをご覧ください。

  3. [GCP 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. ユーザー クラスタの Google Distributed Cloud バージョンを選択します。

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

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

  6. [次へ] をクリックして [コントロール プレーン] セクションに移動します。

コントロール プレーン

[コントロール プレーン] セクションのすべてのフィールドには、デフォルト値が設定されています。デフォルトを確認して、必要に応じて変更します。

  1. [コントロール プレーン ノードの vCPU] フィールドに、ユーザー クラスタの各コントロール プレーン ノードの vCPU の数を入力します（最小値は 4）。

  2. [コントロール プレーン ノードのメモリ] フィールドに、ユーザー クラスタの各コントロール プレーンのメモリサイズを MiB 単位で入力します（最小値は 8192 で、4 の倍数にする必要があります）。

  3. [コントロール プレーン ノード] で、ユーザー クラスタのコントロール プレーン ノードの数を選択します。たとえば、開発環境用に 1 つのコントロール プレーン ノード、高可用性（HA）環境と本番環境用に 3 つのコントロール プレーン ノードを選択できます。

  4. 必要に応じて、[ノードの自動サイズ変更] を選択します。サイズ変更とは、ノードに割り当てられる vCPU リソースとメモリリソースが自動的に調整されることを意味します。有効にすると、ユーザー クラスタのコントロール プレーン ノードの数が、ユーザー クラスタ内のワーカーノード数に合わせて変更されます。そのため、ユーザー クラスタにワーカーノードを追加すると、コントロール プレーン ノードのサイズが増加します。

  5. 必要に応じて、[コントロール プレーン v2 を有効にする] を選択します。Controlplane V2 を有効にすると、ユーザー クラスタのコントロール プレーンは管理クラスタ（kubeception）ではなく、そのユーザー クラスタの 1 つ以上のノードで実行されます。

    [コントロール プレーン v2 を有効にする] を選択すると、[コントロール プレーン ノードの IP] セクションが表示されます。ゲートウェイの IP アドレス、サブネット マスク、コントロール プレーン ノードの IP アドレスを入力します。

    Controlplane V2 が有効になっている場合、vCPU とメモリのフィールドはユーザー クラスタ内のコントロール プレーン ノードに適用されます。ノードの数は、入力した IP アドレスの数によって決まります。Controlplane V2 が有効になっていない場合、vCPU、メモリ、コントロール プレーン ノード数のフィールドは管理クラスタ内のノードに適用されます。管理クラスタに十分な IP アドレスを確保するようにしてください。

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

ネットワーキング

このセクションでは、クラスタのノード、Pod、Service の IP アドレスを指定します。ユーザー クラスタには、ノードごとに 1 つの IP アドレスと、クラスタのアップグレード、更新、自動修復で必要な一時ノード用に別の IP アドレスが必要です。詳細については、ユーザー クラスタに必要な IP アドレス数をご覧ください。

  1. [ノード IP] セクションで、ユーザー クラスタの [IP モード] を選択します。次のいずれかを選択します。

    • DHCP: クラスタノードが IP アドレスを DHCP サーバーから取得するようにするには、[DHCP] を選択します。

    • 静的: クラスタノードに静的 IP アドレスを用意する場合や、手動ロード バランシングを設定する場合は、[静的] を選択します。

  2. [DHCP] を選択した場合は、次の手順に進んで、Service と Pod の CIDR を指定します。[Static IP mode] で、次の情報を入力します。

    1. ユーザー クラスタのゲートウェイの IP アドレスを入力します。

    2. ユーザー クラスタ ノードのサブネット マスクを入力します。

    3. [IP アドレス] セクションで、IP アドレスを入力します。必要に応じて、ユーザー クラスタ内のノードのホスト名も入力します。個別の IP v4 アドレス（192.0.2.1 など）か IPv4 アドレスの CIDR ブロック（192.0.2.0/24 など）を入力できます。

      • CIDR ブロックを入力する場合は、ホスト名を入力しないでください。

      • 個々の IP アドレスを入力する場合は、必要に応じてホスト名を入力できます。ホスト名を入力しない場合、Google Distributed Cloud はホスト名として vSphere の VM の名前を使用します。

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

  3. [Service と Pod CIDR] セクションには、Kubernetes Service と Pod に次のアドレス範囲が表示されます。

    • Service CIDR: 10.96.0.0/20
    • Pod CIDR: 192.168.0.0/16

    独自のアドレス範囲を入力する場合は、Pod と Service の IP アドレスのベスト プラクティスをご覧ください。

  4. [静的 IP モード] または [コントロール プレーン v2 を有効にする] を選択した場合は、[ホスト構成] セクションで次の情報を指定します。

    1. DNS サーバーの IP アドレスを入力します。
    2. NTP サーバーの IP アドレスを入力します。
    3. 必要に応じて、DNS 検索ドメインを入力します。

  5. [次へ] をクリックして、[ロードバランサ] セクションに移動します。

ロードバランサ

クラスタに設定するロードバランサを選択します。詳しくは、ロードバランサの概要をご覧ください。

リストからロードバランサの種類を選択します。

MetalLB にバンドル済み

MetalLB にバンドルされたロード バランシングを構成します。管理クラスタが SeeSaw または MetalLB を使用している場合にのみ、ユーザー クラスタに MetalLB を使用できます。このオプションでは、最小限の構成が必要になります。MetalLB はクラスタノードで直接動作するため、追加の VM は不要です。MetalLB を使用するメリットと他のロード バランシング オプションとの比較については、MetalLB にバンドルされたロード バランシングをご覧ください。

  1. [アドレスプール] セクションで、次のようにアドレスプールを少なくとも 1 つ構成します。

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

    2. Ingress VIP を含む 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. LoadBalancer タイプの Service の IP アドレスが Ingress VIP と同じ IP アドレス範囲でない場合は、[+ IP アドレス範囲を追加] をクリックして別のアドレスを入力します。

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

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

      • 自動: MetalLB コントローラがアドレスプールの IP アドレスを LoadBalancer タイプのサービスに自動的に割り振るようにするには、このオプションを選択します。

      • 手動: プール内のアドレスを LoadBalancer タイプの Service に手動で指定する場合は、このオプションを選択します。

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

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

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

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

    • コントロール プレーン VIP: ユーザー クラスタの Kubernetes API サーバーに送信されるトラフィックに使用する宛先 IP アドレス。ユーザー クラスタの Kubernetes API サーバーは、管理クラスタ内のノードで動作します。この IP アドレスは、管理クラスタノードと同じ L2 ドメイン内になければなりません。このアドレスを [アドレスプール] セクションには追加しないでください。

    • Ingress VIP: Ingress プロキシ用のロードバランサに構成する IP アドレス。これは、[アドレスプール] セクションのアドレスプールに追加する必要があります。

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

F5 BIG-IP

管理クラスタが F5 BIG-IP を使用している場合にのみ、ユーザー クラスタに F5 BIG-IP を使用できます。F5 BIG-IP ADC のインストールと構成は、Google Distributed Cloud と統合する前に行います。

F5 のユーザー名とパスワードは管理クラスタから継承されます。

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

    • コントロール プレーン VIP: Kubernetes API サーバーに送信するトラフィックに使用される宛先 IP アドレス。

    • Ingress VIP: Ingress プロキシ用のロードバランサに構成する IP アドレス。

  2. [アドレス] フィールドに、F5 BIG-IP ロードバランサのアドレスを入力します。

  3. [パーティション] フィールドに、ユーザー クラスタ用に作成した BIG-IP パーティションの名前を入力します。

  4. 該当する場合は、[SNAT プール名] フィールドに SNAT プールの名前を入力します。

  5. [続行] をクリックします。

手動

ユーザー クラスタに手動ロードバランサを使用できるのは、管理クラスタが手動ロードバランサを使用している場合だけです。Google Distributed Cloud では、Kubernetes API サーバー、Ingress プロキシがそれぞれ LoadBalancer タイプの Kubernetes Service によって公開されます。これらの Service 用に、30000～32767 の範囲で独自の nodePort 値を選択します。Ingress プロキシには、HTTP と HTTPS 両方のトラフィックに nodePort 値を選択します。詳細については、手動ロード バランシング モードの有効化をご覧ください。

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

    • コントロール プレーン VIP: Kubernetes API サーバーに送信するトラフィックに使用される宛先 IP アドレス。

    • Ingress VIP: Ingress プロキシ用のロードバランサに構成する IP アドレス。

  2. [コントロール プレーン ノードポート] フィールドに、Kubernetes API サーバーの nodePort 値を入力します。

  3. [Ingress HTTP ノードポート] フィールドに、Ingress プロキシへの HTTP トラフィックの nodePort 値を入力します。

  4. [Ingress HTTPS ノードポート] フィールドに、Ingress プロキシへの HTTPS トラフィックの nodePort 値を入力します。

  5. [Konnectivity サーバーのノードポート] フィールドに、Knnectivity サーバーの nodePort 値を入力します。

  6. [続行] をクリックします。

機能

このセクションには、クラスタで有効になっている機能と操作が表示されます。

  1. 以下の機能は自動で有効になります。無効にすることはできません。

  2. 以下の機能はデフォルトで有効になっていますが、無効にすることもできます。

    • vSphere CSI ドライバを有効にする: これは、vSphere Container Storage Plug-in ともいいます。Container Storage Interface（CSI）ドライバは、vSphere にデプロイされたネイティブの Kubernetes クラスタで実行され、vSphere ストレージに永続ボリュームをプロビジョニングします。詳細については、vSphere Container Storage Interface ドライバの使用をご覧ください。

    • 反アフィニティ グループを有効にする: VMware Distributed Resource Scheduler（DRS）の反アフィニティ ルールは、ユーザー クラスタのノードに対して自動的に作成され、データセンター内の少なくとも 3 台の物理ホストに分散されます。vSphere 環境が要件を満たしていることを確認します。

  3. [次へ] をクリックして、ノードプールを構成します。

ノードプール

クラスタは、少なくとも 1 つのノードプールを含めて作成されます。ノードプールは、このクラスタで作成されるワーカーノードのグループのテンプレートです。詳細については、ノードプールの作成と管理をご覧ください。

  1. [Node pool defaults] セクションで、次の操作を行います。

    1. ノードプール名を入力するか、名前として default-pool を使用します。
    2. プール内の各ノードの vCPU の数を入力します（ユーザー クラスタ ワーカーあたりの最小値は 4 です）。
    3. プール内の各ノードのメモリサイズを MiB 単位で入力します（ユーザー クラスタのワーカーノードあたり最小 8192 MiB で、4 の倍数でなければなりません）。
    4. [ノード] フィールドにプール内のノード数（3 以上）を入力します。[ネットワーキング] セクションで [ノード IP] に静的 IP アドレスを入力した場合は、これらのユーザー クラスタ ノードに対応できる十分な IP アドレス数が入力されていることを確認します。
    5. OS イメージのタイプ（Ubuntu、Ubuntu Containerd、または COS）を選択します。
    6. ブートディスク サイズを GiB 単位で入力します（最小 40 GiB）。
    7. MetalLB をロードバランサとして使用する場合、少なくとも 1 つのノードプールで MetalLB を有効にする必要があります。[このノードプールを MetalLB ロード バランシングに使用する] を選択したままにするか、MetalLB に使用する別のノードプールを追加します。

  2. Kubernetes ラベルおよび taint を追加する場合は、[ノードプールのメタデータ（省略可）] セクションで次のように設定します。

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

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

    設定の確認中にエラーが発生した場合は、コンソールにエラー メッセージが表示されます。これにより、構成の問題を修正して、クラスタを再度作成することができます。

    発生する可能性のあるエラーと修正方法の詳細については、Google Cloud コンソールでのユーザー クラスタの作成に関するトラブルシューティングをご覧ください。

gcloud CLI

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

gcloud container vmware clusters create

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

gcloud container vmware node-pools create

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

情報を収集する

クラスタの作成に必要な情報を収集します。

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

    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

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

  2. 利用可能なバージョンのリストを取得します。

    gcloud container vmware 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 が実行され、メタデータが保存されるリージョンです。

      • 管理クラスタが GKE On-Prem API に登録されている場合は、管理クラスタと同じリージョンを使用します。管理クラスタのリージョンを確認するには、次のコマンドを実行します。

        gcloud container vmware admin-clusters list \
  --project=FLEET_HOST_PROJECT_ID \
  --location=-

      • 管理クラスタが GKE On-Prem API に登録されていない場合は、us-west1 または別のサポート対象リージョンを指定します。後で管理クラスタを GKE On-Prem API に登録する場合は、ユーザー クラスタと同じリージョンを使用します。

    gcloud container vmware clusters query-version-config コマンドの出力は、次のようになります。

    versions:
- isInstalled: true
  version: 1.28.800-gke.109
- version: 1.29.0-gke.1456
- version: 1.29.100-gke.248
- version: 1.29.200-gke.245
- version: 1.29.300-gke.184

    このコマンドは、ユーザー クラスタの作成またはアップグレードに使用できるバージョンの説明も出力します。ユーザー クラスタの作成に使用できるバージョンには、isInstalled: true というアノテーションが付いています。つまり、管理クラスタには、そのバージョンのユーザー クラスタを管理するために必要なバージョン特有のコンポーネントがあります。管理クラスタにインストールされているバージョンを使用する場合は、例セクションに進んでユーザー クラスタを作成します。

新しいバージョンをインストールする

管理クラスタは、異なるバージョンのユーザー クラスタを管理できます。query-version-config コマンドの出力には、クラスタの作成時に使用できる他のバージョンが一覧表示されます。管理クラスタよりも新しいバージョンのユーザー クラスタを作成する場合は、次のように、管理クラスタがそのバージョンのユーザー クラスタを管理するために必要なコンポーネントをダウンロードしてデプロイする必要があります。

gcloud container vmware admin-clusters update ADMIN_CLUSTER_NAME \
    --project=FLEET_HOST_PROJECT_ID \
    --location=REGION \
    --required-platform-version=VERSION

VERSION は、query-version-config コマンドの出力に含まれているバージョンのいずれかに置き換えます。

このコマンドは、--required-platform-version で指定したバージョンのコンポーネントを管理クラスタにダウンロードし、そのコンポーネントをデプロイします。これで、指定したバージョンでユーザー クラスタを作成できるようになりました。

gcloud container vmware clusters query-version-config を再実行すると、指定したバージョンに isInstalled: true のアノテーションが付けられます。

例

次の例は、Controlplane V2 が有効なさまざまなロードバランサを使用してユーザー クラスタを作成する方法を示しています。Controlplane V2 を使用すると、ユーザー クラスタのコントロール プレーンはそのユーザー クラスタの 1 つ以上のノードで実行されます。Controlplane V2 を有効にすることをおすすめします。バージョン 1.30 以降では、新しいユーザー クラスタで Controlplane V2 を有効にする必要があります。使用可能なロード バランシング オプションの詳細については、ロードバランサの概要をご覧ください。

ほとんどの例では、デフォルト値を使用してコントロール プレーン ノードを構成しています。デフォルトを変更する場合は、コントロール プレーンのフラグで説明されているフラグを指定します。必要に応じて、vSphere 設定の一部を変更することもできます。

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

gcloud container vmware clusters create コマンドを実行してから 1 分以上経過した後にエラーが発生した場合は、次のコマンドを実行して、クラスタが部分的に作成されたかどうかを確認します。

gcloud container vmware clusters list \
    --project=FLEET_HOST_PROJECT_ID \
    --location=-

出力にクラスタが含まれていない場合は、エラーを修正して gcloud container vmware clusters create を再実行します。

出力にクラスタが含まれている場合は、次のコマンドを使用してクラスタを削除します。

gcloud container vmware clusters delete USER_CLUSTER_NAME \
    --project=FLEET_HOST_PROJECT_ID \
    --location=REGION \
    --force \
    --allow-missing

エラーを修正して gcloud container vmware clusters create を再実行します。

クラスタの稼働後、ノードプールの作成で説明されているように、ワークロードをデプロイする前にノードプールを追加する必要があります。

MetalLB と DHCP

この例では、バンドルされた MetalLB ロードバランサを使用するユーザー クラスタを作成し、DHCP サーバーを使用してクラスタ ワーカー ノードの IP アドレスを取得する方法を示します。

管理クラスタが MetalLB を使用している場合にのみ、ユーザー クラスタに MetalLB を使用できます。このロード バランシング オプションでは、最小限の構成が必要になります。MetalLB はクラスタノードで直接動作するため、追加の VM は不要です。MetalLB を使用するメリットと他のロード バランシング オプションとの比較については、MetalLB にバンドルされたロード バランシングをご覧ください。

次のコマンド例では、以下の特性を持つユーザー クラスタを作成します。この特性は、必要に応じて環境に合わせて変更できます。

フラグ 説明
--admin-users 自分と別のユーザーにクラスタに対する完全な管理者権限を付与します。
--enable-control-plane-v2 Controlplane V2 を有効にします。バージョン 1.30 以降では、これは推奨で、必須です。
--control-plane-ip-block コントロール プレーン ノード用に 1 つの IP アドレス。高可用性（HA）ユーザー クラスタを作成するには、3 つの IP アドレスを指定し、--replicas=3 フラグを追加します。
--metal-lb-config-address-pools MetalLB ロードバランサの 2 つのアドレスプール。少なくとも 1 つのアドレスプールが必要です。必要に応じて、さらに指定できます。便宜上、Ingress VIP の IP アドレスがいずれかのアドレスプールに存在する必要があることを示すため、この例には「ingress-vip-pool」という名前のアドレスプールが含まれています。単一の IP アドレスの CIDR を指定するには、IP アドレスに /32 を追加します。 
gcloud container vmware 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 \
    --service-address-cidr-blocks=10.96.0.0/20 \
    --pod-address-cidr-blocks=192.168.0.0/16 \
    --metal-lb-config-address-pools='pool=NAME,avoid-buggy-ips=AVOID_BUGGY_IPS,manual-assign=MANUAL_ASSIGN,addresses=IP_ADDRESS_RANGE_1' \
    --metal-lb-config-address-pools='pool=ingress-vip-pool,avoid-buggy-ips=False,manual-assign=True,addresses=INGRESS_VIP/32' \
    --enable-control-plane-v2 \
    --dns-servers=DNS_SERVER_1 \
    --ntp-servers=NTP_SERVER_1 \
    --control-plane-ip-block 'gateway=CP_GATEWAY,netmask=CP_NETMASK,ips=CP_IP_ADDRESS_1 CP_HOST_1' \
    --control-plane-vip=CONTROL_PLANE_VIP \
    --ingress-vip=INGRESS_VIP \
    --enable-dhcp

次のように置き換えます。

  • 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）、Fleet サービス（gkehub.googleapis.com）、Connect サービス（gkeconnect.googleapis.com）が実行される Google Cloud リージョン。us-west1 または別のサポート対象リージョンを指定します。クラスタの作成後にリージョンを変更することはできません。この設定では、以下のデータが保存されるリージョンを指定します。
    • クラスタのライフサイクル管理で GKE On-Prem API が必要とするユーザー クラスタ メタデータ
    • システム コンポーネントの Cloud Logging データと Cloud Monitoring データ
    • Cloud Audit Logs によって作成された管理監査ログ

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

  • VERSION: ユーザー クラスタの Google Distributed Cloud のバージョン。
  • 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 ロールが付与されます。このロールにより、すべての Namespace で、クラスタのすべてのリソースに対する完全アクセス権が付与されます。

  • SERVICE_CIDR_BLOCK: クラスタ内の Service に使用される IP アドレスの範囲（CIDR 形式）。/24 以上の範囲にする必要があります。

    例: --service-address-cidr-blocks=10.96.0.0/20

  • POD_CIDR_BLOCK: クラスタ内の Pod に使用される IP アドレスの範囲（CIDR 形式）。/18 以上の範囲にする必要があります。

    例: --pod-address-cidr-blocks=192.168.0.0/16

  • --metal-lb-config-address-pools: MetalLB ロードバランサで使用するアドレスプールの構成を指定する場合は、このフラグを使用します。フラグの値の形式は次のとおりです。 
    --metal-lb-config-address-pool '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 コントローラがこのプールの IP アドレスを Service に自動的に割り当てないようにする場合は、これを True に設定します。これにより、デベロッパーは、LoadBalancer タイプの Service を作成し、プールのアドレスの 1 つを手動で指定できるようになります。指定しない場合、manual-assign は False に設定されます。
    • addresses のリスト: 各アドレスは CIDR 表記またはハイフン付きの範囲形式のいずれかで指定する必要があります。プール内の単一の IP アドレス（Ingress VIP など）を指定する場合は、CIDR 表記の /32 を使用します（例: 192.0.2.1/32）。

    次の点にご注意ください。

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

    例:

    --metal-lb-config-address-pool 'pool=pool1,avoid-buggy-ips=True,manual-assign=True,addresses=10.251.134.80/32;192.168.1.0/26;192.168.1.2-192.168.1.3'
  • CONTROL_PLANE_VIP: ユーザー クラスタの Kubernetes API サーバー用にロードバランサで構成するために選択した IP アドレス。

    例: --control-plane-vip=203.0.113.3

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

    例: --ingress-vip=10.251.134.80

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

  • --enable-dhcp: 指定した DHCP サーバーからクラスタノードが IP アドレスを取得するようにするには、--enable-dhcp を指定します。クラスタノードに静的 IP アドレスを設定する場合や、手動ロード バランシングを設定する場合は、このフラグを指定しないでください。

MetalLB と静的 IP

この例では、バンドルされた MetalLB ロードバランサを使用するユーザー クラスタを作成し、クラスタ ワーカー ノードに静的 IP アドレスを割り当てる方法を示します。

管理クラスタが MetalLB を使用している場合にのみ、ユーザー クラスタに MetalLB を使用できます。このロード バランシング オプションでは、最小限の構成が必要になります。MetalLB はクラスタノードで直接動作するため、追加の VM は不要です。MetalLB を使用するメリットと他のロード バランシング オプションとの比較については、MetalLB にバンドルされたロード バランシングをご覧ください。

次のコマンド例では、以下の特性を持つユーザー クラスタを作成します。この特性は、必要に応じて環境に合わせて変更できます。

フラグ 説明
--admin-users 自分と別のユーザーにクラスタに対する完全な管理者権限を付与します。
--enable-control-plane-v2 Controlplane V2 を有効にします。バージョン 1.30 以降では、これは推奨で、必須です。
--control-plane-ip-block コントロール プレーン ノード用に 1 つの IP アドレス。高可用性（HA）ユーザー クラスタを作成するには、3 つの IP アドレスを指定し、--replicas=3 フラグを追加します。
--metal-lb-config-address-pools MetalLB ロードバランサの 2 つのアドレスプール。少なくとも 1 つのアドレスプールが必要です。必要に応じて、さらに指定できます。便宜上、Ingress VIP の IP アドレスがいずれかのアドレスプールに存在する必要があることを示すため、この例には「ingress-vip-pool」という名前のアドレスプールが含まれています。単一の IP アドレスの CIDR を指定するには、IP アドレスに /32 を追加します。
--static-ip-config-ip-blocks クラスタ内のワーカーノードの 4 つの IP アドレス。これには、アップグレードと更新に使用できる追加のノードのアドレスが含まれます。必要に応じて、さらに IP アドレスを指定できます。ホスト名は省略可能です。 
gcloud container vmware 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 \
    --service-address-cidr-blocks=10.96.0.0/20 \
    --pod-address-cidr-blocks=192.168.0.0/16 \
    --metal-lb-config-address-pools='pool=NAME,avoid-buggy-ips=AVOID_BUGGY_IPS,manual-assign=MANUAL_ASSIGN,addresses=IP_ADDRESS_RANGE_1' \
    --metal-lb-config-address-pools='pool=ingress-vip-pool,avoid-buggy-ips=False,manual-assign=True,addresses=INGRESS_VIP/32' \
    --enable-control-plane-v2 \
    --control-plane-ip-block 'gateway=CP_GATEWAY,netmask=CP_NETMASK,ips=CP_IP_ADDRESS_1 CP_HOST_1' \
    --control-plane-vip=CONTROL_PLANE_VIP \
    --ingress-vip=INGRESS_VIP \
    --static-ip-config-ip-blocks='gateway=GATEWAY,netmask=NETMASK,ips=IP_ADDRESS_1 HOST_1;IP_ADDRESS_2 HOST_2;IP_ADDRESS_3 HOST_3;IP_ADDRESS_4 HOST_4' \
    --dns-servers=DNS_SERVER_1 \
    --ntp-servers=NTP_SERVER_1

次のように置き換えます。

  • 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）、Fleet サービス（gkehub.googleapis.com）、Connect サービス（gkeconnect.googleapis.com）が実行される Google Cloud リージョン。us-west1 または別のサポート対象リージョンを指定します。クラスタの作成後にリージョンを変更することはできません。この設定では、以下のデータが保存されるリージョンを指定します。
    • クラスタのライフサイクル管理で GKE On-Prem API が必要とするユーザー クラスタ メタデータ
    • システム コンポーネントの Cloud Logging データと Cloud Monitoring データ
    • Cloud Audit Logs によって作成された管理監査ログ

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

  • VERSION: ユーザー クラスタの Google Distributed Cloud のバージョン。
  • 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 ロールが付与されます。このロールにより、すべての Namespace で、クラスタのすべてのリソースに対する完全アクセス権が付与されます。

  • SERVICE_CIDR_BLOCK: クラスタ内の Service に使用される IP アドレスの範囲（CIDR 形式）。/24 以上の範囲にする必要があります。

    例: --service-address-cidr-blocks=10.96.0.0/20

  • POD_CIDR_BLOCK: クラスタ内の Pod に使用される IP アドレスの範囲（CIDR 形式）。/18 以上の範囲にする必要があります。

    例: --pod-address-cidr-blocks=192.168.0.0/16

  • --metal-lb-config-address-pools: MetalLB ロードバランサで使用するアドレスプールの構成を指定する場合は、このフラグを使用します。フラグの値の形式は次のとおりです。 
    --metal-lb-config-address-pool '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 コントローラがこのプールの IP アドレスを Service に自動的に割り当てないようにする場合は、これを True に設定します。これにより、デベロッパーは、LoadBalancer タイプの Service を作成し、プールのアドレスの 1 つを手動で指定できるようになります。指定しない場合、manual-assign は False に設定されます。
    • addresses のリスト: 各アドレスは CIDR 表記またはハイフン付きの範囲形式のいずれかで指定する必要があります。プール内の単一の IP アドレス（Ingress VIP など）を指定する場合は、CIDR 表記の /32 を使用します（例: 192.0.2.1/32）。

    次の点にご注意ください。

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

    例:

    --metal-lb-config-address-pool 'pool=pool1,avoid-buggy-ips=True,manual-assign=True,addresses=10.251.134.80/32;192.168.1.0/26;192.168.1.2-192.168.1.3'
  • CONTROL_PLANE_VIP: ユーザー クラスタの Kubernetes API サーバー用にロードバランサで構成するために選択した IP アドレス。

    例: --control-plane-vip=203.0.113.3

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

    例: --ingress-vip=10.251.134.80

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

  • --static-ip-config-ip-blocks: ユーザー クラスタ内のワーカーノードのデフォルト ゲートウェイ、サブネット マスク、静的 IP アドレスのリストを指定します。フラグの値の形式は次のとおりです。 
    --static-ip-config-ip-blocks 'gateway=GATEWAY,netmask=NETMASK,ips=IP_ADDRESS_1;IP_ADDRESS_2 HOST_2;...'

    この値には、gateway、netmask、ips というキーワードで始まるセグメントがあります。セグメントはカンマで区切ります。

    次の点にご注意ください。

    • 値全体を単一引用符で囲みます。
    • IP アドレスとホスト名の間を除き、空白文字は使用できません。

    IP アドレスのリスト:

    • 個々の IP アドレスまたは IP アドレスの CIDR ブロックを指定できます。
    • 各 IP アドレスまたは CIDR ブロックはセミコロンで区切ります。
    • 個々の IP アドレスを指定する場合、必要に応じて、IP アドレスの後にホスト名を追加できます。IP アドレスとホスト名はスペースで区切ります。ホスト名を指定しないと、Google Distributed Cloud はホスト名として vSphere の VM の名前を使用します。
    • CIDR ブロックを指定する場合は、ホスト名の値を指定しないでください。

    例:

    --static-ip-config-ip-blocks 'gateway=172.16.23.254,netmask=255.255.252.0,ips=172.16.20.10;172.16.20.11 host2;172.16.20.12/30'
  • DNS_SERVER: VM の DNS サーバーの IP アドレスのカンマ区切りのリスト。
  • DNS_SEARCH_DOMAIN: ホストが使用する DNS 検索ドメインのカンマ区切りのリスト。これらのドメインは、ドメイン検索リストの一部として使用されます。

    例:

    --dns-search-domains example.com,examplepetstore.com
  • NTP_SERVER: VM が使用する時刻サーバーの IP アドレスのカンマ区切りのリスト。

手動 LB と静的 IP

この例では、手動ロードバランサを使用するユーザー クラスタを作成し、クラスタ ワーカー ノードに静的 IP アドレスを割り当てる方法を示します。

ユーザー クラスタに手動ロードバランサを使用できるのは、管理クラスタが手動ロードバランサを使用している場合だけです。Google Distributed Cloud では、Kubernetes API サーバー、Ingress プロキシ、ログ集計用のアドオン サービスがそれぞれ LoadBalancer タイプの Kubernetes Service によって公開されます。これらの Service 用に、30000～32767 の範囲で独自の nodePort 値を選択します。Ingress プロキシには、HTTP と HTTPS 両方のトラフィックに nodePort 値を選択します。詳細については、手動ロード バランシング モードの有効化をご覧ください。

次のコマンド例では、以下の特性を持つユーザー クラスタを作成します。この特性は、必要に応じて環境に合わせて変更できます。

フラグ 説明
--admin-users 自分と別のユーザーにクラスタに対する完全な管理者権限を付与します。
--enable-control-plane-v2 Controlplane V2 を有効にします。バージョン 1.30 以降では、これは推奨で、必須です。
--control-plane-ip-block コントロール プレーン ノード用に 1 つの IP アドレス。高可用性（HA）ユーザー クラスタを作成するには、3 つの IP アドレスを指定し、--replicas=3 フラグを追加します。
--static-ip-config-ip-blocks クラスタ内のワーカーノードの 4 つの IP アドレス。これには、アップグレードと更新に使用できる追加のノードのアドレスが含まれます。必要に応じて、さらに IP アドレスを指定できます。ホスト名は省略可能です。 
gcloud container vmware 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 \
    --service-address-cidr-blocks=10.96.0.0/20 \
    --pod-address-cidr-blocks=192.168.0.0/16 \
    --enable-control-plane-v2 \
    --control-plane-ip-block 'gateway=CP_GATEWAY,netmask=CP_NETMASK,ips=CP_IP_ADDRESS_1 CP_HOST_1' \
    --control-plane-vip=CONTROL_PLANE_VIP \
    --ingress-vip=INGRESS_VIP \
    --ingress-http-node-port=INGRESS_HTTP_NODE_PORT \
    --ingress-https-node-port=INGRESS_HTTPS_NODE_PORT \
    --static-ip-config-ip-blocks='gateway=GATEWAY,netmask=NETMASK,ips=IP_ADDRESS_1 HOST_1;IP_ADDRESS_2 HOST_2;IP_ADDRESS_3 HOST_3;IP_ADDRESS_4 HOST_4' \
    --dns-servers=DNS_SERVER_1 \
    --ntp-servers=NTP_SERVER_1

次のように置き換えます。

  • 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）、Fleet サービス（gkehub.googleapis.com）、Connect サービス（gkeconnect.googleapis.com）が実行される Google Cloud リージョン。us-west1 または別のサポート対象リージョンを指定します。クラスタの作成後にリージョンを変更することはできません。この設定では、以下のデータが保存されるリージョンを指定します。
    • クラスタのライフサイクル管理で GKE On-Prem API が必要とするユーザー クラスタ メタデータ
    • システム コンポーネントの Cloud Logging データと Cloud Monitoring データ
    • Cloud Audit Logs によって作成された管理監査ログ

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

  • VERSION: ユーザー クラスタの Google Distributed Cloud のバージョン。
  • 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 ロールが付与されます。このロールにより、すべての Namespace で、クラスタのすべてのリソースに対する完全アクセス権が付与されます。

  • SERVICE_CIDR_BLOCK: クラスタ内の Service に使用される IP アドレスの範囲（CIDR 形式）。/24 以上の範囲にする必要があります。

    例: --service-address-cidr-blocks=10.96.0.0/20

  • POD_CIDR_BLOCK: クラスタ内の Pod に使用される IP アドレスの範囲（CIDR 形式）。/18 以上の範囲にする必要があります。

    例: --pod-address-cidr-blocks=192.168.0.0/16

  • CONTROL_PLANE_VIP: ユーザー クラスタの Kubernetes API サーバー用にロードバランサで構成するために選択した IP アドレス。

    例: --control-plane-vip=203.0.113.3

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

    例: --ingress-vip=203.0.113.4

  • INGRESS_HTTP_NODE_PORT: 上り（内向き）プロキシへの HTTP トラフィックの nodePort 値（30243 など）。

  • INGRESS_HTTPS_NODE_PORT: Ingress プロキシへの HTTPS トラフィックの nodePort 値（30879 など）。

  • --static-ip-config-ip-blocks: ユーザー クラスタ内のワーカーノードのデフォルト ゲートウェイ、サブネット マスク、静的 IP アドレスのリストを指定します。フラグの値の形式は次のとおりです。 
    --static-ip-config-ip-blocks 'gateway=GATEWAY,netmask=NETMASK,ips=IP_ADDRESS_1;IP_ADDRESS_2 HOST_2;...'

    この値には、gateway、netmask、ips というキーワードで始まるセグメントがあります。セグメントはカンマで区切ります。

    次の点にご注意ください。

    • 値全体を単一引用符で囲みます。
    • IP アドレスとホスト名の間を除き、空白文字は使用できません。

    IP アドレスのリスト:

    • 個々の IP アドレスまたは IP アドレスの CIDR ブロックを指定できます。
    • 各 IP アドレスまたは CIDR ブロックはセミコロンで区切ります。
    • 個々の IP アドレスを指定する場合、必要に応じて、IP アドレスの後にホスト名を追加できます。IP アドレスとホスト名はスペースで区切ります。ホスト名を指定しないと、Google Distributed Cloud はホスト名として vSphere の VM の名前を使用します。
    • CIDR ブロックを指定する場合は、ホスト名の値を指定しないでください。

    例:

    --static-ip-config-ip-blocks 'gateway=172.16.23.254,netmask=255.255.252.0,ips=172.16.20.10;172.16.20.11 host2;172.16.20.12/30'
  • DNS_SERVER: VM の DNS サーバーの IP アドレスのカンマ区切りのリスト。
  • DNS_SEARCH_DOMAIN: ホストが使用する DNS 検索ドメインのカンマ区切りのリスト。これらのドメインは、ドメイン検索リストの一部として使用されます。

    例:

    --dns-search-domains example.com,examplepetstore.com
  • NTP_SERVER: VM が使用する時刻サーバーの IP アドレスのカンマ区切りのリスト。

コントロール プレーンのフラグ

コントロール プレーンの構成にデフォルト以外の値を使用する場合は、次のフラグを 1 つ以上指定します。

  • --cpus=vCPUS: ユーザー クラスタの各コントロール プレーン ノードの vCPU の数（最小値は 4）。指定しない場合、デフォルトは 4 個の vCPU です。

  • --memory=MEMORY: ユーザー クラスタの各コントロール プレーンのメモリサイズ（MiB 単位）。最小値は 8192 で、4 の倍数にする必要があります。指定しない場合、デフォルトは 8192 です。

  • --replicas=NODES: ユーザー クラスタのコントロール プレーン ノードの数たとえば、開発環境用に 1 つのコントロール プレーン ノード、高可用性（HA）環境と本番環境用に 3 つのコントロール プレーン ノードを選択できます。

  • --enable-auto-resize: ユーザー クラスタのコントロール プレーン ノードの自動サイズ変更を有効にする場合は、--enable-auto-resize を指定します。サイズ変更とは、ノードに割り当てられる vCPU リソースとメモリリソースが自動的に調整されることを意味します。有効にすると、ユーザー クラスタのコントロール プレーン ノードの数が、ユーザー クラスタ内のワーカーノード数に合わせて変更されます。そのため、ユーザー クラスタにワーカーノードを追加すると、コントロール プレーン ノードのサイズが増加します。

  • --enable-control-plane-v2: Controlplane V2 を有効にするには、このフラグを指定します（推奨）。Controlplane V2 が有効になっている場合、ユーザー クラスタのコントロール プレーンは、そのユーザー クラスタの 1 つ以上のノードで実行されます。バージョン 1.30 以降では、Controlplane V2 が必須です。

    Controlplane V2 を有効にする場合は、次のフラグも指定する必要があります。

    • --dns-servers=DNS_SERVER_1,...: VM の DNS サーバーの IP アドレスのカンマ区切りのリスト。

    • --ntp-servers=NTP_SERVER_1,...: VM が使用する時刻サーバーの IP アドレスのカンマ区切りのリスト。

    • --control-plane-ip-block の形式は次のとおりです。

        --control-plane-ip-block 'gateway=CP_GATEWAY,netmask=CP_NETMASK,ips=CP_IP_ADDRESS_1;CP_IP_ADDRESS_2 CP_HOST_2'

      この値には、gateway、netmask、ips というキーワードで始まるセグメントがあります。セグメントはカンマで区切ります。

      次の点にご注意ください。

      • 値全体を単一引用符で囲みます。

      • IP アドレスとホスト名の間を除き、空白文字は使用できません。

        IP アドレスのリスト:

      • 個々の IP アドレスまたは IP アドレスの CIDR ブロックを指定できます。

      • 各 IP アドレスまたは CIDR ブロックはセミコロンで区切ります。

      • 個々の IP アドレスを指定する場合、必要に応じて、IP アドレスの後にホスト名を追加できます。IP アドレスとホスト名はスペースで区切ります。

      • CIDR ブロックを指定する場合は、ホスト名の値を指定しないでください。

        例:

        --control-plane-ip-block 'gateway=192.168.0.1,netmask=255.0.0.0,ips=192.168.1.1;192.168.1.2 hostname-2;192.168.2.2/28`

    • 省略可: --dns-search-domains=DNS_SEARCH_DOMAIN_1,...: ホストが使用する DNS 検索ドメインのカンマ区切りリスト。これらのドメインは、ドメイン検索リストの一部として使用されます。

      例:

      --dns-search-domains example.com,examplepetstore.com

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

    vSphere のフラグ

    必要に応じて、次のオプション フラグを指定します。

  • --disable-aag-config: このフラグを指定しない場合、ユーザー クラスタのノードに VMware Distributed Resource Scheduler（DRS）の反アフィニティ ルールが自動的に作成され、ノードはデータセンター内の少なくとも 3 台の物理ホストに分散されます。vSphere 環境が要件を満たしていることを確認します。クラスタが要件を満たしていない場合は、このフラグを指定します。

  • --disable-vsphere-csi: このフラグを指定しない場合、vSphere Container Storage Interface（CSI）コンポーネントがユーザー クラスタにデプロイされます。CSI ドライバは、vSphere にデプロイされたネイティブの Kubernetes クラスタで実行され、vSphere ストレージに永続ボリュームをプロビジョニングします。詳細については、vSphere Container Storage Interface ドライバの使用をご覧ください。CSI コンポーネントをデプロイしない場合は、このフラグを指定します。

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

    クラスタ作成の進捗状況を確認する

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

    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 vmware operations describe OPERATION_ID \
  --project=FLEET_HOST_PROJECT_ID \
  --location=REGION

    詳細については、gcloud container vmware operations をご覧ください。

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

    ノードプールを作成する

    クラスタを作成したら、ワークロードをデプロイする前に少なくとも 1 つのノードプールを作成する必要があります。

    gcloud container vmware node-pools create NODE_POOL_NAME \
--cluster=USER_CLUSTER_NAME  \
--project=FLEET_HOST_PROJECT_ID \
--location=REGION \
--image-type=IMAGE_TYPE  \
--boot-disk-size=BOOT_DISK_SIZE \
--cpus=vCPUS \
--memory=MEMORY \
--replicas=NODES \
--enable-load-balancer

    次のように置き換えます。

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

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

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

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

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

  • IMAGE_TYPE: ノードプール内の VM で実行する OS イメージのタイプ。ubuntu_containerd または cos のいずれかに設定します。

  • BOOT_DISK_SIZE: プール内の各ノードのブートディスクのサイズ（GiB 単位）。最小値は 40 GiB です。

  • vCPUs: ノードプール内の各ノードの vCPU 数。最小値は 4 です。

  • MEMORY: プール内の各ノードのメモリサイズ（MiB 単位）。最小値は、ユーザー クラスタ ワーカーノードあたり 8,192 MiB で、値は 4 の倍数にする必要があります。

  • NODES: ノードプール内のノード数。最小値は 3 です。

  • ロードバランサとして MetalLB を使用している場合、プール内のノードで MetalLB スピーカーを実行できるようにするには、必要に応じて --enable-load-balancer を指定します。MetalLB は少なくとも 1 つのノードプールで有効にする必要があります。このフラグを指定しない場合は、MetalLB に使用する別のノードプールを作成する必要があります。

    オプションのフラグについては、ノードプールを追加すると gcloud CLI リファレンスをご覧ください。

gcloud コマンドの例

MetalLB と DHCP

gcloud container vmware clusters create user-cluster-1 \
    --project=example-project-12345 \
    --location=us-west1 \
    --admin-cluster-membership=projects/example-project-12345/locations/us-west1/memberships/admin-cluster-1 \
    --version=1.30.0-gke.1930 \
    --admin-users=sara@example.com \
    --admin-users=amal@example.com \
    --enable-dhcp \
    --service-address-cidr-blocks=10.96.0.0/20 \
    --pod-address-cidr-blocks=192.168.0.0/16 \
    --metal-lb-config-address-pools='pool=lb-pool-1,manual-assign=False,avoid-buggy-ips=True,addresses=192.0.2.0/26;pool=lb-ingress-vip-pool,manual-assign=True,addresses=198.51.100.1/32' \
    --enable-control-plane-v2 \
    --control-plane-vip=203.0.113.1 \
    --ingress-vip=198.51.100.1

--metal-lb-config-address-pools フラグの説明については、ロードバランサをご覧ください。

MetalLB と静的 IP

gcloud container vmware clusters create user-cluster-3 \
    --project=example-project-12345 \
    --location=europe-west1 \
    --admin-cluster-membership=projects/example-project-12345/locations/global/memberships/admin-cluster-1 \
    --version=1.30.0-gke.1930 \
    --admin-users=sara@example.com \
    --admin-users=amal@example.com \
    --static-ip-config-ip-blocks='gateway=192.0.2.254,netmask=255.255.255.0,ips=192.0.2.10 user-vm-1;192.0.2.11 user-vm-2' \
    --static-ip-config-ip-blocks='gateway=192.0.2.254,netmask=255.255.255.0,ips=192.0.2.12 user-vm-3;192.0.2.13 extra-vm' \
    --dns-servers=203.0.113.1,203.0.113.2  \
    --dns-search-domains=example.com,altostrat.com \
    --ntp-servers=203.0.113.3,203.0.113.4 \
    --service-address-cidr-blocks=10.96.0.0/20 \
    --pod-address-cidr-blocks=192.168.0.0/16 \
    --enable-control-plane-v2 \
    --control-plane-ip-block 'gateway=192.0.2.254,netmask=255.255.255.0,ips=198.51.100.1 cp-vm-1;198.51.100.2 cp-vm-2;198.51.100.3 cp-vm-3' \
    --replicas=3 \
    --metal-lb-config-address-pools='pool=lb-pool-1,manual-assign=False,avoid-buggy-ips=True,addresses=192.0.2.0/26;lb-ingress-vip-pool,manual-assign=True,addresses=198.51.100.1/32' \
    --control-plane-vip=172.16.20.61 \
    --ingress-vip=172.16.20.62

手動 LB と静的 IP

gcloud container vmware clusters create user-cluster-4 \
    --project=example-project-12345 \
    --location=asia-east1 \
    --admin-cluster-membership=projects/example-project-12345/locations/asia-east1/memberships/admin-cluster-1 \
    --version=1.30.0-gke.1930 \
    --admin-users=sara@example.com \
    --admin-users=amal@example.com \
    --static-ip-config-ip-blocks='gateway=192.0.2.254,netmask=255.255.255.0,ips=192.0.2.10 user-vm-1;192.0.2.11 user-vm-2';ips=192.0.2.12 user-vm-3;192.0.2.13 extra-vm'\
    --dns-servers=203.0.113.1,203.0.113.2  \
    --ntp-servers=203.0.113.3,203.0.113.4 \
    --service-address-cidr-blocks=10.96.0.0/20 \
    --pod-address-cidr-blocks=192.168.0.0/16 \
    --enable-control-plane-v2 \
    --control-plane-ip-block 'gateway=192.0.2.254,netmask=255.255.255.0,ips=198.51.100.1 cp-vm-1;198.51.100.2 cp-vm-2;198.51.100.3 cp-vm-3' \
    --replicas=3 \
    --control-plane-vip=192.0.2.60 \
    --ingress-vip=192.0.2.50 \
    --ingress-http-node-port=30243 \
    --ingress-https-node-port=30879

Terraform

始める前に

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

    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

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

  2. 利用可能なバージョンのリストを取得します。

    gcloud container vmware 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、Fleet サービス、Connect サービスが実行されるリージョンです。us-west1 または別のサポートされているリージョンを指定します。

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

    versions:
- isInstalled: true
  version: 1.14.3-gke.25
- version: 1.14.4-gke.54
- version: 1.15.0-gke.581

    ユーザー クラスタの作成に使用できるバージョンには、isInstalled=true というアノテーションが付いています。つまり、管理クラスタには、そのバージョンのユーザー クラスタを管理するために必要なバージョン特有のコンポーネントがあります。別の利用可能なバージョンでユーザー クラスタを作成する場合は、管理クラスタのバージョンよりも新しいバージョンをインストールするをご覧ください。

例

次の基本的な構成サンプルを使用して、バンドルされた MetalLB ロードバランサを使用するユーザー クラスタと 1 つのノードプールを作成できます。

詳細とその他の例については、google_gkeonprem_vmware_cluster リファレンス ドキュメントをご覧ください。

変数を terraform.tfvars に設定する

このサンプルは、main.tf に渡される変数ファイルの例を示しています。この例では、バンドルされた MetalLB ロードバランサを構成して、指定した DHCP サーバーから、クラスタノードが IP アドレスを取得できるようにしています。

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

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

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

    cp terraform.tfvars.sample terraform.tfvars

  3. terraform.tfvars でパラメータ値を変更します。

    project_id                  = "FLEET_HOST_PROJECT_ID"
region                      = "REGION"
admin_cluster_name          = "ADMIN_CLUSTER_NAME"
on_prem_version             = "VERSION"
admin_user_emails           = ["YOUR_EMAIL_ADDRESS", "ADMIN_2_EMAIL_ADDRESS"]
cluster_name                = "avmw-user-cluster-metallb"
control_plane_node_cpus     = 4
control_plane_node_memory   = 8192
control_plane_node_replicas = 3
control_plane_vip           = "CONTROL_PLANE_VIP"
ingress_vip                 = "INGRESS_VIP"
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）、Fleet サービス（gkehub.googleapis.com）、Connect サービス（gkeconnect.googleapis.com）が実行される Google Cloud リージョン。us-west1 または別のサポートされているリージョンを指定します。

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

      1. テキスト エディタで main.tf を開きます。
      2. 次のように admin_cluster_membership を検索します。
      admin_cluster_membership = "projects/${var.project_id}/locations/global/memberships/${var.admin_cluster_name}"
      1. global を管理クラスタが使用するリージョンに変更して、ファイルを保存します。

    • on_prem_version: ユーザー クラスタの Google Distributed Cloud のバージョン。通常は、管理クラスタと同じバージョンを指定します。より新しいバージョンを指定するには、管理クラスタのバージョンよりも新しいバージョンをインストールします。管理クラスタのバージョンがわからない場合は、gcloud container vmware clusters query-version-config を実行します。これは、管理クラスタのバージョンよりも新しいバージョンをインストールするの最初のステップです。

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

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

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

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

    • control_plane_node_cpus: ユーザー クラスタの各コントロール プレーン ノードの vCPU 数。最小値は 4 vCPU です。

    • control_plane_node_memory: ユーザー クラスタの各コントロール プレーンのメモリサイズ（MiB 単位）。最小値は 8192 で、4 の倍数にする必要があります。

    • control_plane_node_replicas: ユーザー クラスタのコントロール プレーン ノードの数。たとえば、開発環境用に 1 つのコントロール プレーン ノード、高可用性（HA）環境と本番環境用に 3 つのコントロール プレーン ノードを入力できます。

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

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

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

      • name: プールの名前。
      • addresses: CIDR 表記またはハイフン付き範囲形式のアドレス範囲。プール内の単一の IP アドレス（Ingress VIP など）を指定するには、CIDR 表記の /32 を使用します（例: 192.0.2.1/32）。

      サンプルの IP アドレスを実際の値に置き換え、必要に応じてアドレスプールを追加します。

  4. 変更を terraform.tfvars に保存します。main.tf でオプションを変更しない場合は、次のクラスタと 1 つのノードプールを作成するに進みます。

省略可: main.tf でクラスタの設定を構成する

このセクションでは、main.tf で可能なオプションの構成変更について説明します。変更を行う前に main.tf のバックアップを作成してください。

cp main.tf main.tf.bak

ワーカーノードの IP アドレスモード

デフォルトでは、main.tf は、ワーカーノードへの IP アドレスの割り当てに指定した DHCP サーバーを使用するようにクラスタを構成します。DHCP を構成するため、network_config ブロック内に dhcp_config マップが使用されています。ワーカーノードに静的 IP アドレスを提供するには、main.tf を次のように変更します。

  1. network_config ブロックを置き換え、static_ip_config ブロックを含めます。例:

      network_config {
    service_address_cidr_blocks = ["10.96.0.0/12"]
    pod_address_cidr_blocks = ["192.168.0.0/16"]
    host_config {
      dns_servers = ["10.254.41.1"]
      ntp_servers = ["216.239.35.8"]
    }
    static_ip_config {
      ip_blocks {
        netmask = "255.255.252.0"
        gateway = "10.251.31.254"
        ips {
          ip = "10.251.30.153"
          hostname = "vm-1"
        }
        ips {
          ip = "10.251.31.206"
          hostname = "vm-2"
        }
        ips {
          ip = "10.251.31.193"
          hostname = "vm-3"
        }
        ips {
          ip = "10.251.30.230"
          hostname = "vm-4"
        }
      }
    }
  }

  2. 以下を実際の値に置き換えます。

    • service_address_cidr_blocks: クラスタ内の Service に使用される IP アドレスの範囲（CIDR 形式）。/24 以上の範囲にする必要があります。

    • pod_address_cidr_blocks: クラスタ内の Pod に使用される IP アドレスの範囲（CIDR 形式）。/18 以上の範囲にする必要があります。

    • dns_servers: VM の DNS サーバーの IP アドレスのリスト。

    • ntp_servers: VM が使用する時刻サーバーの IP アドレスのリスト。

    • static_ip_config ブロックで、netmask と gateway の値をネットワークのアドレスに置き換えます。ip と hostname をワーカーノードの IP アドレスとホスト名に置き換えます。

Controlplane V2 を構成する

デフォルトでは、main.tf は、管理クラスタの 1 つ以上のノードで実行されるようにユーザー クラスタのコントロール プレーンを構成します（kubeception モデルと呼ばれます）。必要に応じて、Controlplane V2 を有効にできます。Controlplane V2 が有効になっている場合、ユーザー クラスタのコントロール プレーンは、そのユーザー クラスタの 1 つ以上のノードで実行されます。Controlplane V2 を構成するには、main.tf を次のように変更します。

  1. admin_cluster_membership の行の後に、次の行を追加します。

      enable_control_plane_v2 = "true"

  2. network_config ブロックに control_plane_v2_config マップを追加します。例:

      control_plane_v2_config {
    control_plane_ip_block {
      netmask = "255.255.252.0"
      gateway = "10.250.71.254"
      ips {
        ip = "10.250.68.54"
        hostname = "cpv2-vm1"
      }
      ips {
        ip = "10.250.68.128"
        hostname = "cpv2-vm2"
      }
      ips {
        ip = "10.250.71.50"
        hostname = "cpv2-vm3"
      }
    }
  }

  3. netmask と gateway の値をネットワークの IP アドレスに置き換えます。ip と hostname をコンソール プレーン ノードの IP アドレスに置き換えます。

クラスタと 1 つのノードプールを作成する

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

    terraform init

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

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

    terraform plan

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

    terraform apply

    ユーザー クラスタの作成には 15 分以上かかり、ノードプールの作成にさらに 15 分かかります。クラスタは、Google Cloud コンソールの [GKE クラスタ] ページで確認できます。

トラブルシューティング

クラスタの作成とアップグレードに対するトラブルシューティングをご覧ください。

次のステップ