Diese Seite wurde von der Cloud Translation API übersetzt.

Nutzercluster erstellen

In GKE on VMware werden Ihre Arbeitslasten in einem oder mehreren Nutzerclustern ausgeführt. In diesem Dokument wird gezeigt, wie Sie einen Nutzercluster erstellen.

Es gibt mehrere Tools, mit denen Sie einen Nutzercluster erstellen können:

gkectl
Google Cloud Console
Google Cloud CLI
Terraform

Drei dieser Tools (Console, gcloud CLI und Terraform) sind Clients der GKE On-Prem API.

Informationen dazu, welches Tool Sie verwenden können, finden Sie unter Tool zum Verwalten des Clusterlebenszyklus auswählen.

Hinweise

Richten Sie Ihre Google Cloud-Ressourcen wie in diesen Dokumenten beschrieben ein, falls noch nicht geschehen:
Denken Sie beim Einrichten des Flotten-Hostprojekts an Ihr Tool, da Sie, wenn Sie sich für einen der GKE On-Prem API-Clients entschieden haben, zusätzliche APIs aktivieren müssen.
Bevor Sie einen Nutzercluster erstellen, benötigen Sie einen Administratorcluster, um den Nutzercluster zu verwalten. Erstellen Sie eine Administratorworkstation und einen Administratorcluster, falls noch nicht geschehen.

Wenn Sie einen der GKE On-Prem API-Clients verwenden, müssen Sie Audit-Logging und Cloud Logging für den Administratorcluster aktivieren.
Ermitteln Sie die Version des Nutzerclusters, den Sie installieren möchten. Wenn Sie einen Nutzercluster erstellen, installieren Sie in der Regel die Version, die der Version des Administratorclusters entspricht. Sie können jedoch eine spätere Patchversion oder eine neuere Nebenversion installieren. Weitere Informationen finden Sie unter Version des Administratorclusters installieren.
Überlegen Sie, ob Ihr Nutzercluster Controlplane V2 aktivieren soll. Wenn die Steuerungsebene V2 aktiviert ist, wird die Steuerungsebene für den Nutzercluster auf einem oder mehreren Knoten im Nutzercluster selbst ausgeführt. Es wird dringend empfohlen, Controlplane V2 zu aktivieren. Alternativ können Sie einen Nutzercluster erstellen, der kubeception verwendet. Im Fall von kubeception wird die Steuerungsebene für den Nutzercluster auf einem oder mehreren Knoten im Administratorcluster ausgeführt.
Prüfen Sie das Dokument zur Planung von IP-Adressen und achten Sie darauf, dass genügend IP-Adressen verfügbar sind.
Lesen Sie die Load-Balancing-Übersicht und prüfen Sie noch einmal, welche Art von Load-Balancer Sie verwenden möchten. Sie können den gebündelten MetalLB-Load-Balancer verwenden oder manuell einen Load-Balancer Ihrer Wahl konfigurieren. Für das manuelle Load-Balancing müssen Sie den Load-Balancer einrichten, bevor Sie Ihren Nutzercluster erstellen.
Überlegen Sie, wie viele Knotenpools Sie benötigen und welches Betriebssystem Sie in jedem Ihrer Pools ausführen möchten.
Überlegen Sie, ob Sie separate vSphere-Cluster für Ihren Administratorcluster und Ihre Nutzercluster verwenden und ob Sie separate Rechenzentren verwenden möchten. Überlegen Sie auch, ob Sie separate Instanzen von vCenter Server verwenden möchten.

Nutzercluster erstellen

gkectl

Verfahrensübersicht

Dies sind die wichtigsten Schritte beim Erstellen eines Nutzerclusters mit gkectl:

Verbindung zu Ihrer Administrator-Workstation herstellen

Die Administratorworkstation ist eine Maschine mit den erforderlichen Tools zum Erstellen eines Nutzerclusters.
Ihre Konfigurationsdateien ausfüllen

Geben Sie die Details für den neuen Cluster an. Füllen Sie dazu eine Nutzercluster-Konfigurationsdatei, eine Konfigurationsdatei für Anmeldedaten und möglicherweise eine IP-Blockdatei aus.
(Optional) Importieren Sie Betriebssystem-Images in vSphere und übertragen Sie Container-Images gegebenenfalls in die private Registry.

Führen Sie den Befehl „gkectl prepare“ aus.
Nutzercluster erstellen

Führen Sie gkectl create cluster aus, um einen Cluster zu erstellen, wie in der Konfigurationsdatei angegeben.
Prüfen Sie, ob Ihr Nutzercluster ausgeführt wird

Rufen Sie mit kubectl die Clusterknoten auf.

Am Ende dieses Verfahrens haben Sie einen laufenden Nutzercluster, in dem Sie Ihre Arbeitslasten bereitstellen können.

Wenn Sie VPC Service Controls verwenden, werden beim Ausführen einiger gkectl-Befehle wie "Validation Category: GCP - [UNKNOWN] GCP service: [Stackdriver] could not get GCP services" möglicherweise Fehler angezeigt. Fügen Sie Ihren Befehlen den Parameter --skip-validation-gcp hinzu, um diese Fehler zu vermeiden.

Ihre Konfigurationsdateien ausfüllen

Führen Sie diese Schritte auf Ihrer Administratorworkstation aus.

Als gkeadm die Administrator-Workstation erstellt hat, wurde eine zweite Konfigurationsdatei mit dem Namen user-cluster.yaml erzeugt. Diese Konfigurationsdatei dient zum Erstellen Ihres Nutzerclusters.

Machen Sie sich mit der Konfigurationsdatei vertraut, indem Sie sich das Dokument zur Nutzercluster-Konfigurationsdatei ansehen. Möglicherweise möchten Sie dieses Dokument in einem separaten Tab oder Fenster geöffnet lassen, da Sie sich beim Ausführen der folgenden Schritte darauf beziehen.

`name`

Geben Sie für das Feld name einen Namen Ihrer Wahl für den Nutzercluster an.

`gkeOnPremVersion`

Dieses Feld ist bereits für Sie ausgefüllt. Damit wird die Version von GKE on VMware angegeben. Beispiel: 1.28.400-gke.75.

`enableControlplaneV2`

Legen Sie zum Erstellen eines Nutzerclusters mit aktivierter Controlplane V2 enableControlplaneV2 auf true fest.

Wenn die Steuerungsebene V2 aktiviert ist, wird die Steuerungsebene für den Nutzercluster auf Knoten im Nutzercluster selbst ausgeführt. Wir empfehlen dringend, Controlplane V2 zu aktivieren.

Kubeception

Wenn Sie dieses Feld auf false festlegen, verwendet der Cluster kubecetption. Mit kubeception wird die Steuerungsebene für den Nutzercluster auf Knoten im Administratorcluster ausgeführt.

Für einen kubeception-Cluster:

Setzen Sie enableControlplaneV2 auf false.
Füllen Sie den Abschnitt controlPlaneIPBlock nicht aus.
Geben Sie IP-Adressen für die Knoten der Steuerungsebene des Nutzerclusters in der IP-Blockdatei des Administratorclusters an.

`enableDataplaneV2`

Legen Sie enableDataplaneV2 auf true fest.

`vCenter`

Die im Abschnitt vCenter Ihrer Administratorcluster-Konfigurationsdatei festgelegten Werte sind global. Das heißt, sie gelten für Ihren Administratorcluster und die zugehörigen Nutzercluster.

Für jeden von Ihnen erstellten Nutzercluster haben Sie die Möglichkeit, einige der globalen vCenter-Werte zu überschreiben.

Wenn Sie einen oder mehrere der globalen vCenter-Werte überschreiben möchten, füllen Sie die relevanten Felder im Abschnitt vCenter der Konfigurationsdatei des Nutzerclusters aus.

Insbesondere möchten Sie separate vSphere-Cluster für Ihre Administrator- und Nutzercluster sowie separate Rechenzentren für Ihren Administratorcluster und Ihre Nutzercluster verwenden.

Ein Rechenzentrum und einen vSphere-Cluster verwenden

Die Standardoption besteht darin, ein Rechenzentrum und einen vSphere-Cluster für den Administratorcluster und den Nutzercluster zu verwenden. Legen Sie für diese Option keine vCenter-Werte in der Konfigurationsdatei des Nutzerclusters fest. Die vCenter-Werte werden aus dem Administratorcluster übernommen.

Separate vSphere-Cluster verwenden

Wenn Sie einen Nutzercluster erstellen möchten, der sich in seinem eigenen vSphere-Cluster befindet, geben Sie in der Konfigurationsdatei des Nutzerclusters einen Wert für vCenter.cluster an.

Wenn sich Ihr Administratorcluster und Ihr Nutzercluster in separaten vSphere-Clustern befinden, können sie sich im selben Rechenzentrum oder in verschiedenen Rechenzentren befinden.

Separate vSphere-Rechenzentren verwenden

Der Nutzercluster und der Administratorcluster können sich in verschiedenen Rechenzentren befinden. In diesem Fall befinden sie sich auch in separaten vSphere-Clustern.

Wenn Sie vCenter.datacenter in der Konfigurationsdatei des Nutzerclusters angeben, müssen Sie auch Folgendes angeben:

vCenter.networkName
vCenter.datastore oder vCenter.storagePolicyName.
vCenter.cluster oder vCenter.resourcePool.

Separate vCenter-Konten verwenden

Ein Nutzercluster kann ein anderes vCenter-Konto mit anderen vCenter.credentials als der Administratorcluster verwenden. Das vCenter-Konto für den Administratorcluster benötigt Zugriff auf das Rechenzentrum des Administratorclusters, während das vCenter-Konto für den Nutzercluster nur Zugriff auf das Rechenzentrum des Nutzerclusters benötigt.

Separate Instanzen von vCenter Server verwenden

In bestimmten Situationen ist es sinnvoll, einen Nutzercluster zu erstellen, der eine eigene Instanz von vCenter Server verwendet. Das heißt, der Administratorcluster und ein zugehöriger Nutzercluster verwenden unterschiedliche Instanzen von vCenter Server.

An einem Edge-Standort können Sie beispielsweise eine physische Maschine, auf der vCenter Server ausgeführt wird, und eine oder mehrere physische Maschinen, auf denen ESXi ausgeführt wird, haben. Anschließend können Sie mit Ihrer lokalen Instanz von vCenter Server eine vSphere-Objekthierarchie erstellen, einschließlich Rechenzentren, Clustern, Ressourcenpools, Datenspeichern und Ordnern.

Füllen Sie den gesamten vCenter-Abschnitt der Konfigurationsdatei des Nutzerclusters 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"

Füllen Sie außerdem das Feld network.vCenter.networkName aus.

`network`

Legen Sie fest, wie die Worker-Knoten ihre IP-Adressen abrufen sollen. Folgende Optionen sind verfügbar:

Von einem DHCP-Server, den Sie im Voraus eingerichtet haben. Legen Sie network.ipMode.type auf "dhcp" fest.
Aus einer Liste der von Ihnen angegebenen statischen IP-Adressen. Legen Sie network.ipMode.type auf "static" fest und erstellen Sie eine IP-Blockdatei, die die statischen IP-Adressen bereitstellt. Ein Beispiel für eine IP-Blockdatei finden Sie unter Beispiel für ausgefüllte Konfigurationsdateien.

Wenn Sie statische IP-Adressen für Ihre Worker-Knoten verwenden möchten, füllen Sie das Feld network.ipMode.ipBlockFilePath aus.

Die IP-Adressen der Knoten der Steuerungsebene für Ihren Nutzercluster müssen aus einer Liste statischer Adressen abgerufen werden, die Sie bereitstellen. Dies ist auch dann der Fall, wenn Ihre Worker-Knoten ihre Adressen von einem DHCP-Server erhalten. Füllen Sie den Abschnitt network.controlPlaneIPBlock aus, um statische IP-Adressen für die Knoten der Steuerungsebene anzugeben. Wenn Sie einen Hochverfügbarkeits-Nutzercluster wünschen, geben Sie drei IP-Adressen an. Geben Sie andernfalls eine IP-Adresse an.

Geben Sie die DNS- und NTP-Server an, indem Sie den Abschnitt hostConfig ausfüllen. Diese DNS- und NTP-Server sind für die Knoten der Steuerungsebene vorgesehen. Wenn Sie für Ihre Worker-Knoten statische IP-Adressen verwenden, gelten diese DNS- und NTP-Server auch für die Worker-Knoten.

network.podCIDR und network.serviceCIDR haben bereits ausgefüllte Werte, die Sie unverändert lassen können, sofern sie nicht mit Adressen in Konflikt stehen, die bereits in Ihrem Netzwerk verwendet werden. Kubernetes verwendet diese Bereiche, um den Pods und Services in Ihrem Cluster IP-Adressen zuzuweisen.

Unabhängig davon, ob Sie einen DHCP-Server verwenden oder eine Liste statischer IP-Adressen angeben, müssen Sie für Ihren Nutzercluster genügend IP-Adressen haben. Informationen zur Anzahl der benötigten IP-Adressen finden Sie unter IP-Adressen planen.

`loadBalancer`

Legen Sie eine VIP für den Kubernetes API-Server Ihres Nutzerclusters fest. Legen Sie eine andere VIP für den Ingress-Dienst Ihres Nutzerclusters fest. Geben Sie Ihre VIPs als Werte für loadBalancer.vips.controlPlaneVIP und loadBalancer.vips.ingressVIP an.

Entscheiden Sie, welche Art von Load-Balancing Sie verwenden möchten. Folgende Optionen sind verfügbar:

Gebündeltes MetalLB-Load-Balancing. Legen Sie loadBalancer.kind auf "MetalLB" fest. Füllen Sie auch den Abschnitt loadBalancer.metalLB.addressPools aus und setzen Sie enableLoadBalancer für mindestens einen Ihrer Knotenpools auf true. Weitere Informationen finden Sie unter Gebündeltes Load-Balancing mit MetalLB.
Manuelles Load-Balancing. Legen Sie loadBalancer.kind auf "ManualLB" fest und füllen Sie den Abschnitt manualLB aus. Weitere Informationen finden Sie unter Manuelles Load-Balancing.

Weitere Informationen zu den Load-Balancing-Optionen finden Sie unter Load-Balancing – Übersicht.

`advancedNetworking`

Wenn Sie ein NAT-Gateway für ausgehenden Traffic erstellen möchten, legen Sie für advancedNetworking den Wert true fest.

`multipleNetworkInterfaces`

Entscheiden Sie, ob Sie mehrere Netzwerkschnittstellen für Pods konfigurieren möchten, und legen Sie multipleNetworkInterfaces entsprechend fest.

`storage`

Wenn Sie die Bereitstellung von vSphere-CSI-Komponenten deaktivieren möchten, setzen Sie storage.vSphereCSIDisabled auf true.

`masterNode`

Im Abschnitt masterNode können Sie angeben, wie viele Knoten der Steuerungsebene für den Nutzercluster verwendet werden sollen: ein oder drei. Sie können auch einen Datenspeicher für die Knoten der Steuerungsebene angeben und angeben, ob Sie die automatische Größenanpassung für die Knoten der Steuerungsebene aktivieren möchten.

Sie haben im Abschnitt network.controlPlaneIPBlock IP-Adressen für die Knoten der Steuerungsebene angegeben.

`nodePools`

Ein Knotenpool besteht aus einer Gruppe von Knoten in einem Cluster, die alle dieselbe Konfiguration haben. Beispielsweise kann auf den Knoten in einem Pool Windows und auf den Knoten in einem anderen Pool Linux ausgeführt werden.

Sie müssen mindestens einen Knotenpool angeben, indem Sie den Abschnitt nodePools ausfüllen.

Weitere Informationen finden Sie unter Knotenpools und Knotenpools erstellen und verwalten.

`antiAffinityGroups`

Legen Sie antiAffinityGroups.enabled auf true oder false fest.

Dieses Feld gibt an, ob GKE on VMware DRS-Anti-Affinitätsregeln (Distributed Resource Scheduler) für Ihre Worker-Knoten erstellt, wodurch sie auf mindestens drei physische Hosts in Ihrem Rechenzentrum verteilt werden.

`stackdriver`

Wenn Sie Cloud Logging und Cloud Monitoring für Ihren Cluster aktivieren möchten, füllen Sie den Abschnitt stackdriver aus.

Dieser Bereich ist standardmäßig erforderlich. Wenn Sie diesen Abschnitt nicht ausfüllen, müssen Sie also beim Ausführen von gkectl create cluster das Flag --skip-validation-stackdriver angeben.

Beachten Sie die folgenden Anforderungen für neue Cluster:

Die ID in stackdriver.projectID muss mit der ID in gkeConnect.projectID und cloudAuditLogging.projectID übereinstimmen.
Die in stackdriver.clusterLocation festgelegte Google Cloud-Region muss mit der in cloudAuditLogging.clusterLocation und gkeConnect.location festgelegten Region übereinstimmen, sofern das Feld in der Konfigurationsdatei enthalten ist. Wenn gkeOnPremAPI.enabled den Wert true hat, muss dieselbe Region auch in gkeOnPremAPI.location festgelegt werden.

Wenn die Projekt-IDs und Regionen nicht identisch sind, schlägt die Clustererstellung fehl.

`gkeConnect`

Ihr Nutzercluster muss bei einer Google Cloud-Flotte registriert sein.

Füllen Sie den Abschnitt gkeConnect aus, um ein Flotten-Hostprojekt und ein zugehöriges Dienstkonto anzugeben. Die ID in gkeConnect.projectID muss mit der in stackdriver.projectID und cloudAuditLogging.projectID festgelegten ID übereinstimmen. Wenn die Projekt-IDs nicht übereinstimmen, schlägt die Clustererstellung fehl.

In Version 1.28 und höher können Sie optional eine Region angeben, in der die Flotten- und Connect-Dienste in gkeConnect.location ausgeführt werden. Wenn Sie dieses Feld nicht angeben, verwendet der Cluster die globalen Instanzen dieser Dienste.

Wenn Sie gkeConnect.location in Ihre Konfigurationsdatei aufnehmen, muss die angegebene Region mit der in cloudAuditLogging.clusterLocation, stackdriver.clusterLocation und gkeOnPremAPI.location konfigurierten Region übereinstimmen. Wenn die Regionen nicht identisch sind, schlägt die Clustererstellung fehl.

`gkeOnPremAPI`

Wenn in Version 1.16 und höher die GKE On-Prem API in Ihrem Google Cloud-Projekt aktiviert ist, werden alle Cluster im Projekt automatisch in der in stackdriver.clusterLocation konfigurierten Region für die GKE On-Prem API registriert. Die Region gkeOnPremAPI.location muss mit der Region übereinstimmen, die in cloudAuditLogging.clusterLocation, gkeConnect.location (wenn das Feld in der Konfigurationsdatei enthalten ist) und stackdriver.clusterLocation angegeben ist.

Wenn Sie alle Cluster im Projekt in der GKE On-Prem API registrieren möchten, führen Sie die Schritte unter Vorbereitung aus, um die GKE On-Prem API im Projekt zu aktivieren und zu verwenden.
Wenn Sie den Cluster nicht in der GKE On-Prem API registrieren möchten, fügen Sie diesen Abschnitt ein und legen Sie gkeOnPremAPI.enabled auf false fest. Wenn Sie keine Cluster im Projekt registrieren möchten, deaktivieren Sie gkeonprem.googleapis.com (den Dienstnamen für die GKE On-Prem API) im Projekt. Eine Anleitung dazu finden Sie unter Dienste deaktivieren.

`usageMetering`

Wenn Sie die Nutzungsmessung für Ihren Cluster aktivieren möchten, füllen Sie den Abschnitt usageMetering aus.

`cloudAuditLogging`

Wenn Sie die Audit-Logs vom Kubernetes API-Server des Clusters in Cloud-Audit-Logs einbinden möchten, füllen Sie den Abschnitt cloudAuditLogging aus.

Beachten Sie die folgenden Anforderungen für neue Cluster:

Die ID in cloudAuditLogging.projectID muss mit der ID in gkeConnect.projectID und stackdriver.projectID übereinstimmen.
Die Region in cloudAuditLogging.clusterLocation muss mit der Region übereinstimmen, die in gkeConnect.location (wenn das Feld in der Konfigurationsdatei enthalten ist) und in stackdriver.clusterLocation festgelegt sind. Wenn gkeOnPremAPI.enabled den Wert true hat, muss dieselbe Region außerdem in gkeOnPremAPI.location festgelegt werden.

Wenn die Projekt-IDs und Regionen nicht identisch sind, schlägt die Clustererstellung fehl.

Beispiel für ausgefüllte Konfigurationsdateien

Hier sehen Sie ein Beispiel für eine IP-Blockdatei und eine Nutzercluster-Konfigurationsdatei:

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.28.400-gke.75
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

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 nur drei Worker-Knoten vorhanden sind. Die zusätzliche IP-Adresse wird während des Clusterupgrades, der Aktualisierung und der automatischen Reparatur des Clusters benötigt.
DNS- und NTP-Server werden im Abschnitt hostConfig angegeben. In diesem Beispiel sind diese DNS- und NTP-Server für die Knoten der Steuerungsebene und die Worker-Knoten vorgesehen. Das liegt daran, dass die Worker-Knoten statische IP-Adressen haben. Sollten die Worker-Knoten ihre IP-Adressen von einem DHCP-Server abrufen, wären diese DNS- und NTP-Server nur für die Knoten der Steuerungsebene vorgesehen.
Die statischen IP-Adressen für die drei Knoten der Steuerungsebene werden im Abschnitt network.controlPlaneIPBlock der Konfigurationsdatei des Nutzerclusters angegeben. In diesem Block wird keine zusätzliche IP-Adresse benötigt.
Controlplane V2 ist aktiviert.
Das Feld masterNode.replicas ist auf 3 gesetzt, sodass der Cluster eine Steuerungsebene mit Hochverfügbarkeit hat.
Die virtuelle IP-Adresse der Steuerungsebene und die virtuelle IP-Adresse für eingehenden Traffic befinden sich beide im selben VLAN wie die Worker-Knoten und die Knoten der Steuerungsebene.
Die VIPs, die für Dienste vom Typ LoadBalancer reserviert sind, werden im Abschnitt loadBalancer.metalLB.addressPools der Konfigurationsdatei des Nutzerclusters angegeben. Diese VIPs befinden sich im selben VLAN wie die Worker-Knoten und die Knoten der Steuerungsebene. Die in diesem Abschnitt angegebene Gruppe von VIPs muss die virtuelle IP-Adresse für eingehenden Traffic enthalten und darf nicht die virtuelle IP-Adresse der Steuerungsebene enthalten.
Die Konfigurationsdatei des Nutzerclusters enthält keinen vCenter-Abschnitt. Der Nutzercluster verwendet also dieselben vSphere-Ressourcen wie der Administratorcluster.

Konfigurationsdatei validieren

Nachdem Sie die Konfigurationsdatei des Nutzerclusters ausgefüllt haben, führen Sie gkectl check-config aus, um zu prüfen, ob die Datei gültig ist:

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

Ersetzen Sie Folgendes:

ADMIN_CLUSTER_KUBECONFIG: Pfad der kubeconfig-Datei für Ihren Administratorcluster
USER_CLUSTER_CONFIG: Pfad Ihrer Nutzercluster-Konfigurationsdatei

Wenn der Befehl Fehlermeldungen zurückgibt, beheben Sie die Probleme und validieren Sie die Datei noch einmal.

Wenn Sie die zeitaufwendigeren Validierungen überspringen möchten, übergeben Sie das Flag --fast. Verwenden Sie die Flags --skip-validation-xxx, um einzelne Validierungen zu überspringen. Weitere Informationen zum Befehl check-config finden Sie unter Vorabprüfungen ausführen.

3. (Optional) Betriebssystem-Images in vSphere importieren und Container-Images in eine private Registry übertragen

Führen Sie gkectl prepare aus, wenn eine der folgenden Bedingungen zutrifft:

Der Nutzercluster befindet sich in einem anderen vSphere-Rechenzentrum als Ihr Administratorcluster.
Ihr Nutzercluster hat einen anderen vCenter Server als Ihr Administratorcluster.
Ihr Nutzercluster verwendet eine private Container Registry, die sich von der privaten Registry unterscheidet, die von Ihrem Administratorcluster verwendet wird.

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

Ersetzen Sie Folgendes:

ADMIN_CLUSTER_KUBECONFIG: der Pfad der kubeconfig-Datei Ihres Administratorclusters
BUNDLE: Pfad der Bundle-Datei. Diese Datei befindet sich auf Ihrer Administrator-Workstation in /var/lib/gke/bundles/. Beispiel:
```
/var/lib/gke/bundles/gke-onprem-vsphere-1.28.400-gke.75-full.tgz
```
USER_CLUSTER_CONFIG: Pfad Ihrer Nutzercluster-Konfigurationsdatei

4. Nutzercluster erstellen

Erstellen Sie einen Nutzercluster:

gkectl create cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

Suchen Sie die kubeconfig-Datei des Nutzerclusters.

Mit dem Befehl gkectl create cluster wird im aktuellen Verzeichnis die kubeconfig-Datei USER_CLUSTER_NAME-kubeconfig erstellt. Sie benötigen diese kubeconfig-Datei später, um mit Ihrem Nutzercluster zu interagieren.

Die kubeconfig-Datei enthält den Namen Ihres Nutzerclusters. Zum Aufrufen des Clusternamens können Sie folgenden Befehl ausführen:

kubectl config get-clusters --kubeconfig USER_CLUSTER_KUBECONFIG

Die Ausgabe zeigt den Namen des Clusters. Beispiel:

NAME
my-user-cluster

Wenn Sie möchten, können Sie den Namen und den Speicherort der kubeconfig-Datei ändern.

5. Prüfen Sie, ob Ihr Nutzercluster ausgeführt wird

Prüfen Sie, ob Ihr Nutzercluster ausgeführt wird:

kubectl get nodes --kubeconfig USER_CLUSTER_KUBECONFIG

Ersetzen Sie USER_CLUSTER_KUBECONFIG durch den Pfad der kubeconfig-Datei des Nutzerclusters.

Die Ausgabe zeigt die Knoten des Nutzerclusters. 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

Console

Mehr erfahren

Rufen Sie in der Google Cloud Console die Seite GKE on VMware-Cluster erstellen auf.

Zur Seite „GKE on VMware-Cluster erstellen“
Wählen Sie das Google Cloud-Projekt aus, in dem Sie den Cluster erstellen möchten. Das ausgewählte Projekt wird auch als Flotten-Hostprojekt verwendet. Dies muss dasselbe Projekt sein, bei dem der Administratorcluster registriert ist. Nachdem der Nutzercluster erstellt wurde, wird er automatisch bei der Flotte des ausgewählten Projekts registriert.

Clustergrundlagen

Geben Sie grundlegende Informationen zum Cluster ein.

Geben Sie einen Namen für den Nutzercluster ein.
Wählen Sie unter Administratorcluster den Administratorcluster aus der Liste aus. Wenn Sie beim Erstellen keinen Namen für den Administratorcluster angegeben haben, wird der Name im Format gke-admin-[HASH] generiert. Wenn Sie den Namen des Administratorclusters nicht erkennen, führen Sie den folgenden Befehl auf Ihrer Administrator-Workstation aus:
```
KUBECONFIG=ADMIN_CLUSTER_KUBECONFIG
kubectl get OnPremAdminCluster -n kube-system -o=jsonpath='{.items[0].metadata.name}'
```
Wenn der zu verwendende Administratorcluster nicht angezeigt wird, lesen Sie den Abschnitt zur Fehlerbehebung. Der Administratorcluster wird nicht in der Drop-down-Liste Clustergrundlagen angezeigt.
Wählen Sie im Feld GCP API-Standort die Google Cloud-Region aus der Liste aus. Mit dieser Einstellung wird die Region festgelegt, in der die folgenden APIs und Dienste ausgeführt werden:
- GKE On-Prem API (gkeonprem.googleapis.com)
- Flottendienst (gkehub.googleapis.com)
- Dienst verbinden (gkeconnect.googleapis.com)
Mit dieser Einstellung wird auch die Region festgelegt, in der die folgenden Daten gespeichert werden:
- Die Metadaten des Nutzerclusters, die die GKE On-Prem API zum Verwalten des Clusterlebenszyklus benötigt
- Cloud Logging- und Cloud Monitoring-Daten von Systemkomponenten
- Das von Cloud-Audit-Logs erstellte Administrator-Audit-Log
Der Clustername, das Projekt und der Standort identifizieren zusammen den Cluster in Google Cloud eindeutig.
Wählen Sie die GKE on VMware-Version für Ihren Nutzercluster aus.
Als Ersteller des Clusters erhalten Sie Administratorberechtigungen für den Cluster. Optional können Sie die E-Mail-Adresse eines anderen Nutzers, der den Cluster verwalten wird, im Bereich Autorisierung in das Feld Clusteradministrator eingeben.

Wenn der Cluster erstellt wird, wendet die GKE On-Prem API die Richtlinien für die rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC) von Kubernetes auf den Cluster an, um Ihnen und anderen Administratoren die Kubernetes-Rolle clusterrole/cluster-admin zu gewähren, die vollständigen Zugriff auf jede Ressource im Cluster in allen Namespaces bietet.

Hinweis: Zusätzlich zu den Kubernetes-RBAC-Richtlinien müssen Sie Nutzern, die keine Projektinhaber sind, einige IAM-Rollen (Identity and Access Management) zuweisen. Weitere Informationen zum Gewähren von IAM-Rollen finden Sie unter Erforderliche Rollen gewähren.
Klicken Sie auf Weiter, um zum Abschnitt Steuerungsebene zu wechseln.

Steuerungsebene

Alle Felder im Bereich Steuerungsebene sind mit Standardwerten festgelegt. Prüfen Sie die Standardeinstellungen und ändern Sie sie optional bei Bedarf.

Geben Sie im Feld vCPUs für Knoten der Steuerungsebene die Anzahl der vCPUs (mindestens 4) für jeden Knoten der Steuerungsebene für Ihren Nutzercluster ein.
Geben Sie im Feld Arbeitsspeicher des Knotens der Steuerungsebene die Arbeitsspeichergröße in MiB (mindestens 8.192 und muss ein Vielfaches von 4) für jede Steuerungsebene für Ihren Nutzercluster ein.
Wählen Sie unter Knoten der Steuerungsebene die Anzahl der Knoten der Steuerungsebene für Ihren Nutzercluster aus. Sie können beispielsweise einen Knoten der Steuerungsebene für eine Entwicklungsumgebung und drei Knoten der Steuerungsebene für Produktionsumgebungen mit Hochverfügbarkeit auswählen.
Wählen Sie optional Automatische Anpassung der Knotengröße aus. Bei der Größenanpassung werden die einem Knoten zugewiesenen vCPU- und Arbeitsspeicherressourcen automatisch angepasst. Wenn diese Option aktiviert ist, wird die Größe der Knoten der Steuerungsebene für den Nutzercluster entsprechend der Anzahl der Worker-Knoten im Nutzercluster angepasst. Je mehr Worker-Knoten Sie dem Nutzercluster hinzufügen, desto größer werden die Knoten der Steuerungsebene.
Wählen Sie optional Steuerungsebene v2 aktivieren aus. Wenn Sie Controlplane V2 aktivieren, wird die Steuerungsebene für einen Nutzercluster auf einem oder mehreren Knoten im Nutzercluster selbst und nicht im Administratorcluster (auch als kubeception bezeichnet) ausgeführt.

Wenn Sie Steuerungsebene v2 aktivieren auswählen, wird der Abschnitt IP-Adressen der Knoten der Steuerungsebene angezeigt. Geben Sie die IP-Adresse für das Gateway, die Subnetzmaske und die IP-Adressen für die Knoten der Steuerungsebene ein.

Wenn die Steuerungsebene V2 aktiviert ist, gelten die Felder für vCPU und Arbeitsspeicher für die Knoten der Steuerungsebene im Nutzercluster. Die Anzahl der Knoten wird durch die Anzahl der von Ihnen eingegebenen IP-Adressen bestimmt. Wenn die Steuerungsebene V2 nicht aktiviert ist, gelten die Felder für vCPU, Arbeitsspeicher und Anzahl der Knoten der Steuerungsebene für die Knoten im Administratorcluster. Reservieren Sie genügend IP-Adressen für Ihren Administratorcluster.
Klicken Sie auf Weiter, um zum Abschnitt Netzwerk zu gelangen.

Netzwerk

In diesem Abschnitt geben Sie die IP-Adressen für die Knoten, Pods und Services Ihres Clusters an. Ein Nutzercluster benötigt eine IP-Adresse für jeden Knoten und eine zusätzliche IP-Adresse für einen temporären Knoten, der während Clusterupgrades, -aktualisierungen und der automatischen Reparatur benötigt wird. Weitere Informationen finden Sie unter Wie viele IP-Adressen benötigt ein Nutzercluster?.

Wählen Sie im Abschnitt Knoten-IP-Adressen den IP-Modus für den Nutzercluster aus. Entscheiden Sie sich für eine der folgenden Möglichkeiten:
- DHCP: Wählen Sie DHCP aus, wenn Ihre Clusterknoten ihre IP-Adresse von einem DHCP-Server abrufen sollen.
- Statisch: Wählen Sie Statisch aus, wenn Sie statische IP-Adressen für Ihre Clusterknoten bereitstellen oder das manuelle Load-Balancing einrichten möchten.
Wenn Sie DHCP ausgewählt haben, fahren Sie mit dem nächsten Schritt fort, um Service- und Pod-CIDRs anzugeben. Geben Sie für den statischen IP-Modus die folgenden Informationen an:
1. Geben Sie die IP-Adresse des Gateways für den Nutzercluster ein.
2. Geben Sie die Subnetzmaske für die Nutzerclusterknoten ein.
3. Geben Sie im Abschnitt IP-Adressen die IP-Adressen und optional die Hostnamen für die Knoten im Nutzercluster ein. Sie können entweder eine einzelne IPv4-Adresse (z. B. 192.0.2.1) oder einen CIDR-Block von IPv4-Adressen (z. B. 192.0.2.0/24) eingeben.
  - Wenn Sie einen CIDR-Block eingeben, geben Sie keinen Hostnamen ein.
  - Wenn Sie eine einzelne IP-Adresse eingeben, können Sie optional einen Hostnamen eingeben. Wenn Sie keinen Hostnamen eingeben, verwendet GKE on VMware den Namen der VM aus vSphere als Hostnamen.
4. Klicken Sie nach Bedarf auf + IP-Adresse hinzufügen, um weitere IP-Adressen einzugeben.
Im Abschnitt Dienst- und Pod-CIDRs enthält die Console die folgenden Adressbereiche für Ihre Kubernetes-Dienste und -Pods:
- Service-CIDR: 10.96.0.0/20
- Pod-CIDR: 192.168.0.0/16
Wenn Sie Ihre eigenen Adressbereiche eingeben möchten, finden Sie Best Practices unter IP-Adressen für Pods und Services.
Wenn Sie den Modus für statische IP-Adressen oder Steuerungsebene v2 aktivieren ausgewählt haben, geben Sie im Abschnitt Hostkonfiguration die folgenden Informationen an:
1. Geben Sie die IP-Adressen der DNS-Server ein.
2. Geben Sie die IP-Adressen der NTP-Server ein.
3. Geben Sie optional DNS-Suchdomains ein.
Klicken Sie auf Weiter, um zum Abschnitt Load-Balancer zu gelangen.

Load-Balancer

Wählen Sie den Load-Balancer aus, der für Ihren Cluster eingerichtet werden soll. Weitere Informationen finden Sie unter Load-Balancer – Übersicht.

Wählen Sie den Load-Balancer-Typ aus der Liste aus.

Gebündelt mit MetalLB

Konfigurieren Sie gebündeltes Load-Balancing mit MetalLB. Sie können MetalLB nur für den Nutzercluster verwenden, wenn Ihr Administratorcluster SeeSaw oder MetalLB verwendet. Diese Option erfordert eine minimale Konfiguration. MetalLB wird direkt auf Ihren Clusterknoten ausgeführt und benötigt keine zusätzlichen VMs. Weitere Informationen zu den Vorteilen der Verwendung von MetalLB im Vergleich zu den anderen Load-Balancing-Optionen finden Sie unter Gebündeltes Load-Balancing mit MetalLB.

Konfigurieren Sie im Abschnitt Adresspools mindestens einen Adresspool so:
1. Geben Sie einen Namen für den Adresspool ein.
2. Geben Sie einen IP-Adressbereich ein, der die Ingress-VIP in der CIDR-Notation (z. B. 192.0.2.0/26) oder der Bereichsnotation (z. B. 192.0.2.64-192.0.2.72) enthält. Verwenden Sie zum Angeben einer einzelnen IP-Adresse in einem Pool /32 in der CIDR-Notation (z. B. 192.0.2.1/32).
3. Wenn sich die IP-Adressen für Ihre Services vom Typ LoadBalancer nicht im selben IP-Adressbereich wie die Ingress-VIP befinden, klicken Sie auf + IP-Adressbereich hinzufügen und geben Sie einen anderen Adressbereich ein.
  
  Die IP-Adressen in jedem Pool dürfen sich nicht überschneiden und müssen sich im selben Subnetz wie die Clusterknoten befinden.
4. Wählen Sie unter Zuweisung von IP-Adressen eine der folgenden Optionen aus:
  - Automatisch: Wählen Sie diese Option aus, wenn der MetalLB-Controller automatisch IP-Adressen aus dem Adresspool den Services vom Typ LoadBalancer zuweisen soll.
  - Manuell: Wählen Sie diese Option aus, wenn Sie Adressen aus dem Pool verwenden möchten, um Adressen für Services vom Typ LoadBalancer manuell anzugeben.
5. Klicken Sie auf Fehlerhafte IP-Adressen vermeiden, wenn der MetalLB-Controller keine Adressen aus dem Pool verwenden soll, die auf .0 oder .255 enden. Dadurch wird verhindert, dass fehlerhafte Geräte versehentlich Traffic löschen, der an diese speziellen IP-Adressen gesendet wird.
6. Klicken Sie zum Schluss auf Fertig.
Klicken Sie ggf. auf Adresspool hinzufügen.
Geben Sie im Abschnitt Virtuelle IP-Adressen Folgendes ein:
- Virtuelle IP-Adresse der Steuerungsebene: Die Ziel-IP-Adresse, die für Traffic an den Kubernetes API-Server des Nutzerclusters verwendet werden soll. Der Kubernetes API-Server für den Nutzercluster wird auf einem Knoten im Administratorcluster ausgeführt. Diese IP-Adresse muss sich in derselben L2-Domain wie die Administratorclusterknoten befinden. Fügen Sie diese Adresse nicht im Abschnitt Adresspools hinzu.
- Ingress-VIP: Die IP-Adresse, die auf dem Load-Balancer für den Ingress-Proxy konfiguriert werden soll. Sie müssen dies einem Adresspool im Abschnitt Adresspools hinzufügen.
Klicken Sie auf Weiter.

F5 BIG-IP

Sie können F5 BIG-IP nur für den Nutzercluster verwenden, wenn Ihr Administratorcluster F5 BIG-IP verwendet. Installieren und konfigurieren Sie unbedingt den F5 BIG-IP-ADC, bevor Sie ihn in GKE on VMware einbinden.

Der F5-Nutzername und -Passwort werden vom Administratorcluster übernommen.

Geben Sie im Abschnitt Virtuelle IP-Adressen Folgendes ein:
- VIP der Steuerungsebene: Die Ziel-IP-Adresse, die für den an den Kubernetes API-Server gesendeten Traffic verwendet werden soll.
- Ingress-VIP: Die IP-Adresse, die auf dem Load-Balancer für den Ingress-Proxy konfiguriert werden soll.
Geben Sie im Feld Adresse die Adresse Ihres F5 BIG-IP-Load-Balancers ein.
Geben Sie im Feld Partition den Namen einer BIG-IP-Partition ein, die Sie für den Nutzercluster erstellt haben.
Geben Sie im Feld SNAT-Poolname gegebenenfalls den Namen des SNAT-Pools ein.
Klicken Sie auf Weiter.

Manuell

Sie können nur dann einen manuellen Load-Balancer für den Nutzercluster verwenden, wenn Ihr Administratorcluster einen manuellen Load-Balancer verwendet. In GKE on VMware werden der Kubernetes API-Server und der Ingress-Proxy von einem Kubernetes-Dienst vom Typ LoadBalancer bereitgestellt. Wählen Sie Ihre eigenen nodePort-Werte im Bereich von 30.000 bis 32.767 für diese Dienste aus. Wählen Sie für den Ingress-Proxy einen nodePort-Wert für HTTP- und HTTPS-Traffic aus. Weitere Informationen finden Sie unter Manuellen Load-Balancing-Modus aktivieren.

Geben Sie im Abschnitt Virtuelle IP-Adressen Folgendes ein:
- VIP der Steuerungsebene: Die Ziel-IP-Adresse, die für den an den Kubernetes API-Server gesendeten Traffic verwendet werden soll.
- Ingress-VIP: Die IP-Adresse, die auf dem Load-Balancer für den Ingress-Proxy konfiguriert werden soll.
Geben Sie im Feld Port für Knoten der Steuerungsebene den Wert nodePort für den Kubernetes API-Server ein.
Geben Sie im Feld Ingress-HTTP-Knotenport einen nodePort-Wert für HTTP-Traffic zum Ingress-Proxy ein.
Geben Sie im Feld Knotenport für eingehenden HTTPS-Traffic einen nodePort-Wert für den HTTPS-Traffic zum Ingress-Proxy ein.
Geben Sie im Feld Knotenport für Konnectivity-Server einen nodePort-Wert für den Konnectivity-Server ein.
Klicken Sie auf Weiter.

Features

In diesem Abschnitt werden die Features und Vorgänge angezeigt, die im Cluster aktiviert sind.

Folgendes ist automatisch aktiviert und kann nicht deaktiviert werden:
- Cloud Logging von Systemdiensten
- Cloud Monitoring von Systemdiensten
- Audit-Log für Administratoraktivitäten
Folgendes ist standardmäßig aktiviert, kann aber deaktiviert werden:
- vSphere-CSI-Treiber aktivieren: Wird auch als vSphere Container Storage-Plug-in bezeichnet. Der CSI-Treiber (Container Storage Interface) wird in einem Kubernetes-Cluster ausgeführt, der in vSphere bereitgestellt wird, um nichtflüchtige Volumes im vSphere-Speicher bereitzustellen. Weitere Informationen finden Sie unter Mit dem vSphere-CSI-Treiber (Container Storage Interface) arbeiten.
- Anti-Affinitätsgruppen aktivieren: VMware-DRS-Anti-Affinitätsregeln (Distributed Resource Scheduler) werden automatisch für die Knoten Ihres Nutzerclusters erstellt, wodurch sie auf mindestens drei physische Hosts in Ihrem Rechenzentrum verteilt werden. Prüfen Sie, ob Ihre vSphere-Umgebung die Anforderungen erfüllt.
Hinweis: Wenn Sie Minimale Infrastruktur einrichten ausgeführt haben, haben Sie nur einen ESXi-Host. Deaktivieren Sie daher Anti-Affinitätsgruppen aktivieren.
Klicken Sie auf Weiter, um einen Knotenpool zu konfigurieren.

Knotenpools

Ihr Cluster wird mit mindestens einem Knotenpool erstellt. Ein Knotenpool ist eine Vorlage für eine Gruppe von Worker-Knoten, die in diesem Cluster erstellt werden. Weitere Informationen finden Sie unter Knotenpools erstellen und verwalten.

Gehen Sie im Bereich Knotenpool-Standardeinstellungen so vor:
1. Geben Sie den Namen des Knotenpools ein oder übernehmen Sie "default-pool".
2. Geben Sie die Anzahl der vCPUs für jeden Knoten im Pool ein (mindestens 4 pro Nutzercluster-Worker).
3. Geben Sie die Arbeitsspeichergröße in Mebibyte (MiB) für jeden Knoten im Pool ein (mindestens 8.192 MiB pro Worker-Knoten des Nutzerclusters und muss ein Vielfaches von 4 sein).
4. Geben Sie im Feld Knoten die Anzahl der Knoten im Pool ein (mindestens 3). Wenn Sie im Abschnitt Netzwerk für Knoten-IPs statische IP-Adressen eingegeben haben, prüfen Sie, ob Sie genügend IP-Adressen für diese Nutzerclusterknoten eingegeben haben.
5. Wählen Sie den Betriebssystem-Image-Typ aus: Ubuntu, Ubuntu Containerd oder COS.
6. Geben Sie die Größe des Bootlaufwerks in Gibibyte (GiB) ein (mindestens 40 GiB).
7. Wenn Sie MetalLB als Load-Balancer verwenden, muss MetalLB in mindestens einem Knotenpool aktiviert sein. Lassen Sie entweder Diesen Knotenpool für MetalLB-Load-Balancing verwenden aktiviert oder fügen Sie einen weiteren Knotenpool für MetalLB hinzu.
Wenn Sie im Bereich Knotenpool-Metadaten (optional) Kubernetes-Labels und -Markierungen hinzufügen möchten, gehen Sie so vor:
1. Klicken Sie auf + Kubernetes-Labels hinzufügen. Geben Sie den Schlüssel und den Wert für das Label ein. Wiederholen Sie diese Schritte für alle Suchabfragen, für die dies erforderlich ist.
2. Klicken Sie auf + Markierung hinzufügen. Geben Sie Schlüssel, Wert und Effekt für die Markierung ein. Wiederholen Sie diese Schritte für alle Suchabfragen, für die dies erforderlich ist.
Klicken Sie auf Prüfen und abschließen, um den Nutzercluster zu erstellen. Das Erstellen des Nutzerclusters dauert mindestens 15 Minuten. In der Console werden Statusmeldungen angezeigt, wenn die Einstellungen überprüft und der Cluster in Ihrem Rechenzentrum erstellt wird.

Wenn beim Überprüfen der Einstellungen ein Fehler auftritt, wird in der Console eine Fehlermeldung angezeigt, die klar genug sein sollte, damit Sie das Konfigurationsproblem beheben und noch einmal versuchen können, den Cluster zu erstellen.

Weitere Informationen zu möglichen Fehlern und deren Behebung finden Sie unter Fehlerbehebung beim Erstellen von Nutzerclustern in der Google Cloud Console.

gcloud-CLI

Mit dem folgenden Befehl erstellen Sie einen Nutzercluster:

gcloud container vmware clusters create

Nachdem Sie den Cluster erstellt haben, müssen Sie mit dem folgenden Befehl mindestens einen Knotenpool erstellen:

gcloud container vmware node-pools create

Die meisten Flags zum Erstellen des Clusters und des Knotenpools entsprechen den Feldern in der Konfigurationsdatei für Nutzercluster. Für einen leichteren Einstieg können Sie im Abschnitt Beispiele einen vollständigen Befehl testen.

Hinweise

Rufen Sie den Namen und den Standort der Flottenmitgliedschaft Ihres Administratorclusters ab:
```
gcloud container fleet memberships list \
    --project=FLEET_HOST_PROJECT_ID
```
Ersetzen Sie FLEET_HOST_PROJECT_ID durch die ID des Projekts, für das der Administratorcluster registriert ist.

Die Ausgabe sieht in etwa so aus:
```
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
```
Der Standort gibt an, wo die Fleet- und Connect-Dienste ausgeführt werden. Administratorcluster, die vor 1.28 erstellt wurden, werden von den globalen Flotten- und Connect-Diensten verwaltet. In Version 1.28 und höher können Sie beim Erstellen des Administratorclusters entweder global oder eine Google Cloud-Region angeben. In den folgenden Beispielbefehlen geben Sie die Region im Flag --admin-cluster-membership-location an.
Rufen Sie eine Liste der verfügbaren Versionen auf:
```
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
```
Ersetzen Sie Folgendes:
- ADMIN_CLUSTER_NAME: Der Name des Administratorclusters.
- FLEET_HOST_PROJECT_ID: Die ID des Projekts, für das der Administratorcluster registriert ist.
- ADMIN_CLUSTER_REGION: Region der Flottenmitgliedschaft des Administratorclusters. Dies ist entweder global oder eine Google Cloud-Region. Verwenden Sie den Standort für den Administratorcluster aus der Ausgabe von gcloud container fleet memberships list.
- REGION: Die Google Cloud-Region, die Sie beim Erstellen des Clusters verwenden. Dies ist die Region, in der die GKE On-Prem API und die Fleet and Connect-Dienste ausgeführt werden. Geben Sie us-west1 oder eine andere unterstützte Region an.
Die Ausgabe dieses Befehls sieht in etwa so aus:
```
versions:
- isInstalled: true
  version: 1.14.3-gke.25
- version: 1.14.4-gke.54
- version: 1.15.0-gke.581
```
Versionen, die Sie zum Erstellen eines Nutzerclusters verwenden können, sind mit isInstalled=true gekennzeichnet. Das bedeutet, dass der Administratorcluster die versionsspezifischen Komponenten hat, die zum Verwalten von Nutzerclustern dieser Version erforderlich sind. Informationen zum Erstellen eines Nutzerclusters mit einer anderen verfügbaren Version finden Sie unter Eine neuere Version als die Version des Administratorclusters installieren.

Beispiele

Die folgenden Beispiele zeigen, wie Sie einen Nutzercluster mit verschiedenen Load-Balancern erstellen. Weitere Informationen zu den verfügbaren Load-Balancing-Optionen finden Sie unter Load-Balancer – Übersicht.

In den Beispielen werden die Standardwerte zum Konfigurieren der Knoten der Steuerungsebene verwendet. Wenn Sie einen der Standardwerte ändern möchten, fügen Sie die im Abschnitt Flags der Steuerungsebene beschriebenen Flags ein. Bei Bedarf können Sie auch einige vSphere-Einstellungen ändern.

Nachdem der Cluster ausgeführt wurde, müssen Sie einen Knotenpool hinzufügen, bevor Sie Arbeitslasten bereitstellen, wie im Abschnitt Knotenpool erstellen beschrieben.

MetalLB und DHCP

Dieses Beispiel zeigt, wie Sie einen Nutzercluster mit dem gebündelten MetalLB-Load-Balancer erstellen und Ihren DHCP-Server verwenden, um IP-Adressen für Ihre Clusterknoten abzurufen.

Sie können MetalLB nur für den Nutzercluster verwenden, wenn Ihr Administratorcluster SeeSaw oder MetalLB verwendet. Diese Load-Balancing-Option erfordert eine minimale Konfiguration. MetalLB wird direkt auf Ihren Clusterknoten ausgeführt und benötigt keine zusätzlichen VMs. Weitere Informationen zu den Vorteilen der Verwendung von MetalLB im Vergleich zu den anderen Load-Balancing-Optionen finden Sie unter Gebündeltes Load-Balancing mit 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

Ersetzen Sie Folgendes:

USER_CLUSTER_NAME: Ein Name Ihrer Wahl für Ihren Nutzercluster. Der Name kann nach dem Erstellen des Clusters nicht mehr geändert werden. Der Name muss:
- darf höchstens 40 Zeichen enthalten.
- darf nur kleingeschriebene, alphanumerische Zeichen und einen Bindestrich - enthalten.
- Er muss mit einem Buchstaben beginnen.
- Er muss mit einem alphanumerischen Zeichen enden.
FLEET_HOST_PROJECT_ID: Die ID des Projekts, in dem Sie den Cluster erstellen möchten. Das angegebene Projekt wird auch als Flotten-Hostprojekt verwendet. Dies muss dasselbe Projekt sein, für das der Administratorcluster registriert ist. Nachdem der Nutzercluster erstellt wurde, wird er automatisch bei der Flotte des ausgewählten Projekts registriert. Das Flotten-Hostprojekt kann nach dem Erstellen des Clusters nicht mehr geändert werden.
ADMIN_CLUSTER_NAME: Der Name des Administratorclusters, der den Nutzercluster verwaltet. Im Flag --admin-cluster-membership können Sie den vollständig angegebenen Clusternamen im folgenden Format verwenden:
```
    projects/FLEET_HOST_PROJECT_ID/locations/ADMIN_CLUSTER_REGION/memberships/ADMIN_CLUSTER_NAME
```
Alternativ können Sie --admin-cluster-membership wie im Beispielbefehl auf den Namen des Administratorclusters festlegen. Wenn Sie nur den Namen des Administratorclusters verwenden, legen Sie die Projekt-ID des Administratorclusters mit --admin-cluster-membership-project und den Standort mit --admin-cluster-membership-location fest. Der Standort des Administratorclusters ist entweder global oder eine Google Cloud-Region. Wenn Sie die Region suchen, führen Sie gcloud container fleet memberships list aus.
REGION: Die Google Cloud-Region, in der die GKE On-Prem API (gkeonprem.googleapis.com), der Flottendienst (gkehub.googleapis.com) und der Connect-Dienst (gkeconnect.googleapis.com) ausgeführt werden. Geben Sie us-west1 oder eine andere unterstützte Region an. Die Region kann nach dem Erstellen des Clusters nicht mehr geändert werden. Diese Einstellung gibt die Region an, in der Folgendes gespeichert wird:
- Die Nutzerclustermetadaten, die die GKE On-Prem API zum Verwalten des Clusterlebenszyklus benötigt
- Cloud Logging- und Cloud Monitoring-Daten von Systemkomponenten
- Das von Cloud-Audit-Logs erstellte Administrator-Audit-Log
Der Clustername, das Projekt und der Standort identifizieren zusammen den Cluster in Google Cloud eindeutig.

Wichtig: Wenn Sie Anthos Service Mesh installieren möchten, müssen Sie Version 1.19.3 oder höher installieren. Dies ist erforderlich, da die Fleet- und Connect-Dienste in einer Region ausgeführt werden.
VERSION: Die GKE on VMware-Version für Ihren Nutzercluster.
YOUR_EMAIL_ADDRESS und ANOTHER_EMAIL_ADDRESS: Wenn Sie das Flag --admin-users nicht angeben, erhalten Sie als Clusterersteller standardmäßig Administratorberechtigungen für den Cluster. Wenn Sie jedoch --admin-users angeben, um einen anderen Nutzer als Administrator festzulegen, wird die Standardeinstellung überschrieben und es müssen sowohl Ihre E-Mail-Adresse als auch die des anderen Administrators enthalten sein. So fügen Sie beispielsweise zwei Administratoren hinzu:
```
    --admin-users=sara@example.com \
    --admin-users=amal@example.com
```
Wenn der Cluster erstellt wird, wendet die GKE On-Prem API die Richtlinien der rollenbasierten Zugriffssteuerung (Role-Based Access Control, RBAC) von Kubernetes auf den Cluster an, um Ihnen und anderen Administratoren die Kubernetes-Rolle clusterrole/cluster-admin zu gewähren. Diese gewährt vollständigen Zugriff auf jede Ressource im Cluster in allen Namespaces.

Hinweis: Zusätzlich zu den Kubernetes-RBAC-Richtlinien müssen Sie Nutzern, die keine Projektinhaber sind, einige IAM-Rollen (Identity and Access Management) zuweisen. Weitere Informationen zum Gewähren von IAM-Rollen finden Sie unter Erforderliche Rollen gewähren.

SERVICE_CIDR_BLOCK: Ein Bereich von IP-Adressen im CIDR-Format, der für Dienste in Ihrem Cluster verwendet wird. Muss mindestens ein /24-Bereich sein.
Beispiel: --service-address-cidr-blocks=10.96.0.0/20
POD_CIDR_BLOCK: Ein Bereich von IP-Adressen im CIDR-Format, der für Pods in Ihrem Cluster verwendet wird. Muss mindestens ein /18-Bereich sein.
Beispiel: --pod-address-cidr-blocks=192.168.0.0/16

--metal-lb-config-address-pools: Fügen Sie dieses Flag hinzu, um die Konfiguration für Adresspools anzugeben, die vom MetalLB-Load-Balancer verwendet werden sollen. Der Wert für das Flag hat folgendes Format:
```
--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;...' \
```
Der Wert umfasst Segmente, die mit den Keywords pool, avoid-buggy-ip, manual-assign und addresses beginnen. Trennen Sie die einzelnen Segmente durch Kommas.
- pool: Ein Name Ihrer Wahl für den Pool.
- avoid-buggy-ips1: Wenn Sie diesen Wert auf True festlegen, weist der MetalLB-Controller Diensten keine IP-Adressen zu, die auf .0 oder .255 enden. Dadurch wird das Problem vermieden, dass fehlerhafte Verbrauchergeräte versehentlich den an diese speziellen IP-Adressen gesendeten Traffic verwerfen. Wenn keine Angabe erfolgt, wird standardmäßig False verwendet.
- manual-assign: Wenn Sie nicht möchten, dass der MetalLB-Controller automatisch IP-Adressen aus diesem Pool den Diensten zuweist, legen Sie dafür True fest. Anschließend kann ein Entwickler einen Dienst vom Typ LoadBalancer erstellen und manuell eine der Adressen aus dem Pool angeben. Wenn keine Angabe erfolgt, wird manual-assign auf False gesetzt.
- In der Liste der addresses: Jede Adresse muss ein Bereich in CIDR-Notation oder mit Bindestrich als Bereich sein. Verwenden Sie /32 in CIDR-Notation, um eine einzelne IP-Adresse in einem Pool anzugeben (z. B. für die virtuelle IP-Adresse für eingehenden Traffic). Beispiel: 192.0.2.1/32.
Wichtige Hinweise:
- Setzen Sie den gesamten Wert in einfache Anführungszeichen.
- Leerzeichen sind nicht zulässig.
- Trennen Sie die einzelnen IP-Adressbereiche durch ein Semikolon.
Beispiel:
```
--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: Die IP-Adresse, die Sie auf dem Load-Balancer für den Kubernetes API-Server des Nutzerclusters konfiguriert haben.
Beispiel: --control-plane-vip=203.0.113.3
INGRESS_VIP: Die IP-Adresse, die Sie auf dem Load-Balancer für den Ingress-Proxy konfiguriert haben.
Beispiel: --ingress-vip=10.251.134.80

Die IP-Adresse für die virtuelle IP-Adresse für eingehenden Traffic muss sich in einem der MetalLB-Adresspools befinden.

--enable-dhcp: Geben Sie --enable-dhcp an, wenn Sie möchten, dass die Clusterknoten ihre IP-Adresse von einem von Ihnen bereitgestellten DHCP-Server abrufen. Geben Sie dieses Flag nicht an, wenn Sie statische IP-Adressen für Ihre Clusterknoten bereitstellen oder manuelles Load-Balancing einrichten möchten.

MetalLB und statische IP-Adressen

In diesem Beispiel wird gezeigt, wie Sie mit dem gebündelten MetalLB-Load-Balancer einen Nutzercluster erstellen und Ihren Clusterknoten statische IP-Adressen zuweisen.

Scrollen Sie bei Bedarf nach unten, um den Platzhalter ADMIN_CLUSTER_NAME für das Flag --admin-cluster-membership auszufüllen. In diesem Beispiel wird der vollständig angegebene Name des Administratorclusters verwendet, sodass Sie --admin-cluster-membership-location und --admin-cluster-membership-project nicht angeben müssen.

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,...

Ersetzen Sie Folgendes:

USER_CLUSTER_NAME: Ein Name Ihrer Wahl für Ihren Nutzercluster. Der Name kann nach dem Erstellen des Clusters nicht mehr geändert werden. Der Name muss:
- darf höchstens 40 Zeichen enthalten.
- darf nur kleingeschriebene, alphanumerische Zeichen und einen Bindestrich - enthalten.
- Er muss mit einem Buchstaben beginnen.
- Er muss mit einem alphanumerischen Zeichen enden.
FLEET_HOST_PROJECT_ID: Die ID des Projekts, in dem Sie den Cluster erstellen möchten. Das angegebene Projekt wird auch als Flotten-Hostprojekt verwendet. Dies muss dasselbe Projekt sein, für das der Administratorcluster registriert ist. Nachdem der Nutzercluster erstellt wurde, wird er automatisch bei der Flotte des ausgewählten Projekts registriert. Das Flotten-Hostprojekt kann nach dem Erstellen des Clusters nicht mehr geändert werden.
ADMIN_CLUSTER_NAME: Der Name des Administratorclusters, der den Nutzercluster verwaltet. Im Flag --admin-cluster-membership können Sie den vollständig angegebenen Clusternamen im folgenden Format verwenden:
```
    projects/FLEET_HOST_PROJECT_ID/locations/ADMIN_CLUSTER_REGION/memberships/ADMIN_CLUSTER_NAME
```
Alternativ können Sie --admin-cluster-membership wie im Beispielbefehl auf den Namen des Administratorclusters festlegen. Wenn Sie nur den Namen des Administratorclusters verwenden, legen Sie die Projekt-ID des Administratorclusters mit --admin-cluster-membership-project und den Standort mit --admin-cluster-membership-location fest. Der Standort des Administratorclusters ist entweder global oder eine Google Cloud-Region. Wenn Sie die Region suchen, führen Sie gcloud container fleet memberships list aus.
REGION: Die Google Cloud-Region, in der die GKE On-Prem API (gkeonprem.googleapis.com), der Flottendienst (gkehub.googleapis.com) und der Connect-Dienst (gkeconnect.googleapis.com) ausgeführt werden. Geben Sie us-west1 oder eine andere unterstützte Region an. Die Region kann nach dem Erstellen des Clusters nicht mehr geändert werden. Diese Einstellung gibt die Region an, in der Folgendes gespeichert wird:
- Die Nutzerclustermetadaten, die die GKE On-Prem API zum Verwalten des Clusterlebenszyklus benötigt
- Cloud Logging- und Cloud Monitoring-Daten von Systemkomponenten
- Das von Cloud-Audit-Logs erstellte Administrator-Audit-Log
Der Clustername, das Projekt und der Standort identifizieren zusammen den Cluster in Google Cloud eindeutig.

Wichtig: Wenn Sie Anthos Service Mesh installieren möchten, müssen Sie Version 1.19.3 oder höher installieren. Dies ist erforderlich, da die Fleet- und Connect-Dienste in einer Region ausgeführt werden.
VERSION: Die GKE on VMware-Version für Ihren Nutzercluster.
YOUR_EMAIL_ADDRESS und ANOTHER_EMAIL_ADDRESS: Wenn Sie das Flag --admin-users nicht angeben, erhalten Sie als Clusterersteller standardmäßig Administratorberechtigungen für den Cluster. Wenn Sie jedoch --admin-users angeben, um einen anderen Nutzer als Administrator festzulegen, wird die Standardeinstellung überschrieben und es müssen sowohl Ihre E-Mail-Adresse als auch die des anderen Administrators enthalten sein. So fügen Sie beispielsweise zwei Administratoren hinzu:
```
    --admin-users=sara@example.com \
    --admin-users=amal@example.com
```
Wenn der Cluster erstellt wird, wendet die GKE On-Prem API die Richtlinien der rollenbasierten Zugriffssteuerung (Role-Based Access Control, RBAC) von Kubernetes auf den Cluster an, um Ihnen und anderen Administratoren die Kubernetes-Rolle clusterrole/cluster-admin zu gewähren. Diese gewährt vollständigen Zugriff auf jede Ressource im Cluster in allen Namespaces.

Hinweis: Zusätzlich zu den Kubernetes-RBAC-Richtlinien müssen Sie Nutzern, die keine Projektinhaber sind, einige IAM-Rollen (Identity and Access Management) zuweisen. Weitere Informationen zum Gewähren von IAM-Rollen finden Sie unter Erforderliche Rollen gewähren.

SERVICE_CIDR_BLOCK: Ein Bereich von IP-Adressen im CIDR-Format, der für Dienste in Ihrem Cluster verwendet wird. Muss mindestens ein /24-Bereich sein.
Beispiel: --service-address-cidr-blocks=10.96.0.0/20
POD_CIDR_BLOCK: Ein Bereich von IP-Adressen im CIDR-Format, der für Pods in Ihrem Cluster verwendet wird. Muss mindestens ein /18-Bereich sein.
Beispiel: --pod-address-cidr-blocks=192.168.0.0/16

--metal-lb-config-address-pools: Fügen Sie dieses Flag hinzu, um die Konfiguration für Adresspools anzugeben, die vom MetalLB-Load-Balancer verwendet werden sollen. Der Wert für das Flag hat folgendes Format:
```
--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;...' \
```
Der Wert umfasst Segmente, die mit den Keywords pool, avoid-buggy-ip, manual-assign und addresses beginnen. Trennen Sie die einzelnen Segmente durch Kommas.
- pool: Ein Name Ihrer Wahl für den Pool.
- avoid-buggy-ips1: Wenn Sie diesen Wert auf True festlegen, weist der MetalLB-Controller Diensten keine IP-Adressen zu, die auf .0 oder .255 enden. Dadurch wird das Problem vermieden, dass fehlerhafte Verbrauchergeräte versehentlich den an diese speziellen IP-Adressen gesendeten Traffic verwerfen. Wenn keine Angabe erfolgt, wird standardmäßig False verwendet.
- manual-assign: Wenn Sie nicht möchten, dass der MetalLB-Controller automatisch IP-Adressen aus diesem Pool den Diensten zuweist, legen Sie dafür True fest. Anschließend kann ein Entwickler einen Dienst vom Typ LoadBalancer erstellen und manuell eine der Adressen aus dem Pool angeben. Wenn keine Angabe erfolgt, wird manual-assign auf False gesetzt.
- In der Liste der addresses: Jede Adresse muss ein Bereich in CIDR-Notation oder mit Bindestrich als Bereich sein. Verwenden Sie /32 in CIDR-Notation, um eine einzelne IP-Adresse in einem Pool anzugeben (z. B. für die virtuelle IP-Adresse für eingehenden Traffic). Beispiel: 192.0.2.1/32.
Wichtige Hinweise:
- Setzen Sie den gesamten Wert in einfache Anführungszeichen.
- Leerzeichen sind nicht zulässig.
- Trennen Sie die einzelnen IP-Adressbereiche durch ein Semikolon.
Beispiel:
```
--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: Die IP-Adresse, die Sie auf dem Load-Balancer für den Kubernetes API-Server des Nutzerclusters konfiguriert haben.
Beispiel: --control-plane-vip=203.0.113.3
INGRESS_VIP: Die IP-Adresse, die Sie auf dem Load-Balancer für den Ingress-Proxy konfiguriert haben.
Beispiel: --ingress-vip=10.251.134.80

Die IP-Adresse für die virtuelle IP-Adresse für eingehenden Traffic muss sich in einem der MetalLB-Adresspools befinden.

--static-ip-config-ip-blocks: Geben Sie das Standardgateway, die Subnetzmaske und eine Liste der statischen IP-Adressen für die Worker-Knoten im Nutzercluster an. Der Wert für das Flag hat folgendes Format:
```
--static-ip-config-ip-blocks 'gateway=GATEWAY,netmask=NETMASK,ips=IP_ADDRESS_1;IP_ADDRESS_2 HOST_2;...'
```
Der Wert umfasst Segmente, die mit den Keywords gateway, netmask und ips beginnen. Trennen Sie die Segmente durch Kommas.

Wichtige Hinweise:
- Setzen Sie den gesamten Wert in einfache Anführungszeichen.
- Leerzeichen sind nur zwischen einer IP-Adresse und einem Hostnamen zulässig.
Führen Sie in der Liste der IP-Adressen folgende Schritte aus:
- Sie können eine einzelne IP-Adresse oder einen CIDR-Block mit IP-Adressen angeben.
- Trennen Sie die einzelnen IP-Adressen oder CIDR-Blöcke durch ein Semikolon.
- Für eine einzelne IP-Adresse können Sie optional nach der IP-Adresse einen Hostnamen angeben. Trennen Sie die IP-Adresse und den Hostnamen durch ein Leerzeichen. Wenn Sie keinen Hostnamen angeben, verwendet GKE on VMware den Namen der VM aus vSphere als Hostname.
- Wenn Sie einen CIDR-Block angeben, geben Sie keinen Wert für den Hostnamen an.
Beispiel:
```
--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: Eine durch Kommas getrennte Liste der IP-Adressen der DNS-Server für die VMs.
DNS_SEARCH_DOMAIN: Eine durch Kommas getrennte Liste der DNS-Suchdomains, die von den Hosts verwendet werden sollen. Diese Domains werden als Teil einer Domainsuchliste verwendet.
Beispiel:
```
--dns-search-domains example.com,examplepetstore.com
```
NTP_SERVER: Eine durch Kommas getrennte Liste der IP-Adressen von Zeitservern, die von den VMs verwendet werden sollen.

F5 BIG-IP und DHCP

In diesem Beispiel wird gezeigt, wie Sie mit Ihrem F5 BIG-IP-Load-Balancer einen Nutzercluster erstellen und Ihren DHCP-Server verwenden, um IP-Adressen für Ihre Clusterknoten abzurufen.

Sie können F5 nur für den Nutzercluster verwenden, wenn Ihr Administratorcluster F5 verwendet. Installieren und konfigurieren Sie unbedingt den F5 BIG-IP-ADC, bevor Sie ihn in GKE on VMware einbinden.

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: Ein Name Ihrer Wahl für Ihren Nutzercluster. Der Name kann nach dem Erstellen des Clusters nicht mehr geändert werden. Der Name muss:
- darf höchstens 40 Zeichen enthalten.
- darf nur kleingeschriebene, alphanumerische Zeichen und einen Bindestrich - enthalten.
- Er muss mit einem Buchstaben beginnen.
- Er muss mit einem alphanumerischen Zeichen enden.
FLEET_HOST_PROJECT_ID: Die ID des Projekts, in dem Sie den Cluster erstellen möchten. Das angegebene Projekt wird auch als Flotten-Hostprojekt verwendet. Dies muss dasselbe Projekt sein, für das der Administratorcluster registriert ist. Nachdem der Nutzercluster erstellt wurde, wird er automatisch bei der Flotte des ausgewählten Projekts registriert. Das Flotten-Hostprojekt kann nach dem Erstellen des Clusters nicht mehr geändert werden.
ADMIN_CLUSTER_NAME: Der Name des Administratorclusters, der den Nutzercluster verwaltet. Im Flag --admin-cluster-membership können Sie den vollständig angegebenen Clusternamen im folgenden Format verwenden:
```
    projects/FLEET_HOST_PROJECT_ID/locations/ADMIN_CLUSTER_REGION/memberships/ADMIN_CLUSTER_NAME
```
Alternativ können Sie --admin-cluster-membership wie im Beispielbefehl auf den Namen des Administratorclusters festlegen. Wenn Sie nur den Namen des Administratorclusters verwenden, legen Sie die Projekt-ID des Administratorclusters mit --admin-cluster-membership-project und den Standort mit --admin-cluster-membership-location fest. Der Standort des Administratorclusters ist entweder global oder eine Google Cloud-Region. Wenn Sie die Region suchen, führen Sie gcloud container fleet memberships list aus.
REGION: Die Google Cloud-Region, in der die GKE On-Prem API (gkeonprem.googleapis.com), der Flottendienst (gkehub.googleapis.com) und der Connect-Dienst (gkeconnect.googleapis.com) ausgeführt werden. Geben Sie us-west1 oder eine andere unterstützte Region an. Die Region kann nach dem Erstellen des Clusters nicht mehr geändert werden. Diese Einstellung gibt die Region an, in der Folgendes gespeichert wird:
- Die Nutzerclustermetadaten, die die GKE On-Prem API zum Verwalten des Clusterlebenszyklus benötigt
- Cloud Logging- und Cloud Monitoring-Daten von Systemkomponenten
- Das von Cloud-Audit-Logs erstellte Administrator-Audit-Log
Der Clustername, das Projekt und der Standort identifizieren zusammen den Cluster in Google Cloud eindeutig.

Wichtig: Wenn Sie Anthos Service Mesh installieren möchten, müssen Sie Version 1.19.3 oder höher installieren. Dies ist erforderlich, da die Fleet- und Connect-Dienste in einer Region ausgeführt werden.
VERSION: Die GKE on VMware-Version für Ihren Nutzercluster.
YOUR_EMAIL_ADDRESS und ANOTHER_EMAIL_ADDRESS: Wenn Sie das Flag --admin-users nicht angeben, erhalten Sie als Clusterersteller standardmäßig Administratorberechtigungen für den Cluster. Wenn Sie jedoch --admin-users angeben, um einen anderen Nutzer als Administrator festzulegen, wird die Standardeinstellung überschrieben und es müssen sowohl Ihre E-Mail-Adresse als auch die des anderen Administrators enthalten sein. So fügen Sie beispielsweise zwei Administratoren hinzu:
```
    --admin-users=sara@example.com \
    --admin-users=amal@example.com
```
Wenn der Cluster erstellt wird, wendet die GKE On-Prem API die Richtlinien der rollenbasierten Zugriffssteuerung (Role-Based Access Control, RBAC) von Kubernetes auf den Cluster an, um Ihnen und anderen Administratoren die Kubernetes-Rolle clusterrole/cluster-admin zu gewähren. Diese gewährt vollständigen Zugriff auf jede Ressource im Cluster in allen Namespaces.

Hinweis: Zusätzlich zu den Kubernetes-RBAC-Richtlinien müssen Sie Nutzern, die keine Projektinhaber sind, einige IAM-Rollen (Identity and Access Management) zuweisen. Weitere Informationen zum Gewähren von IAM-Rollen finden Sie unter Erforderliche Rollen gewähren.

SERVICE_CIDR_BLOCK: Ein Bereich von IP-Adressen im CIDR-Format, der für Dienste in Ihrem Cluster verwendet wird. Muss mindestens ein /24-Bereich sein.
Beispiel: --service-address-cidr-blocks=10.96.0.0/20
POD_CIDR_BLOCK: Ein Bereich von IP-Adressen im CIDR-Format, der für Pods in Ihrem Cluster verwendet wird. Muss mindestens ein /18-Bereich sein.
Beispiel: --pod-address-cidr-blocks=192.168.0.0/16

F5_CONFIG_ADDRESS: Die Adresse Ihres F5 BIG-IP-Load-Balancers.
F5_CONFIG_PARTITION:Der Name einer BIG-IP-Partition, die Sie für Ihren Nutzercluster erstellt haben.
F5_CONFIG_SNAT_POOL: Der Name Ihres SNAT-Pools, falls zutreffend.

CONTROL_PLANE_VIP: Die IP-Adresse, die Sie auf dem Load-Balancer für den Kubernetes API-Server des Nutzerclusters konfiguriert haben.
Beispiel: --control-plane-vip=203.0.113.3
INGRESS_VIP: Die IP-Adresse, die Sie auf dem Load-Balancer für den Ingress-Proxy konfiguriert haben.
Beispiel: --ingress-vip=10.251.134.80

Die IP-Adresse für die virtuelle IP-Adresse für eingehenden Traffic muss sich in einem der MetalLB-Adresspools befinden.

--enable-dhcp: Geben Sie --enable-dhcp an, wenn Sie möchten, dass die Clusterknoten ihre IP-Adresse von einem von Ihnen bereitgestellten DHCP-Server abrufen. Geben Sie dieses Flag nicht an, wenn Sie statische IP-Adressen für Ihre Clusterknoten bereitstellen oder manuelles Load-Balancing einrichten möchten.

Manuelles Load-Balancing und statische IP-Adressen

In diesem Beispiel wird gezeigt, wie Sie einen Nutzercluster mit einem manuellen Load-Balancer erstellen und Ihren Clusterknoten statische IP-Adressen zuweisen.

Sie können nur dann einen manuellen Load-Balancer für den Nutzercluster verwenden, wenn Ihr Administratorcluster einen manuellen Load-Balancer verwendet. In GKE on VMware werden der Kubernetes API-Server, der Ingress-Proxy und der Add-on-Dienst für die Logaggregation jeweils von einem Kubernetes-Dienst vom Typ LoadBalancer bereitgestellt. Wählen Sie Ihre eigenen nodePort-Werte zwischen 30.000 und 32.767 für diese Dienste aus. Wählen Sie für den Ingress-Proxy einen nodePort-Wert für HTTP- und HTTPS-Traffic aus. Weitere Informationen finden Sie unter Manuellen Load-Balancing-Modus aktivieren.

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

Ersetzen Sie Folgendes:

USER_CLUSTER_NAME: Ein Name Ihrer Wahl für Ihren Nutzercluster. Der Name kann nach dem Erstellen des Clusters nicht mehr geändert werden. Der Name muss:
- darf höchstens 40 Zeichen enthalten.
- darf nur kleingeschriebene, alphanumerische Zeichen und einen Bindestrich - enthalten.
- Er muss mit einem Buchstaben beginnen.
- Er muss mit einem alphanumerischen Zeichen enden.
FLEET_HOST_PROJECT_ID: Die ID des Projekts, in dem Sie den Cluster erstellen möchten. Das angegebene Projekt wird auch als Flotten-Hostprojekt verwendet. Dies muss dasselbe Projekt sein, für das der Administratorcluster registriert ist. Nachdem der Nutzercluster erstellt wurde, wird er automatisch bei der Flotte des ausgewählten Projekts registriert. Das Flotten-Hostprojekt kann nach dem Erstellen des Clusters nicht mehr geändert werden.
ADMIN_CLUSTER_NAME: Der Name des Administratorclusters, der den Nutzercluster verwaltet. Im Flag --admin-cluster-membership können Sie den vollständig angegebenen Clusternamen im folgenden Format verwenden:
```
    projects/FLEET_HOST_PROJECT_ID/locations/ADMIN_CLUSTER_REGION/memberships/ADMIN_CLUSTER_NAME
```
Alternativ können Sie --admin-cluster-membership wie im Beispielbefehl auf den Namen des Administratorclusters festlegen. Wenn Sie nur den Namen des Administratorclusters verwenden, legen Sie die Projekt-ID des Administratorclusters mit --admin-cluster-membership-project und den Standort mit --admin-cluster-membership-location fest. Der Standort des Administratorclusters ist entweder global oder eine Google Cloud-Region. Wenn Sie die Region suchen, führen Sie gcloud container fleet memberships list aus.
REGION: Die Google Cloud-Region, in der die GKE On-Prem API (gkeonprem.googleapis.com), der Flottendienst (gkehub.googleapis.com) und der Connect-Dienst (gkeconnect.googleapis.com) ausgeführt werden. Geben Sie us-west1 oder eine andere unterstützte Region an. Die Region kann nach dem Erstellen des Clusters nicht mehr geändert werden. Diese Einstellung gibt die Region an, in der Folgendes gespeichert wird:
- Die Nutzerclustermetadaten, die die GKE On-Prem API zum Verwalten des Clusterlebenszyklus benötigt
- Cloud Logging- und Cloud Monitoring-Daten von Systemkomponenten
- Das von Cloud-Audit-Logs erstellte Administrator-Audit-Log
Der Clustername, das Projekt und der Standort identifizieren zusammen den Cluster in Google Cloud eindeutig.

Wichtig: Wenn Sie Anthos Service Mesh installieren möchten, müssen Sie Version 1.19.3 oder höher installieren. Dies ist erforderlich, da die Fleet- und Connect-Dienste in einer Region ausgeführt werden.
VERSION: Die GKE on VMware-Version für Ihren Nutzercluster.
YOUR_EMAIL_ADDRESS und ANOTHER_EMAIL_ADDRESS: Wenn Sie das Flag --admin-users nicht angeben, erhalten Sie als Clusterersteller standardmäßig Administratorberechtigungen für den Cluster. Wenn Sie jedoch --admin-users angeben, um einen anderen Nutzer als Administrator festzulegen, wird die Standardeinstellung überschrieben und es müssen sowohl Ihre E-Mail-Adresse als auch die des anderen Administrators enthalten sein. So fügen Sie beispielsweise zwei Administratoren hinzu:
```
    --admin-users=sara@example.com \
    --admin-users=amal@example.com
```
Wenn der Cluster erstellt wird, wendet die GKE On-Prem API die Richtlinien der rollenbasierten Zugriffssteuerung (Role-Based Access Control, RBAC) von Kubernetes auf den Cluster an, um Ihnen und anderen Administratoren die Kubernetes-Rolle clusterrole/cluster-admin zu gewähren. Diese gewährt vollständigen Zugriff auf jede Ressource im Cluster in allen Namespaces.

Hinweis: Zusätzlich zu den Kubernetes-RBAC-Richtlinien müssen Sie Nutzern, die keine Projektinhaber sind, einige IAM-Rollen (Identity and Access Management) zuweisen. Weitere Informationen zum Gewähren von IAM-Rollen finden Sie unter Erforderliche Rollen gewähren.

SERVICE_CIDR_BLOCK: Ein Bereich von IP-Adressen im CIDR-Format, der für Dienste in Ihrem Cluster verwendet wird. Muss mindestens ein /24-Bereich sein.
Beispiel: --service-address-cidr-blocks=10.96.0.0/20
POD_CIDR_BLOCK: Ein Bereich von IP-Adressen im CIDR-Format, der für Pods in Ihrem Cluster verwendet wird. Muss mindestens ein /18-Bereich sein.
Beispiel: --pod-address-cidr-blocks=192.168.0.0/16

CONTROL_PLANE_VIP: Die IP-Adresse, die Sie für den Load-Balancer für den Kubernetes API-Server des Nutzerclusters konfiguriert haben.

Beispiel: --control-plane-vip=203.0.113.3
CONTROL_PLANE_NODE_PORT: Ein nodePort-Wert für den Kubernetes API-Server.
INGRESS_VIP: Die IP-Adresse, die Sie auf dem Load-Balancer für den Ingress-Proxy konfiguriert haben.

Beispiel: --ingress-vip=203.0.113.4
INGRESS_HTTP_NODE_PORT: Ein nodePort-Wert für HTTP-Traffic zum Ingress-Proxy.
INGRESS_HTTPS_NODE_PORT: Ein nodePort-Wert für HTTPS-Traffic zum Ingress-Proxy.
KONNECTIVITY_SERVER_NODE_PORT: Ein nodePort-Wert für den Konnectivity-Server.

--static-ip-config-ip-blocks: Geben Sie das Standardgateway, die Subnetzmaske und eine Liste der statischen IP-Adressen für die Worker-Knoten im Nutzercluster an. Der Wert für das Flag hat folgendes Format:
```
--static-ip-config-ip-blocks 'gateway=GATEWAY,netmask=NETMASK,ips=IP_ADDRESS_1;IP_ADDRESS_2 HOST_2;...'
```
Der Wert umfasst Segmente, die mit den Keywords gateway, netmask und ips beginnen. Trennen Sie die Segmente durch Kommas.

Wichtige Hinweise:
- Setzen Sie den gesamten Wert in einfache Anführungszeichen.
- Leerzeichen sind nur zwischen einer IP-Adresse und einem Hostnamen zulässig.
Führen Sie in der Liste der IP-Adressen folgende Schritte aus:
- Sie können eine einzelne IP-Adresse oder einen CIDR-Block mit IP-Adressen angeben.
- Trennen Sie die einzelnen IP-Adressen oder CIDR-Blöcke durch ein Semikolon.
- Für eine einzelne IP-Adresse können Sie optional nach der IP-Adresse einen Hostnamen angeben. Trennen Sie die IP-Adresse und den Hostnamen durch ein Leerzeichen. Wenn Sie keinen Hostnamen angeben, verwendet GKE on VMware den Namen der VM aus vSphere als Hostname.
- Wenn Sie einen CIDR-Block angeben, geben Sie keinen Wert für den Hostnamen an.
Beispiel:
```
--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: Eine durch Kommas getrennte Liste der IP-Adressen der DNS-Server für die VMs.
DNS_SEARCH_DOMAIN: Eine durch Kommas getrennte Liste der DNS-Suchdomains, die von den Hosts verwendet werden sollen. Diese Domains werden als Teil einer Domainsuchliste verwendet.
Beispiel:
```
--dns-search-domains example.com,examplepetstore.com
```
NTP_SERVER: Eine durch Kommas getrennte Liste der IP-Adressen von Zeitservern, die von den VMs verwendet werden sollen.

Flags der Steuerungsebene

Wenn Sie für die Konfiguration der Steuerungsebene nicht standardmäßige Werte verwenden möchten, fügen Sie eines oder mehrere der folgenden Flags ein:

--cpus=vCPUS: Die Anzahl der vCPUs (mindestens 4) für jeden Knoten der Steuerungsebene für Ihren Nutzercluster. Wenn keine Angabe erfolgt, werden standardmäßig 4 vCPUs verwendet.
--memory=MEMORY: Die Arbeitsspeichergröße in Mebibyte (MiB) für jede Steuerungsebene für Ihren Nutzercluster. Der Mindestwert beträgt 8192 und muss ein Vielfaches von 4 sein. Wenn keine Angabe erfolgt, wird der Standardwert 8192 verwendet.
--replicas=NODES: Die Anzahl der Knoten der Steuerungsebene für Ihren Nutzercluster. Sie können beispielsweise einen Knoten der Steuerungsebene für eine Entwicklungsumgebung und drei Knoten der Steuerungsebene für Produktionsumgebungen (Hochverfügbarkeit) auswählen.
--enable-auto-resize: Wenn Sie die automatische Größenanpassung der Knoten der Steuerungsebene für den Nutzercluster aktivieren möchten, fügen Sie --enable-auto-resize ein. Bei der Größenanpassung werden die einem Knoten zugewiesenen vCPU- und Arbeitsspeicherressourcen automatisch angepasst. Wenn diese Option aktiviert ist, wird die Größe der Knoten der Steuerungsebene für den Nutzercluster entsprechend der Anzahl der Worker-Knoten im Nutzercluster angepasst. Je mehr Worker-Knoten Sie dem Nutzercluster hinzufügen, desto größer werden die Knoten der Steuerungsebene.
--enable-control-plane-v2: Wenn Sie Controlplane V2 aktivieren möchten, fügen Sie --enable-control-plane-v2 ein. Wenn die Steuerungsebene V2 aktiviert ist, wird die Steuerungsebene für einen Nutzercluster auf einem oder mehreren Knoten im Nutzercluster ausgeführt. Standardmäßig wird die Steuerungsebene für einen Nutzercluster auf einem oder mehreren Knoten im Administratorcluster ausgeführt (das sogenannte kubeception-Modell). Wenn die Steuerungsebene V2 aktiviert ist, gelten die Werte für --cpus und --memory für die Knoten der Steuerungsebene im Nutzercluster. Die Anzahl der Knoten wird durch die Anzahl der IP-Adressen bestimmt, die Sie in --control-plane-ip-block eingeben. Wenn die Steuerungsebene V2 nicht aktiviert ist, gelten die Werte für --cpus, --memory und --replicas für die Knoten der Steuerungsebene im Administratorcluster. Reservieren Sie genügend IP-Adressen für Ihren Administratorcluster.

Wenn Sie Controlplane V2 aktivieren, müssen Sie auch die folgenden Flags angeben:
- --dns-servers=DNS_SERVER_1,...: Eine durch Kommas getrennte Liste der IP-Adressen der DNS-Server für die VMs.
- --ntp-servers=NTP_SERVER_1,...: eine durch Kommas getrennte Liste der IP-Adressen von Zeitservern, die von den zu verwendenden VMs verwendet werden sollen.
- --control-plane-ip-block mit folgendem Format:
```
  --control-plane-ip-block 'gateway=CP_GATEWAY,netmask=CP_NETMASK,ips=CP_IP_ADDRESS_1;CP_IP_ADDRESS_2 CP_HOST_2'
```
  Der Wert umfasst Segmente, die mit den Keywords gateway, netmask und ips beginnen. Trennen Sie die Segmente durch Kommas.
  
  Wichtige Hinweise:
  - Setzen Sie den gesamten Wert in einfache Anführungszeichen.
  - Leerzeichen sind nur zwischen einer IP-Adresse und einem Hostnamen zulässig.
    
    Führen Sie in der Liste der IP-Adressen folgende Schritte aus:
  - Sie können eine einzelne IP-Adresse oder einen CIDR-Block mit IP-Adressen angeben.
  - Trennen Sie die einzelnen IP-Adressen oder CIDR-Blöcke durch ein Semikolon.
  - Für eine einzelne IP-Adresse können Sie nach der IP-Adresse optional einen Hostnamen angeben. Trennen Sie die IP-Adresse und den Hostnamen durch ein Leerzeichen.
  - Wenn Sie einen CIDR-Block angeben, geben Sie keinen Wert für den Hostnamen an.
    
    Beispiel:
```
--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`
```
- Optional: --dns-search-domains=DNS_SEARCH_DOMAIN_1,...: Eine durch Kommas getrennte Liste der DNS-Suchdomains für die zu verwendenden Hosts. Diese Domains werden als Teil einer Domainsuchliste verwendet.
  
  Beispiel:
```
--dns-search-domains example.com,examplepetstore.com
```
Eine vollständige Liste der Flags und ihrer Beschreibungen finden Sie in der Referenz zur gcloud CLI.

vSphere-Flags

Geben Sie bei Bedarf die folgenden optionalen Flags an:
--disable-aag-config: Wenn Sie dieses Flag nicht angeben, werden die Anti-Affinitätsregeln von VMware Distributed Resource Scheduler (DRS) automatisch für die Knoten Ihres Nutzerclusters erstellt. Dadurch werden sie auf mindestens drei physische Hosts in Ihrem Rechenzentrum verteilt. Prüfen Sie, ob Ihre vSphere-Umgebung die Anforderungen erfüllt. Wenn Ihr Cluster die Anforderungen nicht erfüllt, fügen Sie dieses Flag hinzu.

Hinweis: Wenn Sie Minimale Infrastruktur einrichten ausgeführt haben, haben Sie nur einen ESXi-Host. Achten Sie daher darauf, dieses Flag anzugeben.
--disable-vsphere-csi: Wenn Sie dieses Flag nicht angeben, werden die Komponenten der vSphere Container Storage Interface (CSI) im Nutzercluster bereitgestellt. Der CSI-Treiber wird in einem nativen Kubernetes-Cluster ausgeführt, der in vSphere bereitgestellt wird, um nichtflüchtige Volumes im vSphere-Speicher bereitzustellen. Weitere Informationen finden Sie unter Mit dem vSphere-CSI-Treiber (Container Storage Interface) arbeiten. Wenn Sie die CSI-Komponenten nicht bereitstellen möchten, fügen Sie dieses Flag hinzu.

Eine vollständige Liste der Flags und ihren Beschreibungen finden Sie in der Referenz zur gcloud CLI.

Bevor Sie den Befehl gcloud zum Erstellen des Clusters ausführen, sollten Sie --validate-only einbinden, um die Konfiguration zu validieren, die Sie in den Flags für den Befehl gcloud angegeben haben. Wenn Sie bereit sind, den Cluster zu erstellen, entfernen Sie dieses Flag und führen Sie den Befehl aus.

Die Ausgabe des Befehls sieht in etwa so aus:
```
Waiting for operation [projects/example-project-12345/locations/us-west1/operations/operation-1679543737105-5f7893fd5bae9-942b3f97-75e59179] to complete.
```
In der Beispielausgabe ist der String operation-1679543737105-5f7893fd5bae9-942b3f97-75e59179 der OPERATION_ID des Vorgangs mit langer Ausführungszeit. Sie können den Status des Vorgangs mit dem folgenden Befehl ermitteln:
```
gcloud container vmware operations describe OPERATION_ID \
  --project=FLEET_HOST_PROJECT_ID \
  --location=REGION
```
Weitere Informationen finden Sie unter gcloud container vmware Operations.

Das Erstellen des Nutzerclusters dauert mindestens 15 Minuten. Sie können den Cluster in der Google Cloud Console auf der Seite Anthos Clusters ansehen.

Knotenpool erstellen

Nachdem der Cluster erstellt wurde, müssen Sie mindestens einen Knotenpool erstellen, bevor Sie Arbeitslasten bereitstellen.
```
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
```
Ersetzen Sie Folgendes:
NODE_POOL_NAME: Ein Name Ihrer Wahl für den Knotenpool. Der Name:
- darf höchstens 40 Zeichen enthalten.
- darf nur kleingeschriebene, alphanumerische Zeichen und einen Bindestrich - enthalten.
- Er muss mit einem Buchstaben beginnen.
- Er muss mit einem alphanumerischen Zeichen enden.
USER_CLUSTER_NAME: Der Name des neu erstellten Nutzerclusters.
FLEET_HOST_PROJECT_ID: Die ID des Projekts, für das der Cluster registriert ist.
REGION: Die Google Cloud-Region, die Sie beim Erstellen des Clusters angegeben haben.
IMAGE_TYPE: Der Typ des Betriebssystem-Images, das auf den VMs im Knotenpool ausgeführt werden soll. Legen Sie einen der folgenden Werte fest: ubuntu_containerd oder cos.
BOOT_DISK_SIZE: Die Größe des Bootlaufwerks in Gibibyte (GiB) für jeden Knoten im Pool. Das Minimum beträgt 40 GiB.
vCPUs: Die Anzahl der vCPUs für jeden Knoten im Knotenpool. Der Mindestwert ist 4.
MEMORY: die Arbeitsspeichergröße in Mebibyte (MiB) für jeden Knoten im Pool. Das Minimum beträgt 8.192 MiB pro Worker-Knoten des Nutzerclusters und der Wert muss ein Vielfaches von 4 sein.
NODES: Die maximale Anzahl von Knoten im Knotenpool. Der Mindestwert ist 3.
Wenn Sie MetalLB als Load-Balancer verwenden, fügen Sie optional --enable-load-balancer hinzu, wenn Sie zulassen möchten, dass der MetalLB-Lautsprecher auf den Knoten im Pool ausgeführt wird. MetalLB muss in mindestens einem Knotenpool aktiviert sein. Wenn Sie dieses Flag nicht angeben, müssen Sie einen weiteren Knotenpool zur Verwendung für MetalLB erstellen.

Informationen zu optionalen Flags finden Sie unter Knotenpool hinzufügen und in der Referenz zur gcloud CLI.

Beispiele für gcloud-Befehle

MetalLB und 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.28.300-gke.123 \
    --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

Eine Beschreibung des Flags --metal-lb-config-address-pools finden Sie unter Load-Balancer.

MetalLB und statische IP-Adressen

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.28.300-gke.123 \
    --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 und 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.28.300-gke.123 \
    --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

Eine Beschreibung der F5-Flags finden Sie unter Load-Balancer.

Manuelles Load-Balancing und statische IP-Adressen

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.28.300-gke.123 \
    --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

Hinweise

Rufen Sie den Namen und den Standort der Flottenmitgliedschaft Ihres Administratorclusters ab:
```
gcloud container fleet memberships list \
    --project=FLEET_HOST_PROJECT_ID
```
Ersetzen Sie FLEET_HOST_PROJECT_ID durch die ID des Projekts, für das der Administratorcluster registriert ist.

Die Ausgabe sieht in etwa so aus:
```
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
```
Der Standort gibt an, wo die Fleet- und Connect-Dienste ausgeführt werden. Administratorcluster, die vor 1.28 erstellt wurden, werden von den globalen Flotten- und Connect-Diensten verwaltet. In Version 1.28 und höher können Sie beim Erstellen des Clusters entweder global oder eine Google Cloud-Region angeben.
Rufen Sie eine Liste der verfügbaren Versionen auf:
```
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
```
Ersetzen Sie Folgendes:
- ADMIN_CLUSTER_NAME: Der Name des Administratorclusters.
- FLEET_HOST_PROJECT_ID: Die ID des Projekts, für das der Administratorcluster registriert ist.
- ADMIN_CLUSTER_REGION: Region der Flottenmitgliedschaft des Administratorclusters. Dies ist entweder global oder eine Google Cloud-Region. Verwenden Sie den Standort für den Administratorcluster aus der Ausgabe von gcloud container fleet memberships list.
- REGION: Die Google Cloud-Region, die Sie beim Erstellen des Clusters verwenden. Dies ist die Region, in der die GKE On-Prem API und die Fleet and Connect-Dienste ausgeführt werden. Geben Sie us-west1 oder eine andere unterstützte Region an.
Die Ausgabe dieses Befehls sieht in etwa so aus:
```
versions:
- isInstalled: true
  version: 1.14.3-gke.25
- version: 1.14.4-gke.54
- version: 1.15.0-gke.581
```
Versionen, die Sie zum Erstellen eines Nutzerclusters verwenden können, sind mit isInstalled=true gekennzeichnet. Das bedeutet, dass der Administratorcluster die versionsspezifischen Komponenten hat, die zum Verwalten von Nutzerclustern dieser Version erforderlich sind. Informationen zum Erstellen eines Nutzerclusters mit einer anderen verfügbaren Version finden Sie unter Eine neuere Version als die Version des Administratorclusters installieren.

Beispiel

Sie können das folgende grundlegende Konfigurationsbeispiel verwenden, um einen Nutzercluster mit dem gebündelten MetalLB-Load-Balancer und einem Knotenpool zu erstellen.

Weitere Informationen und Beispiele finden Sie in der Referenzdokumentation zu google_gkeonprem_vmware_cluster.

Variablen in `terraform.tfvars` festlegen

Das Beispiel enthält eine Beispieldatei mit Variablen, die an main.tf übergeben werden muss. Sie zeigt, wie Sie den gebündelten MetalLB-Load-Balancer konfigurieren und Ihre Clusterknoten aktivieren, um ihre IP-Adressen von einem von Ihnen bereitgestellten DHCP-Server abzurufen.

Klonen Sie das Repository anthos-samples und wechseln Sie in das Verzeichnis, in dem sich das Terraform-Beispiel befindet:

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

Erstellen Sie eine Kopie der Datei terraform.tfvars.sample:
```
cp terraform.tfvars.sample terraform.tfvars
```
Ändern Sie die Parameterwerte in 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"] }
]
```
In der folgenden Liste werden die Variablen beschrieben:
- project_id: Die ID des Projekts, in dem Sie den Cluster erstellen möchten. Das angegebene Projekt wird auch als Flotten-Hostprojekt verwendet. Dies muss dasselbe Projekt sein, für das der Administratorcluster registriert ist. Nachdem der Nutzercluster erstellt wurde, wird er automatisch bei der Flotte des ausgewählten Projekts registriert. Das Flotten-Hostprojekt kann nach dem Erstellen des Clusters nicht mehr geändert werden.
- region: Die Google Cloud-Region, in der die GKE On-Prem API (gkeonprem.googleapis.com), der Flottendienst (gkehub.googleapis.com) und der Connect-Dienst (gkeconnect.googleapis.com) ausgeführt werden. Geben Sie us-west1 oder eine andere unterstützte Region an.
- admin_cluster_name: Der Name des Administratorclusters, der den Nutzercluster verwaltet. In diesem Beispiel wird davon ausgegangen, dass der Administratorcluster global als Region verwendet. Wenn Sie einen regionalen Administratorcluster haben:
  1. Öffnen Sie main.tf in einem Texteditor.
  2. Suchen Sie nach admin_cluster_membership, was in etwa so aussieht:
```
admin_cluster_membership = "projects/${var.project_id}/locations/global/memberships/${var.admin_cluster_name}"
```
  1. Ändern Sie global in die Region, die der Administratorcluster verwendet, und speichern Sie die Datei.
- on_prem_version: Die GKE on VMware-Version für Ihren Nutzercluster. In der Regel geben Sie dieselbe Version wie der Administratorcluster an. Wenn Sie eine höhere Version angeben möchten, installieren Sie eine neuere Version als die Version des Administratorclusters. Wenn Sie die Version des Administratorclusters nicht kennen, führen Sie gcloud container vmware clusters query-version-config aus. Dies ist der erste Schritt unter Version des Administratorclusters installieren.
- admin_user_emails: Eine Liste der E-Mail-Adressen der Nutzer, denen Administratorberechtigungen für den Cluster gewährt werden sollen. Fügen Sie Ihre E-Mail-Adresse hinzu, wenn Sie den Cluster verwalten möchten.
  
  Beim Erstellen des Clusters wendet die GKE On-Prem API die Richtlinien für die rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC) von Kubernetes auf den Cluster an, um den Administratoren die Kubernetes-Rolle clusterrole/cluster-admin zu gewähren. Diese gewährt vollständigen Zugriff auf jede Ressource im Cluster in allen Namespaces. Dadurch können sich Nutzer auch mit ihrer Google-Identität in der Konsole anmelden.
- cluster_name: Ein Name Ihrer Wahl für Ihren Nutzercluster. Der Name kann nach dem Erstellen des Clusters nicht mehr geändert werden. Der Name:
  - darf höchstens 40 Zeichen enthalten.
  - darf nur kleingeschriebene, alphanumerische Zeichen und einen Bindestrich - enthalten.
  - Er muss mit einem Buchstaben beginnen.
  - Er muss mit einem alphanumerischen Zeichen enden.
- control_plane_node_cpus: Die Anzahl der vCPUs für jeden Knoten der Steuerungsebene für Ihren Nutzercluster. Die Mindestanzahl beträgt 4 vCPUs.
- control_plane_node_memory: Die Arbeitsspeichergröße in Mebibyte (MiB) für jede Steuerungsebene für Ihren Nutzercluster. Der Mindestwert beträgt 8192 und muss ein Vielfaches von 4 sein.
- control_plane_node_replicas: Die Anzahl der Knoten der Steuerungsebene für Ihren Nutzercluster. Sie können beispielsweise einen Knoten der Steuerungsebene für eine Entwicklungsumgebung und drei Knoten der Steuerungsebene für Produktionsumgebungen (Hochverfügbarkeit) eingeben.
- control_plane_vip: Die virtuelle IP-Adresse (VIP), die Sie auf dem Load-Balancer für den Kubernetes API-Server des Nutzerclusters konfiguriert haben.
- ingress_vip: Die IP-Adresse, die Sie auf dem Load-Balancer für den Ingress-Proxy konfiguriert haben.
- lb_address_pools: Eine Liste von Zuordnungen, die die vom MetalLB-Load-Balancer zu verwendenden Adresspools definieren. Die virtuelle IP-Adresse für eingehenden Traffic muss sich in einem dieser Pools befinden. Geben Sie Folgendes an:
  - name: Ein Name für den Pool.
  - addresses: Ein Adressbereich in CIDR-Notation oder als Bereich mit Bindestrich. Wenn Sie eine einzelne IP-Adresse in einem Pool angeben möchten (z. B. für die virtuelle IP-Adresse für eingehenden Traffic), verwenden Sie /32 in CIDR-Notation, z. B. 192.0.2.1/32.
  Ersetzen Sie die Beispiel-IP-Adressen durch Ihre Werte und fügen Sie bei Bedarf weitere Adresspools hinzu.
Speichern Sie die Änderungen in terraform.tfvars. Wenn Sie keine optionalen Änderungen an main.tf vornehmen möchten, fahren Sie mit dem folgenden Abschnitt Cluster und Knotenpool erstellen fort.

Optional: Clustereinstellungen in `main.tf` konfigurieren

In diesem Abschnitt werden einige optionale Konfigurationsänderungen erläutert, die Sie in main.tf vornehmen können. Bevor Sie Änderungen vornehmen, sollten Sie eine Sicherung von main.tf erstellen:

cp main.tf main.tf.bak

IP-Adressierungsmodus für Worker-Knoten

main.tf konfiguriert den Cluster standardmäßig so, dass ein von Ihnen bereitgestellter DHCP-Server verwendet wird, um den Worker-Knoten des Clusters IP-Adressen zuzuweisen. DHCP wird durch Einfügen der dhcp_config-Zuordnung in den network_config-Block konfiguriert. Wenn Sie statische IP-Adressen für Ihre Worker-Knoten bereitstellen möchten, nehmen Sie die folgenden Änderungen an main.tf vor:

Ersetzen Sie den network_config-Block und fügen Sie einen static_ip_config-Block ein. Beispiel:

  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"
        }
      }
    }
  }

Ersetzen Sie Folgendes durch Ihre Werte:
- service_address_cidr_blocks: Ein Bereich von IP-Adressen im CIDR-Format, der für Dienste in Ihrem Cluster verwendet wird. Muss mindestens ein /24-Bereich sein.
- pod_address_cidr_blocks: Ein Bereich von IP-Adressen im CIDR-Format, der für Pods in Ihrem Cluster verwendet wird. Muss mindestens ein /18-Bereich sein.
- dns_servers: Eine Liste der IP-Adressen der DNS-Server für die VMs.
- ntp_servers: Eine Liste der IP-Adressen der Zeitserver für die zu verwendenden VMs.
- Ersetzen Sie im Block static_ip_config die Werte für netmask und gateway durch die Adressen Ihres Netzwerks. Ersetzen Sie ip und hostname durch die IP-Adressen und Hostnamen Ihrer Worker-Knoten.

Controlplane V2 konfigurieren

Standardmäßig konfiguriert main.tf die Steuerungsebene für den Nutzercluster für die Ausführung auf einem oder mehreren Knoten im Administratorcluster (bezeichnet als kubeception-Modell). Wenn Sie möchten, können Sie Controlplane V2 aktivieren. Wenn „Controlplane V2“ aktiviert ist, wird die Steuerungsebene für einen Nutzercluster auf einem oder mehreren Knoten im Nutzercluster selbst ausgeführt. Nehmen Sie zum Konfigurieren von Controlplane V2 die folgenden Änderungen an main.tf vor:

Fügen Sie nach der Zeile mit admin_cluster_membership die folgende Zeile ein:
```
  enable_control_plane_v2 = "true"
```

Fügen Sie dem network_config-Block eine control_plane_v2_config-Zuordnung hinzu. Beispiel:

  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"
      }
    }
  }

Ersetzen Sie die Werte für netmask und gateway durch IP-Adressen aus Ihrem Netzwerk. Ersetzen Sie ip und hostname durch die IP-Adressen der Knoten der Steuerungsebene.

Cluster und einen Knotenpool erstellen

Initialisieren und erstellen Sie den Terraform-Plan:
```
terraform init
```
Terraform installiert alle erforderlichen Bibliotheken, z. B. den Google Cloud-Anbieter.
Überprüfen Sie die Konfiguration und nehmen Sie bei Bedarf Änderungen vor:
```
terraform plan
```
Wenden Sie den Terraform-Plan an, um den Nutzercluster zu erstellen:
```
terraform apply
```
Das Erstellen des Nutzerclusters dauert etwa 15 Minuten oder länger. Das Erstellen des Knotenpools dauert weitere 15 Minuten. Sie können den Cluster in der Google Cloud Console auf der Seite Anthos Clusters ansehen.

Installieren Sie eine neue Version als die Version des Administratorclusters

Ein Administratorcluster kann Nutzercluster in verschiedenen Versionen verwalten. Wenn Sie einen Nutzercluster erstellen möchten, der eine höhere Version als der Administratorcluster ist, müssen Sie die Komponenten, die der Administratorcluster zum Verwalten von Nutzerclustern dieser Version benötigt, herunterladen und bereitstellen:

Rufen Sie eine Liste der verfügbaren Versionen auf:
```
gcloud container vmware clusters query-version-config \
    --admin-cluster-membership=ADMIN_CLUSTER_NAME \
    --admin-cluster-membership-project=FLEET_HOST_PROJECT_ID \
    --location=REGION
```
Ersetzen Sie Folgendes:
- ADMIN_CLUSTER_NAME: Der Name des Administratorclusters.
- FLEET_HOST_PROJECT_ID: Die ID des Projekts, für das der Administratorcluster registriert ist.
- REGION: Die Google Cloud-Region, in der die GKE On-Prem API ausgeführt wird. Dies ist die Region, die Sie beim Erstellen des Nutzerclusters angeben. Geben Sie us-west1 oder eine andere unterstützte Region an.
Die Ausgabe dieses Befehls sieht in etwa so aus:
```
versions:
- isInstalled: true
  version: 1.14.3-gke.25
- version: 1.14.4-gke.54
- version: 1.15.0-gke.581
```
Im Administratorcluster installierte Versionen werden mit isInstalled=true gekennzeichnet.
Falls noch nicht geschehen, registrieren Sie den Administratorcluster in der GKE On-Prem API. Nachdem der Cluster in der GKE On-Prem API registriert wurde, müssen Sie diesen Schritt nicht noch einmal ausführen.
Laden Sie die neue Version der Komponenten herunter und stellen Sie sie im Administratorcluster bereit:
```
gcloud vmware admin-clusters update ADMIN_CLUSTER_NAME \
    --project=FLEET_HOST_PROJECT_ID \
    --location=REGION \
    --required-platform-version=VERSION
```
Mit diesem Befehl wird die Version der Komponenten, die Sie in --required-platform-version angeben, in den Administratorcluster heruntergeladen und dann die Komponenten bereitgestellt. Sie können jetzt einen Nutzercluster mit der angegebenen Version erstellen.

Fehlerbehebung

Siehe Fehlerbehebung beim Erstellen und Upgraden von Clustern.

Nutzercluster erstellen

Hinweise

Nutzercluster erstellen

gkectl

Verfahrensübersicht

Ihre Konfigurationsdateien ausfüllen

name

gkeOnPremVersion

enableControlplaneV2

Kubeception

enableDataplaneV2

vCenter

Ein Rechenzentrum und einen vSphere-Cluster verwenden

Separate vSphere-Cluster verwenden

Separate vSphere-Rechenzentren verwenden

Separate vCenter-Konten verwenden

Separate Instanzen von vCenter Server verwenden

network

loadBalancer

advancedNetworking

multipleNetworkInterfaces

storage

masterNode

nodePools

antiAffinityGroups

stackdriver

gkeConnect

gkeOnPremAPI

usageMetering

cloudAuditLogging

Beispiel für ausgefüllte Konfigurationsdateien

user-ipblock.yaml

user-cluster.yaml

Konfigurationsdatei validieren

3. (Optional) Betriebssystem-Images in vSphere importieren und Container-Images in eine private Registry übertragen

4. Nutzercluster erstellen

Erstellen Sie einen Nutzercluster:

Suchen Sie die kubeconfig-Datei des Nutzerclusters.

5. Prüfen Sie, ob Ihr Nutzercluster ausgeführt wird

Console

Mehr erfahren

Clustergrundlagen

Steuerungsebene

Netzwerk

Load-Balancer

Gebündelt mit MetalLB

F5 BIG-IP

Manuell

Features

Knotenpools

gcloud-CLI

Hinweise

Beispiele

MetalLB und DHCP

MetalLB und statische IP-Adressen

F5 BIG-IP und DHCP

Manuelles Load-Balancing und statische IP-Adressen

Flags der Steuerungsebene

vSphere-Flags

Knotenpool erstellen

Beispiele für gcloud-Befehle

MetalLB und DHCP

MetalLB und statische IP-Adressen

F5 BIG-IP und DHCP

Manuelles Load-Balancing und statische IP-Adressen

Terraform

Hinweise

Beispiel

Variablen in terraform.tfvars festlegen

Optional: Clustereinstellungen in main.tf konfigurieren

IP-Adressierungsmodus für Worker-Knoten

Controlplane V2 konfigurieren

Cluster und einen Knotenpool erstellen

Installieren Sie eine neue Version als die Version des Administratorclusters

Fehlerbehebung

Nächste Schritte

`name`

`gkeOnPremVersion`

`enableControlplaneV2`

`enableDataplaneV2`

`vCenter`

`network`

`loadBalancer`

`advancedNetworking`

`multipleNetworkInterfaces`

`storage`

`masterNode`

`nodePools`

`antiAffinityGroups`

`stackdriver`

`gkeConnect`

`gkeOnPremAPI`

`usageMetering`

`cloudAuditLogging`

Variablen in `terraform.tfvars` festlegen

Optional: Clustereinstellungen in `main.tf` konfigurieren