In diesem Dokument wird gezeigt, wie Sie einen Nutzercluster erstellen, der ein neues Installationsmodell verwendet, das als Vorschaufeature in Version 1.13 von Anthos-Clustern auf VMware (GKE On-Prem) verfügbar ist.
Was ist Kubeception?
Mit dem Begriff kubeception wird die Idee vermittelt, dass ein Kubernetes-Cluster zum Erstellen und Verwalten anderer Kubernetes-Cluster verwendet wird. Im Kontext von Anthos-Clustern auf VMware bezieht sich kubeception auf den Fall, in dem die Steuerungsebene für einen Nutzercluster auf einem oder mehreren Knoten in einem Administratorcluster ausgeführt wird.
Ab Version 1.13.0 haben Sie die Möglichkeit, die Steuerungsebene für einen Nutzercluster auf einem oder mehreren Knoten im Nutzercluster selbst auszuführen. In früheren Versionen von Anthos-Clustern auf VMware war kubeception die einzige Option. Das heißt, alle Nutzercluster hatten ihre Steuerungsebenen im Administratorcluster.
Das neue Installationsmodell bietet architektonische Konsistenz zwischen Administrator- und Nutzerclustern und entkoppelt den Nutzercluster vom Administratorcluster. Dies ist bei Szenarien wie dem Ausführen von Clustern an verschiedenen geografischen Standorten ein Vorteil.
Hinweis
Sie benötigen einen Administratorcluster und die Administratorclusterversion muss 1.13.0 oder höher sein.
IP-Adressen planen
Beachten Sie beim Planen der IP-Adressen für Ihren Nutzercluster die folgenden Anforderungen für das neue Installationsmodell:
Die Knoten der Steuerungsebene für Ihren Nutzercluster müssen die IP-Adressen aus einer Liste der von Ihnen angegebenen statischen Adressen abrufen. Dies ist auch dann der Fall, wenn die Worker-Knoten ihre Adressen von einem DHCP-Server abrufen. Sie benötigen drei Knoten der Steuerungsebene für einen Hochverfügbarkeits-Nutzercluster (HA), aber nur einen Knoten der Steuerungsebene für einen Nicht-HA-Nutzercluster.
Die Knoten der Nutzercluster-Steuerungsebene müssen sich im selben VLAN wie die Worker-Knoten des Nutzerclusters befinden. Dies steht im Gegensatz zum Kubeception-Modell.
Die virtuelle IP-Adresse der Nutzercluster-Steuerungsebene muss sich im selben VLAN wie die Nutzercluster-Worker-Knoten und die Knoten der Nutzercluster-Steuerungsebene befinden. Dies steht im Gegensatz zum Kubeception-Modell.
vSphere-Umgebung planen
Die Administratorcluster-Konfigurationsdatei und die Nutzercluster-Konfigurationsdatei haben beide den Abschnitt vCenter, in dem Sie die vSphere-Ressourcen angeben können, die der Administrator oder Nutzercluster verwenden soll.
Bei einem Nutzercluster müssen Sie den Abschnitt vCenter nicht ausfüllen, da ein Nutzercluster standardmäßig dieselben vSphere-Ressourcen wie der Administratorcluster verwendet.
Wenn Sie jedoch möchten, dass Ihr Nutzercluster vSphere-Ressourcen verwendet, die Sie nicht für den Administratorcluster angegeben haben, können Sie im Abschnitt vCenter der Nutzercluster-Konfigurationsdatei Felder Ihrer Wahl ausfüllen. Weitere Informationen finden Sie unter vSphere-Objekthierarchie einrichten.
Im neuen Installationsmodell befinden sich die Knoten der Steuerungsebene für den Nutzercluster im Nutzercluster selbst. Daher verwenden die Knoten der Steuerungsebene die vSphere-Ressourcen, die in der Konfigurationsdatei des Nutzerclusters angegeben sind. Angenommen, Sie geben datacenter-1 für den Administratorcluster und datacenter-2 für den Nutzercluster an. Die Knoten der Steuerungsebene für Ihren Nutzercluster befinden sich in datacenter-2.
Anti-Affinitätsgruppen
Die Administratorcluster-Konfigurationsdatei und die Nutzercluster-Konfigurationsdatei haben beide das Feld antiAffinityGroups.enabled, das Sie auf true oder false festlegen können.
Im neuen Installationsmodell werden die Knoten der Steuerungsebene für den Nutzercluster gemäß dem Wert antiAffinityGroups.enabled in der Konfigurationsdatei des Nutzerclusters verteilt.
Im Gegensatz dazu werden bei dem Kubeception-Modell die Knoten der Steuerungsebene für den Nutzercluster gemäß dem Wert antiAffinityGroups.enabled in der Konfigurationsdatei des Administratorclusters verteilt.
Beispiel
Hier ein Beispiel für einen Nutzercluster mit den folgenden Eigenschaften:
Es gibt drei Worker-Knoten.
Die Worker-Knoten haben statische IP-Adressen.
Es gibt drei Knoten der Steuerungsebene. Das ist ein Hochverfügbarkeitscluster.
Der Load-Balancer ist MetalLB.
Der Nutzercluster verwendet dieselben vSphere-Ressourcen wie der Administratorcluster.
Das folgende Diagramm veranschaulicht das Netzwerk für die Administrator- und Nutzercluster:
Im Folgenden finden Sie ein Beispiel für eine IP-Blockdatei und einen Teil einer Nutzercluster-Konfigurationsdatei.
Nutzer-IPblocker.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
Dies sind die wichtigsten Punkte, die im vorherigen Beispiel zu verstehen sind:
Die statischen IP-Adressen für die Worker-Knoten werden in einer IP-Blockdatei angegeben. Die IP-Blockdatei hat vier Adressen, obwohl es nur drei Worker-Knoten gibt. Die zusätzliche IP-Adresse wird während des Clusterupgrades, -updates und der automatischen Reparatur benötigt.
Die statischen IP-Adressen für die drei Knoten der Steuerungsebene werden im Abschnitt
network.controlPlaneIPBlockder Konfigurationsdatei des Nutzerclusters angegeben. In diesem Block ist keine zusätzliche IP-Adresse erforderlich.Das Feld
masterNode.replicasist auf3gesetzt.Die virtuelle IP-Adresse der Steuerungsebene und die virtuelle IP-Adresse für eingehenden Traffic befinden sich beide im selben VLAN wie die Knoten der Worker und der Knoten der Steuerungsebene.
Die virtuellen IP-Adressen, die für Dienste vom Typ Balancer reserviert werden, sind im Abschnitt
loadBalancer.metalLB.addressPoolsder Konfigurationsdatei des Nutzerclusters angegeben. Diese VIPs befinden sich im selben VLAN wie die Worker-Knoten und die Knoten der Steuerungsebene.Die Konfigurationsdatei des Nutzerclusters enthält keinen
vCenter-Abschnitt. Der Nutzercluster verwendet daher dieselben vSphere-Ressourcen wie der Administratorcluster.
Firewallregeln erstellen
Erstellen Sie bei Bedarf zusätzlich zu den standardmäßigen Firewallregeln die folgenden Firewallregeln:
From |
Quellport |
To |
Dst-Port |
Protokoll |
Beschreibung |
|---|---|---|---|---|---|
|
Administratorcluster-Knoten |
Alle |
VIP der Nutzercluster-Steuerungsebene |
443 |
https |
Erlauben, dass Knoten und Pods im Administratorcluster mit dem Kubernetes API-Server des Nutzerclusters kommunizieren. |
|
Administratorcluster-Knoten |
Alle |
Knoten der Steuerungsebene des Nutzerclusters |
443 |
https |
Zulassen, dass Knoten und Pods im Administratorcluster mit dem Kubernetes API-Server des Nutzerclusters über die IP-Adresse eines Knotens der Steuerungsebene eines Nutzerclusters kommunizieren. |
|
Administratorcluster-Knoten |
Alle |
Nutzercluster- vCenter-Server |
443 |
https |
Erlauben Sie dem Administratorcluster, den Lebenszyklus des Nutzerclusters zu verwalten. Erforderlich, wenn Sie einen Wert für vCenter.address angegeben haben, der sich von der vCenter-Adresse in der Konfigurationsdatei des Administratorclusters unterscheidet. |
|
Knoten der Steuerungsebene des Nutzerclusters |
1024 – 65535 |
Lokale Docker-Registry |
Hängt von Ihrer Registry ab |
TCP/https |
Erforderlich, wenn Sie in Ihrer Konfigurationsdatei für den Administratorcluster eine private Registry angegeben haben. |
Nutzercluster mit dem neuen Modell erstellen
In diesem Abschnitt wird gezeigt, wie Sie einen Nutzercluster erstellen, der das neue Installationsmodell verwendet. In diesem Beispiel verwendet der Nutzercluster dieselbe Instanz von vCenter Server wie der Administratorcluster.
Folgen Sie der Anleitung unter Nutzercluster erstellen.
Beachten Sie beim Ausfüllen der Nutzercluster-Konfigurationsdatei Folgendes:
Setzen Sie
kubeceptionauffalse.Geben Sie keinen Wert für
vCenter.addressan.Füllen Sie den Abschnitt
network.controlPlaneIPBlockaus. Wenn Sie einen HA-Nutzercluster haben möchten, geben Sie drei IP-Adressen an. Geben Sie andernfalls eine IP-Adresse an.
Prüfen Sie bei der Ausführung Ihres Nutzerclusters, ob die Steuerungsebene auf einem oder drei Knoten im Nutzercluster ausgeführt wird:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get nodes
Ersetzen Sie USER_CLUSTER_KUBECONFIG durch den Pfad der kubeconfig-Datei des Nutzerclusters.
Die Ausgabe zeigt einen oder drei Knoten der Steuerungsebene zusammen mit den Worker-Knoten. Beispiel:
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
Prüfen Sie, ob die Steuerungsebene für den Nutzercluster im Administratorcluster nicht ausgeführt wird:
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get nodes --output wide
Ersetzen Sie ADMIN_CLUSTER_KUBECONFIG durch den Pfad der SavedModel-Datei des Administratorclusters.
Die Ausgabe zeigt einen Knoten der Steuerungsebene für den Administratorcluster selbst, aber keine Knoten der Steuerungsebene für den Nutzercluster. Beispiel:
admin-vm-1 Ready control-plane,master 82m admin-vm-2 Ready 71m admin-vm-3 Ready 71m
Nutzercluster aktualisieren
Folgen Sie der Anleitung unter Anthos-Cluster auf VMware aktualisieren.
Beachten Sie, dass beim Upgrade eines Nutzerclusters mit dem neuen Installationsmodell der gesamte Nutzercluster aktualisiert wird, einschließlich der Knoten der Nutzersteuerungsebene.
Im Gegensatz dazu werden bei Nutzerclustern, die mit dem kubeception-Modell bereitgestellt werden, für die Knoten der Steuerungsebene während des Nutzercluster-Upgrades keine Upgrades durchgeführt. Sie werden erst nach dem Administratorcluster-Upgrade aktualisiert.
Nutzercluster löschen
So löschen Sie einen Nutzercluster:
gkectl delete cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --cluster USER_CLUSTER
Ersetzen Sie USER_CLUSTER durch den Namen des Nutzerclusters.
Wenn Sie einen Nutzercluster löschen, der das neue Installationsmodell verwendet, werden die Datenlaufwerke des Clusters nicht automatisch gelöscht. Sie müssen die Datenlaufwerke also manuell löschen. Ein Hochverfügbarkeitscluster hat drei Datenlaufwerke und ein Nicht-HA-Cluster hat ein Datenlaufwerk.
Die Datenlaufwerke für den Nutzercluster befinden sich an einem dieser Speicherorte:
ADMIN_CLUSTER/USER_CLUSTER/
ADMIN_DISK_FOLDER/ADMIN_CLUSTER/USER_CLUSTER/
Ersetzen Sie ADMIN_CLUSTER durch den Namen des Administratorclusters.
Wenn Sie im Feld vCenter.dataDisk der Konfigurationsdatei des Administratorclusters einen Ordner angegeben haben, ersetzen Sie ADMIN_DISK_FOLDER durch den Namen des Ordners.
Bei einem Nicht-HA-Cluster hat das Datenlaufwerk den Namen USER_CLUSTER-0-data.vmdk.
Für einen Hochverfügbarkeitscluster haben die Datenlaufwerke einen Namen:
- USER_CLUSTER-0-data.vmdk.
- USER_CLUSTER-1-data.vmdk.
- USER_CLUSTER-2-data.vmdk.
Sie können die Datenlaufwerke mit dem vSphere-Client löschen.
Nutzercluster mit eigenem vCenter-Server erstellen
In bestimmten Situationen ist es sinnvoll, einen Nutzercluster zu erstellen, der eine eigene Instanz von vCenter Server verwendet. Das bedeutet, dass der Administratorcluster und ein zugehöriger Nutzercluster unterschiedliche Instanzen von vCenter Server verwenden.
In einem Edge-Standort möchten Sie beispielsweise, dass eine physische Maschine mit vCenter Server und eine oder mehrere physische Maschinen mit ESXi ausgeführt werden kann. Sie können dann Ihre lokale vCenter-Instanz verwenden, um eine vSphere-Objekthierarchie zu erstellen, die Rechenzentren, Cluster, Ressourcenpools, Datenspeicher und Ordner enthält.
Folgen Sie der Anleitung unter Nutzercluster mit dem neuen Modell erstellen.
Füllen Sie zusätzlich zu den Schritten in diesem Abschnitt den gesamten Abschnitt vCenter der Konfigurationsdatei für den Nutzercluster aus. Geben Sie insbesondere einen Wert für vCenter.address an, der sich von der vCenter Server-Adresse unterscheidet, die Sie in der Konfigurationsdatei des Administratorclusters angegeben haben.
Beispiel
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"
Fehlerbehebung
Siehe Fehlerbehebung beim Erstellen und Upgraden von Clustern.