このドキュメントでは、Anthos clusters on VMware（GKE On-Prem）バージョン 1.13 でプレビュー機能として利用可能な、新しいインストール モデルを使用するユーザー クラスタを作成する方法を説明します。
kubeception とは
kubeception という用語は、Kubernetes クラスタが他の Kubernetes クラスタの作成と管理に使用されるというコンセプトを伝えるために使用されます。Anthos clusters on VMware のコンテキストでは、kubeception はユーザー クラスタのコントロール プレーンが管理クラスタ内の 1 つ以上のノードで実行される場合を指します。
バージョン 1.13.0 以降では、ユーザー クラスタのコントロール プレーンをユーザー クラスタ自体の 1 つ以上のノードで実行することができます。以前のバージョンの Anthos clusters on VMware では、kubeception が唯一のオプションでした。 つまり、すべてのユーザー クラスタには、管理クラスタにコントロール プレーンがありました。
新しいインストール モデルでは、管理クラスタとユーザー クラスタ間でアーキテクチャの整合性が高まり、ユーザー クラスタは管理クラスタから切り離されます。これは、異なる地理的サイトでクラスタを実行するようなシナリオにはメリットがあります。
始める前に
管理クラスタが必要であり、管理クラスタのバージョンは 1.13.0 以降である必要があります。
IP アドレスを計画する
ユーザー クラスタの IP アドレスを計画する場合は、新しいインストール モデルに関する次の要件に注意してください。
ユーザー クラスタのコントロール プレーン ノードは、指定した静的アドレスのリストから IP アドレスを取得する必要があります。これは、ワーカーノードが DHCP サーバーからアドレスを取得する場合でも同じです。高可用性（HA）ユーザー クラスタには 3 つのコントロール プレーン ノードが必要ですが、非 HA ユーザー クラスタにはコントロール プレーン ノードが 1 つだけ必要です。
ユーザー クラスタのコントロール プレーン ノードは、ユーザー クラスタのワーカーノードと同じ VLAN に存在する必要があります。これは kubeception モデルとは対照的です。
ユーザー クラスタ コントロール プレーン VIP は、ユーザー クラスタ ワーカーノードおよびユーザー クラスタ コントロール プレーン ノードと同じ VLAN にある必要があります。これは kubeception モデルとは対照的です。
vSphere 環境を計画する
管理クラスタ構成ファイルとユーザー クラスタ構成ファイルのどちらにも、管理クラスタまたはユーザー クラスタで使用する vSphere リソースを指定できる vCenter セクションがあります。
ユーザー クラスタの場合、管理クラスタと同じ vSphere リソースがデフォルトで使用されるため、vCenter セクションへの入力は不要です。しかし、管理クラスタで指定したものとは異なる vSphere リソースをユーザー クラスタで使用する場合は、ユーザー クラスタ構成ファイルの vCenter セクションで、任意のフィールドに値を入力できます。詳細については、vSphere オブジェクト階層の設定をご覧ください。
新しいインストール モデルでは、ユーザー クラスタのコントロール プレーン ノードはユーザー クラスタ自体にあります。そのため、コントロール プレーン ノードは、ユーザー クラスタ構成ファイルで指定された vSphere リソースを使用します。たとえば、管理クラスタに datacenter-1、ユーザー クラスタに datacenter-2 を指定したとします。ユーザー クラスタのコントロール プレーン ノードは、datacenter-2 にできます。
反アフィニティ グループ
管理クラスタ構成ファイルとユーザー クラスタ構成ファイルには、true または false に設定できる antiAffinityGroups.enabled フィールドがどちらにもあります。
新しいインストール モデルでは、ユーザー クラスタのコントロール プレーン ノードがユーザー クラスタ構成ファイルの antiAffinityGroups.enabled 値に従って分散されます。
一方、kubeception モデルでは、ユーザー クラスタのコントロール プレーン ノードが管理クラスタ構成ファイルの antiAffinityGroups.enabled 値に従って分散されます。
例
ここでは、次のような特性があるユーザー クラスタの例を示します。
3 つのワーカーノードがあります。
ワーカーノードには静的 IP アドレスがあります。
3 つのコントロール プレーン ノードがあります。つまり、HA クラスタです。
ロードバランサは MetalLB です。
ユーザー クラスタは、管理クラスタと同じ 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
...
kubeception: false
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"
...
masterNode:
cpus: 4
memoryMB: 8192
replicas: 3
nodePools:
- name: "worker-node-pool"
enableLoadBalancer: true
上記の例で理解しておくべき重要なポイントは、次のとおりです。
ワーカーノードの静的 IP アドレスは、IP ブロック ファイルに指定されています。その IP ブロック ファイルには、ワーカーノードが 3 つしかない場合でも 4 つのアドレスがあります。その追加の IP アドレスは、クラスタのアップグレード、更新、自動修復に必要なものです。
コントロール プレーン ノード 3 つの静的 IP アドレスは、ユーザー クラスタ構成ファイルの
network.controlPlaneIPBlockセクションで指定されます。このブロックに追加の IP アドレスは必要ありません。masterNode.replicasフィールドは3に設定されています。コントロール プレーン VIP と Ingress VIP は、どちらもワーカーノードとコントロール プレーン ノードと同じ VLAN にあります。
LoadBalancer タイプの Service 用に確保された VIP は、ユーザー クラスタ構成ファイルの
loadBalancer.metalLB.addressPoolsセクションで指定されています。これらの VIP は、ワーカーノードやコントロール プレーン ノードと同じ VLAN にあります。ユーザー クラスタの構成ファイルには、
vCenterセクションがありません。そのため、ユーザー クラスタは、管理クラスタと同じ vSphere リソースを使用します。
ファイアウォール ルールを作成する
標準のファイアウォール ルールに加えて、必要に応じて次のファイアウォール ルールを作成します。
開始日 |
送信元ポート |
終了日 |
宛先ポート |
プロトコル |
説明 |
|---|---|---|---|---|---|
|
管理クラスタノード |
すべて |
ユーザー クラスタ コントロール プレーン VIP |
443 |
https |
管理クラスタ内のノードと Pod が、ユーザー クラスタの Kubernetes API サーバーと通信することを許可します。 |
|
管理クラスタノード |
すべて |
ユーザー クラスタのコントロール プレーン ノード |
443 |
https |
管理クラスタ内のノードと Pod が、ユーザー クラスタ コントロール プレーン ノードの IP アドレスを使用して、ユーザー クラスタの Kubernetes API サーバーと通信することを許可します。 |
|
管理クラスタノード |
すべて |
ユーザー クラスタの vCenter Server |
443 |
https |
管理クラスタがユーザー クラスタのライフサイクルを管理することを許可します。管理クラスタ構成ファイルの vCenter アドレスと異なる値を vCenter.address に指定した場合は必須です。 |
|
ユーザー クラスタのコントロール プレーン ノード |
1024 - 65535 |
オンプレミスのローカル Docker レジストリ |
レジストリにより異なる |
TCP / https |
管理クラスタの構成ファイルで非公開レジストリを指定した場合は必須です。 |
新しいモデルを使用してユーザー クラスタを作成する
このセクションでは、新しいインストール モデルを使用するユーザー クラスタを作成する方法について説明します。この例では、ユーザー クラスタは、管理クラスタと同じ vCenter Server インスタンスを使用します。
ユーザー クラスタの作成の手順を実行します。
ユーザー クラスタの構成ファイルへの入力時に、次のことを行います。
kubeceptionをfalseに設定する。vCenter.addressの値は指定しないでください。network.controlPlaneIPBlockセクションに入力します。 HA ユーザー クラスタが必要な場合は、3 つの IP アドレスを指定します。それ以外の場合は、IP アドレスを 1 つ指定します。
ユーザー クラスタが実行されているときに、コントロール プレーンがユーザー クラスタ内の 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
ユーザー クラスタをアップグレードする
Anthos clusters on VMware のアップグレードの手順を行います。
なお、新しいインストール モデルを使用してユーザー クラスタをアップグレードすると、ユーザー コントロール プレーン ノードを含むユーザー クラスタ全体がアップグレードされます。
一方、kubeception モデルでデプロイされたユーザー クラスタの場合、コントロール プレーン ノードはユーザー クラスタのアップグレード中はアップグレードされず、管理クラスタのアップグレードまでアップグレードできません。
ユーザー クラスタを削除する
ユーザー クラスタを削除するには:
gkectl delete cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --cluster USER_CLUSTER
USER_CLUSTER は、ユーザー クラスタの名前に置き換えます。
新しいインストール モデルを使用するユーザー クラスタを削除しても、クラスタのデータディスクは自動的に削除されません。したがって、データディスクは手動で削除する必要があります。HA クラスタには 3 つのデータディスクがあり、非 HA クラスタには 1 つのデータディスクがあります。
ユーザー クラスタのデータディスクは、次のいずれかの場所にあります。
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 オブジェクト階層を作成できます。
新しいモデルを使用してユーザー クラスタを作成するの手順に従います。
このセクションに示されている手順に加えて、ユーザー クラスタ構成ファイルの 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"
トラブルシューティング
クラスタの作成とアップグレードに対するトラブルシューティングをご覧ください。