コントロール プレーン V2 でユーザー クラスタを作成する

このドキュメントでは、コントロール プレーン V2 を有効にしてユーザー クラスタを作成する方法について説明します。

kubeception とは

kubeception という用語は、Kubernetes クラスタを使用して他の Kubernetes クラスタを作成および管理するというコンセプトを表すために使用されます。GKE on VMware のコンテキストでは、kubeception はユーザー クラスタのコントロール プレーンが管理クラスタ内の 1 つ以上のノードで実行される場合を指します。

コントロール プレーン V2 では、ユーザー クラスタのコントロール プレーンはユーザー クラスタ自体の 1 つ以上のノードで実行されます。

コントロール プレーン V2 のメリットは次のとおりです。

  • 管理クラスタとユーザー クラスタ間のアーキテクチャの一貫性

  • 障害の分離。管理クラスタの障害がユーザー クラスタに影響することはありません。

  • 運用の分離。管理クラスタのアップグレードによるユーザー クラスタのダウンタイムは発生しません。

  • デプロイの分離。管理クラスタとユーザー クラスタを、異なる障害発生ドメインまたは地理的な場所に配置できます。たとえば、エッジ ロケーションのユーザー クラスタが、管理クラスタとは異なる地理的な場所にある場合があります。

準備

管理クラスタが必要で、管理クラスタのバージョンは 1.13.0 以降です。

要件

コントロール プレーン V2 が有効になっているユーザー クラスタ:

  • バンドル型 MetalLB ロードバランサを使用する必要があります
  • Dataplane V2 が有効になっている必要があります

IP アドレスを計画する

ユーザー クラスタの IP アドレスを計画する場合は、コントロール プレーン V2 のこれらの要件を考慮してください。

  • ユーザー クラスタのコントロール プレーン ノードは、指定する静的アドレスのリストから IP アドレスを取得する必要があります。これは、ワーカーノードが DHCP サーバーからアドレスを取得する場合でも当てはまります。高可用性（HA）ユーザー クラスタには 3 つのコントロール プレーン ノードが必要ですが、非 HA ユーザー クラスタにはコントロール プレーン ノードが 1 つだけ必要です。

  • ユーザー クラスタのコントロール プレーン ノードは、ユーザー クラスタのワーカーノードと同じ VLAN に存在する必要があります。これは kubeception モデルとは対照的です。

  • ユーザー クラスタのコントロール プレーン VIP は、ユーザー クラスタのワーカーノードおよびユーザー クラスタのコントロール プレーン ノードと同じ VLAN に存在する必要があります。これは、kubeception モデルとは対照的です。

vSphere 環境を計画する

管理クラスタ構成ファイルとユーザー クラスタ構成ファイルのどちらにも、管理クラスタまたはユーザー クラスタで使用する vSphere リソースを指定できる vCenter セクションがあります。

ユーザー クラスタの場合、管理クラスタと同じ vSphere リソースがデフォルトで使用されるため、vCenter セクションへの入力は不要です。しかし、管理クラスタで指定したものとは異なる vSphere リソースをユーザー クラスタで使用する場合は、ユーザー クラスタ構成ファイルの vCenter セクションで、任意のフィールドに値を入力できます。詳細については、vSphere オブジェクト階層の設定をご覧ください。

コントロール プレーン V2 では、ユーザー クラスタのコントロール プレーン ノードはユーザー クラスタ自体に含まれます。そのため、コントロール プレーン ノードは、ユーザー クラスタ構成ファイルで指定された vSphere リソースを使用します。たとえば、管理クラスタに datacenter-1 を指定し、ユーザー クラスタに datacenter-2 を指定したとします。ユーザー クラスタのコントロール プレーン ノードは、datacenter-2 にできます。

反アフィニティ グループ

管理クラスタ構成ファイルとユーザー クラスタ構成ファイルには、true または false に設定できる antiAffinityGroups.enabled フィールドがどちらにもあります。

コントロール プレーン V2 では、ユーザー クラスタのコントロール プレーン ノードは、ユーザー クラスタの構成ファイルの antiAffinityGroups.enabled 値に従って分散されます。

一方、kubeception モデルでは、ユーザー クラスタのコントロール プレーン ノードが管理クラスタ構成ファイルの antiAffinityGroups.enabled 値に従って分散されます。

例

ここでは、以下の特性を持つユーザー クラスタの例を示します。

  • 3 つのワーカーノードがあります。

  • ワーカーノードには静的 IP アドレスを試用しています。

  • コントロール プレーン ノードは 3 つあります。つまり、HA クラスタです。

  • ロードバランサは MetalLB です。

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

  • ユーザー クラスタは、管理クラスタと同じ vSphere リソースを使用します。

次の図では、管理クラスタとユーザー クラスタのネットワークを示します。

管理クラスタとユーザー クラスタ
管理クラスタとユーザー クラスタ（クリックして拡大）

次に、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

apiVersion: v1
kind: UserCluster
...
network:
  hostConfig:
    dnsServers:
    - "203.0.113.2"
    - "198.51.100.2"
    ntpServers:
    - "216.239.35.4"
  ipMode:
    type: "static"
    ipBlockFilePath: "user-ipblock.yaml"
  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"
...
enableControlplaneV2: true
enableDataplaneV2: true
masterNode:
  cpus: 4
  memoryMB: 8192
  replicas: 3
nodePools:
- name: "worker-node-pool"
  enableLoadBalancer: true

上記の例で理解しておくべき重要なポイントは、次のとおりです。

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

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

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

  • masterNode.replicas フィールドは 3 に設定されています。

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

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

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

コントロール プレーン V2 のファイアウォール ルール

標準のファイアウォール ルールに加えて、以下のファイアウォール ルールを作成します。

送信者

送信元ポート

終了日

宛先ポート

プロトコル

説明

管理クラスタノード

すべて

ユーザー クラスタ コントロール プレーン VIP

443

https

管理クラスタ内のノードと Pod が、ユーザー クラスタの Kubernetes API サーバーと通信することを許可します。

管理クラスタノード

すべて

ユーザー クラスタのコントロール プレーン ノード

443

https

管理クラスタ内のノードと Pod が、ユーザー クラスタ コントロール プレーン ノードの IP アドレスを使用して、ユーザー クラスタの Kubernetes API サーバーと通信することを許可します。

コントロール プレーン V2 が有効になっているユーザー クラスタには、以下の標準のファイアウォール ルールは必要ありません。

送信者

送信元ポート

終了日

宛先ポート

プロトコル

説明

管理クラスタのワーカーノード

すべて

ユーザー クラスタノード

22

SSH

SSH トンネル経由の API サーバーから kubelet への通信

ユーザー クラスタのワーカーノード

すべて

ユーザー クラスタ コントロール プレーン VIP

8132

GRPC

Konnectivity 接続

コントロール プレーン V2 が有効になっているユーザー クラスタを作成する

このセクションでは、コントロール プレーン V2 が有効になっているユーザー クラスタを作成する方法について説明します。この例では、ユーザー クラスタは管理クラスタと同じ vCenter Server インスタンスを使用します。

ユーザー クラスタの作成の手順を実行します。

ユーザー クラスタの構成ファイルに次のように入力します。

  • enableControlplaneV2 を true に設定する。

  • enableDataplaneV2 を true に設定する。

  • loadBalancer.kind を "MetalLB" に設定する

  • vCenter.address の値は指定しないでください。

  • network.controlPlaneIPBlock セクションに入力します。 HA ユーザー クラスタが必要な場合は、3 つの IP アドレスを指定します。それ以外の場合は、1 つの IP アドレスを指定します。

ユーザー クラスタが稼働しているときに、コントロール プレーンがユーザー クラスタ内の 1 つまたは 3 つのノードで実行されていることを確認します。

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get nodes

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

出力には、1 つまたは 3 つのコントロール プレーン ノードと、ワーカーノードが表示されます。 例:

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

ユーザー クラスタのコントロール プレーンが管理クラスタで実行されていないことを確認します。

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get nodes --output wide

ADMIN_CLUSTER_KUBECONFIG は、管理クラスタの kubeconfig ファイルへのパスに置き換えます。

出力には、管理クラスタ自体のコントロール プレーン ノードが表示されますが、ユーザー クラスタのコントロール プレーン ノードは表示されません。例:

admin-vm-1   Ready    control-plane,master   82m
admin-vm-2   Ready                           71m
admin-vm-3   Ready                           71m

USER_CLUSTER_NAME 名前空間の管理クラスタで実行されている Pod がないことを確認します。これは、管理クラスタの USER_CLUSTER_NAME 名前空間で実行されているコントロール プレーン Pod が複数ある kubeception モデルとは対照的です。

kubectl --kubeconfig kubeconfig get pods --namespace USER_CLUSTER_NAME

出力:

No resources found in ... namespace.

ユーザー クラスタで実行されているコントロール プレーン Pod があることを確認します。

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get pods\
    --namespace kube-system\
    --selector tier=control-plane

出力例:

clusterapi-controllers-5bbfb6bd9f-57gz8   3/3     Running   1
…
etcd-cp-vm-1                              1/1     Running   0
…
kube-apiserver-cp-vm-1                    1/1     Running   0
…
kube-controller-manager-cp-vm-1           1/1     Running   0
…
kube-scheduler-cp-vm-1                    1/1     Running   0

ノードへの SSH 接続

コントロール プレーン V2 でユーザー クラスタのコントロール プレーン ノードへの SSH 接続を行うには、ユーザー クラスタのワーカーノードへの接続に使用するのと同じ SSH 認証鍵を使用します。

これは、管理クラスタのワーカーノードへの接続に使用するのと同じ SSH 認証鍵を使用する kubeception ユーザー クラスタとは対照的です。

ユーザー クラスタをアップグレードする

Anthos clusters on VMware のアップグレードの手順を行います。

コントロール プレーン V2 が有効になっているユーザー クラスタをアップグレードすると、ユーザー コントロール プレーン ノードを含むユーザー クラスタ全体がアップグレードされることに注意してください。

対照的に、kubeception モデルでデプロイされたユーザー クラスタの場合、コントロール プレーン ノードはユーザー クラスタのアップグレード時にアップグレードが行われず、管理クラスタのアップグレードまでアップグレードされません。

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

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

gkectl delete cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --cluster USER_CLUSTER

USER_CLUSTER を、ユーザー クラスタの名前に置き換えます。

コントロール プレーン V2 が有効になっているユーザー クラスタを削除しても、クラスタのデータディスクは自動的には削除されません。そのため、データディスクを手動で削除する必要があります。HA クラスタには 3 つのデータディスクがあり、非 HA クラスタには 1 つのデータディスクがあります。

ユーザー クラスタのコントロール プレーン ノードのデータディスクは、ユーザー クラスタ構成ファイルの masterNode.vSphere.datastore フィールドで指定されたデータストアにあります。

ユーザー クラスタのデータディスクは、次のいずれかのロケーションにあります。

  • ADMIN_CLUSTER/USER_CLUSTER/

  • ADMIN_DISK_FOLDER/ADMIN_CLUSTER/USER_CLUSTER/

ADMIN_CLUSTER は、管理クラスタの名前に置き換えます。

管理クラスタ構成ファイルの vCenter.dataDisk フィールドでフォルダを指定した場合は、ADMIN_DISK_FOLDER をフォルダの名前に置き換えます。

非 HA クラスタの場合、データディスクの名前は USER_CLUSTER-0-data.vmdk です。

HA クラスタの場合、データディスクの名前は以下のとおりです。

  • USER_CLUSTER-0-data.vmdk。
  • USER_CLUSTER-1-data.vmdk。
  • USER_CLUSTER-2-data.vmdk。

vSphere クライアントを使用して、データディスクを削除できます。

独自の vCenter Server でユーザー クラスタを作成する

特定の状況では、vCenter Server の独自のインスタンスを使用したユーザー クラスタの作成が合理的なことがあります。つまり、管理クラスタと関連ユーザー クラスタは、vCenter Server の異なるインスタンスを使用します。

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

コントロール プレーン V2 が有効になっているユーザー クラスタを作成するの手順に従います。

そのセクションの手順に加えて、ユーザー クラスタ構成ファイルの 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"

ファイアウォール ルール

ユーザー クラスタに独自の vCenter Server がある場合は、標準のファイアウォール ルールと一般にコントロール プレーン V2 に必要なファイアウォール ルールに加えて、次のファイアウォール ルールを作成します。

送信者

送信元ポート

終了日

宛先ポート

プロトコル

説明

管理クラスタノード

すべて

ユーザー クラスタ vCenter Server

443

https

管理クラスタがユーザー クラスタのライフサイクルを管理することを許可します。管理クラスタ構成ファイルの vCenter アドレスと異なる値を vCenter.address に指定した場合は必須です。

トラブルシューティング

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

次のステップ