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

Google Distributed Cloud では、ワークロードは 1 つ以上のユーザー クラスタで実行されます。このドキュメントでは、ユーザー クラスタを作成する方法について説明します。

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

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

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

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

始める前に

  • まだそれを行っていない場合は、次のドキュメントの説明のとおりに Google Cloud リソースを設定します。

    フリートホスト プロジェクトを設定するときには、ツールの選択に留意してください。それは、GKE On-Prem API クライアントのいずれかを選択した場合は、有効にする必要がある追加の API があるためです。

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

    GKE On-Prem API クライアントのいずれかを使用するを選んだ場合は、管理クラスタのために監査ロギングとCloud ロギングを有効にする必要があります。

  • インストールするユーザー クラスタのバージョンを決定します。ユーザー クラスタを作成する場合は、通常、管理クラスタのバージョンと一致するバージョンをインストールします。ただし、それ以降のパッチ バージョンまたは 1 つ以降のマイナー バージョンをインストールできます。詳細については、管理クラスタのバージョンより新しいバージョンをインストールするをご覧ください。

  • ユーザー クラスタでコントロール プレーン V2 を有効にするかどうかを検討します。コントロール プレーン V2 が有効になっている場合、ユーザー クラスタのコントロール プレーンは、ユーザー クラスタ自体の 1 つ以上のノードで実行されます。コントロール プレーン 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.29.100-gke.248 のようにします。

enableControlplaneV2

コントロール プレーン V2 が有効になっているユーザー クラスタを作成するには、enableControlplaneV2 を true に設定します。

コントロール プレーン V2 が有効になっている場合、ユーザー クラスタのコントロール プレーンはユーザー クラスタ自体のノードで実行されます。コントロール プレーン 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 Server アドレスとは異なる vCenter.address の値を指定します。次に例を示します。

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.29.100-gke.248
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 アドレスは必要ありません。

  • コントロール プレーン V2 が有効になっています。

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

  • コントロール プレーン VIP と 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.29.100-gke.248-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 コンソールで、[GKE on VMware クラスタを作成する] ページに移動します。

    [GKE on VMware クラスタを作成する] に移動する

  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. クラスタ作成者には、クラスタに対するクラスタ管理者権限が付与されます。必要に応じて、[承認] セクションの [クラスタ管理者ユーザー] フィールドに、クラスタを管理する別のユーザーのメールアドレスを入力します。

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

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

コントロール プレーン

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

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

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

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

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

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

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

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

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

ネットワーキング

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

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

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

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

  2. [DHCP] を選択した場合は、次の手順にスキップして [Service と Pod の CIDR] を指定します。[静的 IP モード] で、次の情報を入力します。

    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 の次のアドレス範囲がコンソールにより指定されます。

    • サービス 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. 上り（内向き）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 アドレスが上り（内向き）VIP と同じ IP アドレス範囲でない場合は、[+ IP アドレス範囲を追加] をクリックして別のアドレスを入力します。

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

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

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

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

    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. [内向き HTTP ノードポート] フィールドに、内向きプロキシへの HTTP トラフィックの nodePort 値を入力します。

  4. [内向き HTTPS ノードポート] フィールドに、内向きプロキシへの 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. [ノードプールのデフォルト] セクションで、次の操作を行います。

    1. [ノードプール名] を入力するか、名前として「default-pool」を使用します。
    2. プール内の各ノードの vCPU の数（ユーザー クラスタ ワーカーあたりの最小値は 4）を入力します。
    3. プール内の各ノードのメモリサイズをメガバイト（MiB）単位で入力します（ユーザー クラスタのワーカーノードあたり最小 8,192 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

    ロケーションには、フリート サービスと接続サービスが実行されるロケーションを指定します。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 とフリート サービスと 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 というアノテーションが付いています。つまり、管理クラスタには、そのバージョンのユーザー クラスタを管理するために必要なバージョン特有のコンポーネントがあります。別の利用可能なバージョンでユーザー クラスタを作成する場合は、管理クラスタのバージョンよりも新しいバージョンをインストールするをご覧ください。

例

次の例は、さまざまなロードバランサでユーザー クラスタを作成する方法を示しています。使用可能なロード バランシング オプションの詳細については、ロードバランサの概要をご覧ください。

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

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

MetalLB と DHCP

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

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

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=SERVICE_CIDR_BLOCK \
    --pod-address-cidr-blocks=POD_CIDR_BLOCK \
    --metal-lb-config-address-pools='pool=NAME,avoid-buggy-ips=True|False,manual-assign=True|False,addresses=IP_ADDRESS_RANGE_1;IP_ADDRESS_RANGE_2;...' \
    --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）、フリート サービス（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: ユーザー クラスタの GKE on VMware のバージョン。
  • 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 ロールが付与されます。このロールは、すべての名前空間で、クラスタのすべてのリソースに対する完全アクセス権を付与します。

  • 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 コントローラがこのプールから Service に IP アドレスを自動的に割り当てないようにする場合は、これを 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 アドレスを割り当てる方法を示します。

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

--admin-cluster-membership フラグの ADMIN_CLUSTER_NAME プレースホルダを入力する必要がある場合は、必ずスクロールしてください。この例では、完全指定の管理クラスタ名を使用しているため、--admin-cluster-membership-location と --admin-cluster-membership-project を指定する必要はありません。

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=SERVICE_CIDR_BLOCK \
    --pod-address-cidr-blocks=POD_CIDR_BLOCK \
    --metal-lb-config-address-pools='pool=NAME,avoid-buggy-ips=True|False,manual-assign=True|False,addresses=IP_ADDRESS_RANGE_1;IP_ADDRESS_RANGE_2;...' \
    --control-plane-vip=CONTROL_PLANE_VIP \
    --ingress-vip=INGRESS_VIP \
    --static-ip-config-ip-blocks='gateway=GATEWAY,netmask=NETMASK,ips=IP_ADDRESS_1;IP_ADDRESS_2 HOST_2;...' \
    --dns-servers=DNS_SERVER,... \
    --dns-search-domains=DNS_SEARCH_DOMAIN,... \
    --ntp-servers=NTP_SERVER,...

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

  • 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 でクラスタが一意に識別されます。

  • VERSION: ユーザー クラスタの GKE on VMware のバージョン。
  • 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 ロールが付与されます。このロールは、すべての名前空間で、クラスタのすべてのリソースに対する完全アクセス権を付与します。

  • 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 コントローラがこのプールから Service に IP アドレスを自動的に割り当てないようにする場合は、これを 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 アドレスとホスト名をスペースで区切ります。ホスト名を指定しない場合、GKE on VMware はホスト名として 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 アドレスのカンマ区切りのリスト。

F5 BIG-IP と DHCP

この例では、F5 BIG-IP ロードバランサを使用してユーザー クラスタを作成し、DHCP サーバーを使用してクラスタノードの IP アドレスを取得する方法を示します。

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

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=SERVICE_CIDR_BLOCK \
    --pod-address-cidr-blocks=POD_CIDR_BLOCK \
    --f5-config-address=F5_CONFIG_ADDRESS \
    --f5-config-partition=F5_CONFIG_PARTITION \
    --f5-config-snat-pool=F5_CONFIG_SNAT_POOL \
    --control-plane-vipCONTROL_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）、フリート サービス（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: ユーザー クラスタの GKE on VMware のバージョン。
  • 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 ロールが付与されます。このロールは、すべての名前空間で、クラスタのすべてのリソースに対する完全アクセス権を付与します。

  • 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

  • F5_CONFIG_ADDRESS: F5 BIG-IP ロードバランサのアドレス。

  • F5_CONFIG_PARTITION: ユーザー クラスタ用に作成した BIG-IP パーティションの名前。

  • F5_CONFIG_SNAT_POOL: SNAT プールの名前（該当する場合）。

  • 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 アドレスを設定する場合や、手動ロード バランシングを設定する場合は、このフラグを指定しないでください。

手動 LB と静的 IP

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

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

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=SERVICE_CIDR_BLOCK \
    --pod-address-cidr-blocks=POD_CIDR_BLOCK \
    --control-plane-vip=CONTROL_PLANE_VIP \
    --control-plane-node-port=CONTROL_PLANE_NODE_PORT \
    --ingress-vip=INGRESS_VIP \
    --ingress-http-node-port=INGRESS_HTTP_NODE_PORT \
    --ingress-https-node-port=INGRESS_HTTPS_NODE_PORT \
    --konnectivity-server-node-port=KONNECTIVITY_SERVER_NODE_PORT

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

  • 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 でクラスタが一意に識別されます。

  • VERSION: ユーザー クラスタの GKE on VMware のバージョン。
  • 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 ロールが付与されます。このロールは、すべての名前空間で、クラスタのすべてのリソースに対する完全アクセス権を付与します。

  • 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

  • CONTROL_PLANE_NODE_PORT: Kubernetes API サーバーの nodePort 値。

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

    例: --ingress-vip=203.0.113.4

  • INGRESS_HTTP_NODE_PORT: 内向きプロキシへの HTTP トラフィックの nodePort 値。

  • INGRESS_HTTPS_NODE_PORT: Ingress プロキシへの HTTPS トラフィックの nodePort 値

  • KONNECTIVITY_SERVER_NODE_PORT: Konnectivity サーバーの nodePort 値。

  • --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 アドレスとホスト名をスペースで区切ります。ホスト名を指定しない場合、GKE on VMware はホスト名として 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: コントロール プレーン V2 を有効にする場合は、--enable-control-plane-v2 を指定します。コントロール プレーン V2 が有効になっている場合、ユーザー クラスタのコントロール プレーンは、ユーザー クラスタ自体の 1 つ以上のノードで実行されます。デフォルトでは、ユーザー クラスタのコントロール プレーンは管理クラスタの 1 つ以上のノードで実行されます（kubeception モデルと呼ばれます）。コントロール プレーン V2 が有効になっている場合、--cpus と --memory の値はユーザー クラスタ内のコントロール プレーン ノードに適用されます。ノードの数は、--control-plane-ip-block に入力する IP アドレスの数によって決まります。コントロール プレーン V2 が有効になっていない場合、--cpus、--memory、--replicas の値は管理クラスタ内のコントロール プレーン ノードに適用されます。管理クラスタに十分な IP アドレスを確保するようにしてください。

    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 リファレンスをご覧ください。

    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 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/global/memberships/admin-cluster-1 \
    --version=1.29.100-gke.248 \
    --admin-users=sara@example.com \
    --admin-users=amal@example.com \
    --enable-dhcp \
    --service-address-cidr-blocks=10.96.232.0/24 \
    --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=10.251.133.0/24;10.251.134.80/32;10.251.134.81/32' \
    --metal-lb-config-address-pools='pool=lb-pool-2,manual-assign=True,addresses=172.16.20.62/32' \
    --control-plane-vip=172.16.20.61 \
    --ingress-vip=172.16.20.62

--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.29.100-gke.248 \
    --admin-users=sara@example.com \
    --admin-users=amal@example.com \
    --static-ip-config-ip-blocks='gateway=172.16.23.254,netmask=255.255.252.0,ips=172.16.20.10 user-vm-1;172.16.20.11 user-vm-2' \
    --static-ip-config-ip-blocks='gateway=172.16.23.255,netmask=255.255.252.0,ips=172.16.20.12 user-vm-3;172.16.20.13 extra-vm' \
    --dns-servers=203.0.113.1,198.51.100.1 \
    --dns-search-domains=example.com,altostrat.com \
    --ntp-servers=216.239.35.4,216.239.35.5 \
    --service-address-cidr-blocks=10.96.232.0/24 \
    --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=10.251.133.0/24;10.251.134.80/32;10.251.134.81/32' \
    --metal-lb-config-address-pools='pool=lb-pool-2,manual-assign=True,addresses=172.16.20.62/32' \
    --control-plane-vip=172.16.20.61 \
    --ingress-vip=172.16.20.62

F5 BIG-IP と DHCP

gcloud container vmware clusters create user-cluster-2 \
    --project=example-project-12345 \
    --location=us-west1 \
    --admin-cluster-membership=projects/example-project-12345/locations/global/memberships/admin-cluster-1 \
    --version=1.29.100-gke.248 \
    --admin-users=sara@example.com \
    --admin-users=amal@example.com \
    --enable-dhcp \
    --service-address-cidr-blocks=10.96.232.0/24 \
    --pod-address-cidr-blocks=192.168.0.0/16 \
    --f5-config-address=203.0.113.2 \
    --f5-config-partition=my-f5-admin-partition \
    --control-plane-vip=172.16.20.61 \
    --ingress-vip=172.16.20.62

F5 フラグの詳細については、ロードバランサをご覧ください。

手動 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/global/memberships/admin-cluster-1 \
    --version=1.29.100-gke.248 \
    --admin-users=sara@example.com \
    --admin-users=amal@example.com \
    --static-ip-config-ip-blocks='gateway=172.16.23.254,netmask=255.255.252.0,ips=172.16.20.10 user-vm-1;172.16.20.11 user-vm-2' \
    --static-ip-config-ip-blocks='gateway=172.16.23.255,netmask=255.255.252.0,ips=172.16.20.12 user-vm-3;172.16.20.13 extra-vm' \
    --dns-servers=203.0.113.1,198.51.100.1  \
    --ntp-servers=216.239.35.4,216.239.35.5 \
    --service-address-cidr-blocks=10.96.232.0/24 \
    --pod-address-cidr-blocks=192.168.0.0/16 \
    --control-plane-vip=172.16.20.61 \
    --control-plane-node-port=30968 \
    --ingress-vip=172.16.20.62 \
    --ingress-http-node-port=32527 \
    --ingress-https-node-port=30139 \
    --konnectivity-server-node-port=30969

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

    ロケーションには、フリート サービスと接続サービスが実行されるロケーションを指定します。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 とフリート サービスと 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）、フリート サービス（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 アドレスとホスト名に置き換えます。

コントロール プレーン V2 を構成する

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

    terraform init

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

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

    terraform plan

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

    terraform apply

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

管理クラスタのバージョンより新しいバージョンをインストールする

管理クラスタは、異なるバージョンのユーザー クラスタを管理できます。管理クラスタよりも新しいバージョンのユーザー クラスタを作成する場合は、次のように、管理クラスタがそのバージョンのユーザー クラスタを管理するために必要なコンポーネントをダウンロードしてデプロイする必要があります。

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

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

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

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

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

    • REGION: GKE On-Prem API が実行される Google Cloud リージョン。これは、ユーザー クラスタの作成時に指定するリージョンです。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 というアノテーションが付けられます。

  2. まだ行っていない場合は、GKE On-Prem API に管理クラスタを登録します。クラスタが GKE On-Prem API に登録された後は、この手順を繰り返す必要はありません。

  3. 新しいバージョンのコンポーネントをダウンロードして、管理クラスタにデプロイします。

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

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

トラブルシューティング

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

次のステップ