Anthos-Cluster auf VMware ist jetzt Google Distributed Cloud (nur Software) für VMware. Weitere Informationen finden Sie in der Produktübersicht.

Diese Seite wurde von der Cloud Translation API übersetzt.

Nutzercluster erstellen

In Google Distributed Cloud werden Ihre Arbeitslasten in einem oder mehreren Nutzerclustern ausgeführt. In diesem Dokument wird beschrieben, 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 sollten, 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:
Berücksichtigen Sie bei der Einrichtung Ihres Flotten-Hostprojekts Ihr Tool, da Sie zusätzliche APIs aktivieren müssen, wenn Sie einen der GKE On-Prem API-Clients ausgewählt haben.
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.
Bestimmen Sie die Version des Nutzerclusters, den Sie installieren möchten. Beim Erstellen eines Nutzerclusters installieren Sie in der Regel die Version, die der Version des Administratorclusters entspricht. Sie können jedoch eine neuere Patchversion oder eine neuere Nebenversion installieren. Weitere Informationen finden Sie unter Version installieren, die höher als die Version des Administratorclusters ist.
Überlegen Sie, ob Ihr Nutzercluster die Steuerungsebene 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. Wir empfehlen dringend, die Steuerungsebene 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 im Dokument zur Planung von IP-Adressen, ob genügend IP-Adressen verfügbar sind.
Lesen Sie die Übersicht über das Load-Balancing und greifen Sie noch einmal auf Ihre Entscheidung für die Art des gewünschten Load-Balancers zurück. 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 den Nutzercluster erstellen.
Überlegen Sie, wie viele Knotenpools Sie benötigen und welches Betriebssystem Sie in den einzelnen Pools ausführen möchten.
Überlegen Sie, ob Sie separate vSphere-Cluster für Ihre Administrator- und Nutzercluster und ob Sie separate Rechenzentren verwenden möchten. Überlegen Sie sich auch, ob Sie separate Instanzen von vCenter Server verwenden möchten.
In Version 1.29 und höher sind serverseitige Preflight-Prüfungen standardmäßig aktiviert. Für serverseitige Preflight-Prüfungen sind zusätzliche Firewallregeln erforderlich. Suchen Sie unter Firewallregeln für Administratorcluster nach „Preflight-Prüfungen“ und prüfen Sie, ob alle erforderlichen Firewallregeln konfiguriert sind.

Wenn Sie bei serverseitigen Preflight-Prüfungen einen Nutzercluster mit gkectl erstellen, werden die Preflight-Prüfungen auf dem Administratorcluster und nicht lokal auf der Administratorworkstation ausgeführt. Serverseitige Preflight-Prüfungen werden auch ausgeführt, wenn Sie die Google Cloud Console, die Google Cloud CLI oder Terraform verwenden, um einen Nutzercluster zu erstellen.

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 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, treten möglicherweise Fehler auf, wenn Sie einige gkectl-Befehle wie "Validation Category: GCP - [UNKNOWN] GCP service: [Stackdriver] could not get GCP services" ausführen. Fügen Sie Ihren Befehlen den Parameter --skip-validation-gcp hinzu, um diese Fehler zu vermeiden.

Ihre Konfigurationsdateien ausfüllen

Führen Sie die folgenden 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. Sie gibt die Version von Google Distributed Cloud an. Beispiel: 1.29.100-gke.248.

`enableControlplaneV2`

Zum Erstellen eines Nutzerclusters mit aktivierter Steuerungsebene V2 legen Sie 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, die Steuerungsebene V2 zu aktivieren.

Kubeception

Wenn Sie dieses Feld auf false setzen, 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.
Lassen Sie den Abschnitt controlPlaneIPBlock weg.
Geben Sie in der IP-Blockdatei des Administratorclusters IP-Adressen für die Knoten der Steuerungsebene des Nutzerclusters an.

`enableDataplaneV2`

Setzen Sie enableDataplaneV2 auf true.

`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 möglicherweise separate vSphere-Cluster für Ihren Administrator- und Nutzercluster sowie für Ihre Administrator- und Nutzercluster separate Rechenzentren verwenden.

Ein Rechenzentrum und ein vSphere-Cluster verwenden

Die Standardoption besteht darin, ein Rechenzentrum und einen vSphere-Cluster für den Administrator- und den Nutzercluster zu verwenden. Legen Sie für diese Option in der Konfigurationsdatei des Nutzerclusters keine vCenter-Werte fest. Die vCenter-Werte werden vom 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 mit vCenter Server und eine oder mehrere physische Maschinen mit ESXi haben. Sie können dann Ihre lokale Instanz von vCenter Server verwenden, um eine vSphere-Objekthierarchie zu erstellen, einschließlich Rechenzentren, Clustern, Ressourcenpools, Datenspeichern und Ordnern.

Füllen Sie den gesamten Abschnitt vCenter 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 auch das Feld network.vCenter.networkName aus.

`network`

Legen Sie fest, wie die IP-Adressen der Worker-Knoten abgerufen werden 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 für Ihre Worker-Knoten statische IP-Adressen verwenden möchten, füllen Sie das Feld network.ipMode.ipBlockFilePath aus.

Die Knoten der Steuerungsebene für Ihren Nutzercluster müssen ihre IP-Adressen aus einer von Ihnen bereitgestellten Liste statischer Adressen abrufen. Dies ist selbst dann der Fall, wenn die Worker-Knoten ihre Adressen von einem DHCP-Server beziehen. Füllen Sie den Abschnitt network.controlPlaneIPBlock aus, um statische IP-Adressen für die Knoten der Steuerungsebene anzugeben. Wenn Sie einen Nutzercluster mit Hochverfügbarkeit wünschen, geben Sie drei IP-Adressen an. Andernfalls geben Sie eine IP-Adresse an.

Geben Sie 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, sind 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 dazu, wie viele IP-Adressen Sie benötigen, 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: einer oder drei. Sie können auch einen Datenspeicher für die Knoten der Steuerungsebene angeben und festlegen, ob Sie die automatische Größenanpassung für die Knoten der Steuerungsebene aktivieren möchten.

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

`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 Google Distributed Cloud DRS-Anti-Affinitätsregeln (Distributed Resource Scheduler) für Ihre Worker-Knoten erstellt, sodass 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 Abschnitt ist standardmäßig erforderlich. Das heißt, wenn Sie diesen Abschnitt nicht ausfüllen, müssen Sie das Flag --skip-validation-stackdriver angeben, wenn Sie gkectl create cluster ausführen.

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 (wenn das Feld in Ihrer Konfigurationsdatei enthalten ist). Wenn gkeOnPremAPI.enabled außerdem true ist, muss dieselbe Region 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 identisch sind, 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 ab Version 1.16 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 bei der 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 bei 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 bei der GKE On-Prem API registrieren möchten, schließen Sie diesen Abschnitt ein und setzen Sie gkeOnPremAPI.enabled auf false. Wenn Sie keine Cluster im Projekt registrieren möchten, deaktivieren Sie gkeonprem.googleapis.com (der Dienstname für die GKE On-Prem API) im Projekt. Eine Anleitung 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 festgelegt ist (wenn das Feld in Ihrer Konfigurationsdatei enthalten ist) und stackdriver.clusterLocation. Wenn gkeOnPremAPI.enabled den Wert true hat, muss dieselbe Region 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

Im Folgenden finden 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.29.100-gke.248
enableControlplaneV2: true
enableDataplaneV2: true
network:
  hostConfig:
    dnsServers:
    - "203.0.113.2"
    - "198.51.100.2"
    ntpServers:
    - "216.239.35.4"
  ipMode:
    type: "static"
    ipBlockFilePath: "user-ipblock.yaml"
  serviceCIDR: 10.96.0.0/20
  podCIDR: 192.168.0.0/16
  controlPlaneIPBlock:
    netmask: "255.255.255.0"
    gateway: "172.16.21.1"
    ips:
    - ip: "172.16.21.6"
      hostname: "cp-vm-1"
    - ip: "172.16.21.7"
      hostname: "cp-vm-2"
    - ip: "172.16.21.8"
      hostname: "cp-vm-3"
loadBalancer:
  vips:
    controlPlaneVIP: "172.16.21.40"
    ingressVIP: "172.16.21.30"
  kind: MetalLB
  metalLB:
    addressPools:
    - name: "address-pool-1"
      addresses:
      - "172.16.21.30-172.16.21.39"
masterNode:
  cpus: 4
  memoryMB: 8192
  replicas: 3
nodePools:
- name: "worker-node-pool"
  cpus: 4
  memoryMB: 8192
  replicas: 3
  enableLoadBalancer: true
antiAffinityGroups:
  enabled: true
gkeConnect:
  projectID: "my-project-123"
  location: "us-central1"
  registerServiceAccountKeyPath: "connect-register-sa-2203040617.json"
stackdriver:
  projectID: "my-project-123"
  clusterLocation: "us-central1"
  enableVPC: false
  serviceAccountKeyPath: "log-mon-sa-2203040617.json"
autoRepair:
  enabled: true

Dies sind die wichtigsten Punkte, die im vorherigen Beispiel zu verstehen sind:

Die statischen IP-Adressen für die Worker-Knoten werden in einer IP-Blockdatei angegeben. Die IP-Blockdatei hat vier Adressen, obwohl es nur drei Worker-Knoten gibt. Die zusätzliche IP-Adresse wird während des Clusterupgrades, -updates und der automatischen Reparatur benötigt.
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 bestimmt. Das liegt daran, dass die Worker-Knoten statische IP-Adressen haben. Wenn 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.
Steuerungsebene 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 für Dienste vom Typ LoadBalancer reservierten VIPs werden im Abschnitt loadBalancer.metalLB.addressPools der Nutzercluster-Konfigurationsdatei 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 Abschnitt vCenter. 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:

Ihr 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.29.100-gke.248-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 Anzeigen des Clusternamens können Sie Folgendes 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

Jetzt starten

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. Diese Einstellung gibt die Region an, 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 Folgendes gespeichert wird:
- 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
Durch den Clusternamen, das Projekt und den Standort wird der Cluster in Google Cloud eindeutig identifiziert.
Wählen Sie die Google Distributed Cloud-Version für Ihren Nutzercluster aus.
Als Ersteller des Clusters haben Sie Administratorberechtigungen für den Cluster. Optional können Sie im Bereich Autorisierung im Feld Clusteradministrator die E-Mail-Adresse eines anderen Nutzers eingeben, der den Cluster verwalten wird.

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 Ihnen und anderen Administratoren die Kubernetes-Rolle clusterrole/cluster-admin zu gewähren, die vollständigen Zugriff auf alle Ressourcen im Cluster in allen Namespaces ermöglicht.

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

Steuerungsebene

Für alle Felder im Abschnitt Steuerungsebene werden Standardwerte festgelegt. Überprüfen Sie die Standardeinstellungen und ändern Sie sie bei Bedarf.

Geben Sie im Feld vCPUs für Knoten der Steuerungsebene die Anzahl der vCPUs (mindestens 4) für jeden Knoten der Steuerungsebene Ihres Nutzerclusters ein.
Geben Sie im Feld Arbeitsspeicher des Knotens der Steuerungsebene die Arbeitsspeichergröße in MiB für jede Steuerungsebene Ihres Nutzerclusters in MiB ein (mindestens 8.192 und muss ein Vielfaches von 4 sein).
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 vCPU- und Arbeitsspeicherressourcen, die einem Knoten zugewiesen sind, 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 die Steuerungsebene V2 aktivieren, wird die Steuerungsebene für einen Nutzercluster auf einem oder mehreren Knoten im Nutzercluster selbst und nicht im Administratorcluster ausgeführt (als Kubeception bezeichnet).

Wenn Sie Steuerungsebene v2 aktivieren auswählen, wird der Abschnitt IP-Adressen für 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 Steuerungsebene V2 nicht aktiviert ist, gelten die Felder für vCPU, Arbeitsspeicher und die Anzahl der Knoten der Steuerungsebene für die Knoten im Administratorcluster. Achten Sie darauf, dass Sie genug IP-Adressen für Ihren Administratorcluster reservieren.
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 muss eine IP-Adresse für jeden Knoten und eine zusätzliche IP-Adresse für einen temporären Knoten haben, der während Clusterupgrades, Aktualisierungen und automatischer Reparaturen 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 Google Distributed Cloud den Namen der VM aus vSphere als Hostname.
4. Klicken Sie nach Bedarf auf + IP-Adresse hinzufügen, um weitere IP-Adressen einzugeben.
Im Abschnitt Dienst- und Pod-CIDRs bietet 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 Statischer IP-Modus 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 Übersicht über Load-Balancer.

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 und 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 den an den Kubernetes API-Server des Nutzerclusters gesendeten Traffics 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 dann für den Nutzercluster verwenden, wenn Ihr Administratorcluster F5 BIG-IP verwendet. Installieren und konfigurieren Sie den F5 BIG-IP-ADC, bevor Sie ihn in Google Distributed Cloud einbinden.

Der F5-Nutzername und das -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 Ihren Nutzercluster erstellt haben.
Geben Sie im Feld SNAT-Poolname gegebenenfalls den Namen des SNAT-Pools ein.
Klicken Sie auf Weiter.

Manuell

Sie können einen manuellen Load-Balancer nur dann für den Nutzercluster verwenden, wenn Ihr Administratorcluster einen manuellen Load-Balancer verwendet. In Google Distributed Cloud werden der Kubernetes API-Server und der Ingress-Proxy jeweils von einem Kubernetes-Dienst vom Typ LoadBalancer bereitgestellt. Wählen Sie Ihre eigenen nodePort-Werte im Bereich 30.000 bis 32.767 für diese Dienste aus. Wählen Sie für den Ingress-Proxy einen nodePort-Wert sowohl für HTTP- als auch für 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 in vSphere bereitgestellten Kubernetes-Cluster ausgeführt, 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 befolgt 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 statische IP-Adressen für die Knoten-IPs eingegeben haben, achten Sie darauf, dass 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 ausgewählt oder fügen Sie einen weiteren Knotenpool zur Verwendung für MetalLB hinzu.
Wenn Sie im Abschnitt Knotenpoolmetadaten (optional) Labels und Markierungen von Kubernetes 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 den Schlüssel, den Wert und die 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. Die Console zeigt Statusmeldungen an, während 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 deutlich 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 Fehler beim Erstellen von Nutzerclustern in der Google Cloud Console beheben.

gcloud-CLI

Sie verwenden den folgenden Befehl, um einen Nutzercluster zu erstellen:

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 des Nutzerclusters. Für einen leichteren Einstieg können Sie einen vollständigen Befehl im Abschnitt Beispiele 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 Version 1.28 erstellt wurden, werden von den globalen Fleet- und Connect-Diensten verwaltet. Ab Version 1.28 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 ab:
```
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: Die Mitgliedschaftsregion 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- und 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, werden mit isInstalled=true gekennzeichnet. Das bedeutet, dass der Administratorcluster die versionsspezifischen Komponenten hat, die er zum Verwalten von Nutzerclustern dieser Version benötigt. Wenn Sie einen Nutzercluster mit einer anderen verfügbaren Version erstellen möchten, finden Sie weitere Informationen unter Version höher als die des Administratorclusters installieren.

Beispiele

Die folgenden Beispiele zeigen, wie Sie einen Nutzercluster mit verschiedenen Load-Balancern erstellen. 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 Standardeinstellungen ändern möchten, fügen Sie die im Abschnitt Flags der Steuerungsebene beschriebenen Flags hinzu. Bei Bedarf können Sie auch einige vSphere-Einstellungen ändern.

Nachdem der Cluster ausgeführt wurde, müssen Sie vor dem Bereitstellen von Arbeitslasten einen Knotenpool hinzufügen, wie im Abschnitt Knotenpool erstellen beschrieben.

MetalLB und DHCP

In diesem Beispiel wird gezeigt, 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 von MetalLB und 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 den 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 verwenden, der folgendes Format hat:
```
    projects/FLEET_HOST_PROJECT_ID/locations/ADMIN_CLUSTER_REGION/memberships/ADMIN_CLUSTER_NAME
```
Alternativ können Sie --admin-cluster-membership auf den Namen des Administratorclusters festlegen, wie im Beispielbefehl. Wenn Sie nur den Namen des Administratorclusters verwenden, legen Sie die Projekt-ID des Administratorclusters mit der --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 ermitteln müssen, 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
Durch den Clusternamen, das Projekt und den Standort wird der Cluster in Google Cloud eindeutig identifiziert.

Wichtig: Wenn Sie Cloud Service Mesh installieren möchten, müssen Sie Version 1.19.3 oder höher installieren. Dies ist erforderlich, da die Flotten- 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 als Ersteller des Clusters angeben, erhalten Sie standardmäßig Administratorberechtigungen für den Cluster. Wenn Sie jedoch --admin-users angeben, um einen anderen Nutzer als Administrator festzulegen, wird der Standardwert überschrieben und Sie müssen sowohl Ihre E-Mail-Adresse als auch die E-Mail-Adresse des anderen Administrators angeben. So fügen Sie beispielsweise zwei Administratoren hinzu:
```
    --admin-users=sara@example.com \
    --admin-users=amal@example.com
```
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 Ihnen und anderen Administratoren die Kubernetes-Rolle clusterrole/cluster-admin zu gewähren, die vollständigen Zugriff auf alle Ressourcen im Cluster in allen Namespaces ermöglicht.

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

SERVICE_CIDR_BLOCK: Ein Bereich von IP-Adressen im CIDR-Format, die für Dienste in Ihrem Cluster verwendet werden sollen. 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 werden soll. 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 enthält Segmente, die mit den Keywords pool, avoid-buggy-ip, manual-assign und addresses beginnen. Trennen Sie die Segmente durch Kommas.
- pool: Ein Name Ihrer Wahl für den Pool.
- avoid-buggy-ips1: Wenn Sie True festlegen, weist der MetalLB-Controller Diensten keine IP-Adressen mit der Endung .0 oder .255 zu. Dadurch wird das Problem vermieden, dass fehlerhafte Nutzergeräte den Traffic verlieren, der an diese speziellen IP-Adressen gesendet wird. Wenn keine Angabe erfolgt, wird standardmäßig False verwendet.
- manual-assign: Wenn Sie nicht möchten, dass der MetalLB-Controller IP-Adressen aus diesem Pool automatisch Diensten zuweist, legen Sie diesen Wert auf 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 addresses: Jede Adresse muss ein Bereich in der CIDR-Schreibweise oder im Format mit Bindestrich 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 konfigurieren möchten.
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 die Clusterknoten ihre IP-Adresse von einem von Ihnen angegebenen DHCP-Server abrufen sollen. Lassen Sie dieses Flag weg, 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 einen Nutzercluster mit dem gebündelten MetalLB-Load-Balancer erstellen und den Clusterknoten statische IP-Adressen zuweisen.

Scrollen Sie gegebenenfalls 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 den 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 verwenden, der folgendes Format hat:
```
    projects/FLEET_HOST_PROJECT_ID/locations/ADMIN_CLUSTER_REGION/memberships/ADMIN_CLUSTER_NAME
```
Alternativ können Sie --admin-cluster-membership auf den Namen des Administratorclusters festlegen, wie im Beispielbefehl. Wenn Sie nur den Namen des Administratorclusters verwenden, legen Sie die Projekt-ID des Administratorclusters mit der --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 ermitteln müssen, 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
Durch den Clusternamen, das Projekt und den Standort wird der Cluster in Google Cloud eindeutig identifiziert.

Wichtig: Wenn Sie Cloud Service Mesh installieren möchten, müssen Sie Version 1.19.3 oder höher installieren. Dies ist erforderlich, da die Flotten- 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 als Ersteller des Clusters angeben, erhalten Sie standardmäßig Administratorberechtigungen für den Cluster. Wenn Sie jedoch --admin-users angeben, um einen anderen Nutzer als Administrator festzulegen, wird der Standardwert überschrieben und Sie müssen sowohl Ihre E-Mail-Adresse als auch die E-Mail-Adresse des anderen Administrators angeben. So fügen Sie beispielsweise zwei Administratoren hinzu:
```
    --admin-users=sara@example.com \
    --admin-users=amal@example.com
```
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 Ihnen und anderen Administratoren die Kubernetes-Rolle clusterrole/cluster-admin zu gewähren, die vollständigen Zugriff auf alle Ressourcen im Cluster in allen Namespaces ermöglicht.

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

SERVICE_CIDR_BLOCK: Ein Bereich von IP-Adressen im CIDR-Format, die für Dienste in Ihrem Cluster verwendet werden sollen. 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 werden soll. 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 enthält Segmente, die mit den Keywords pool, avoid-buggy-ip, manual-assign und addresses beginnen. Trennen Sie die Segmente durch Kommas.
- pool: Ein Name Ihrer Wahl für den Pool.
- avoid-buggy-ips1: Wenn Sie True festlegen, weist der MetalLB-Controller Diensten keine IP-Adressen mit der Endung .0 oder .255 zu. Dadurch wird das Problem vermieden, dass fehlerhafte Nutzergeräte den Traffic verlieren, der an diese speziellen IP-Adressen gesendet wird. Wenn keine Angabe erfolgt, wird standardmäßig False verwendet.
- manual-assign: Wenn Sie nicht möchten, dass der MetalLB-Controller IP-Adressen aus diesem Pool automatisch Diensten zuweist, legen Sie diesen Wert auf 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 addresses: Jede Adresse muss ein Bereich in der CIDR-Schreibweise oder im Format mit Bindestrich 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 konfigurieren möchten.
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 enthält 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.
In der Liste der IP-Adressen:
- Sie können eine einzelne IP-Adresse oder einen CIDR-Block von 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 einen Hostnamen nach der IP-Adresse 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 von DNS-Servern für die VMs.
DNS_SEARCH_DOMAIN: Eine durch Kommas getrennte Liste der DNS-Suchdomains, die von den zu verwendenden 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 dann für den Nutzercluster verwenden, wenn Ihr Administratorcluster F5 verwendet. Installieren und konfigurieren Sie den F5 BIG-IP-ADC, bevor Sie ihn in Google Distributed Cloud 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 den 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 verwenden, der folgendes Format hat:
```
    projects/FLEET_HOST_PROJECT_ID/locations/ADMIN_CLUSTER_REGION/memberships/ADMIN_CLUSTER_NAME
```
Alternativ können Sie --admin-cluster-membership auf den Namen des Administratorclusters festlegen, wie im Beispielbefehl. Wenn Sie nur den Namen des Administratorclusters verwenden, legen Sie die Projekt-ID des Administratorclusters mit der --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 ermitteln müssen, 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
Durch den Clusternamen, das Projekt und den Standort wird der Cluster in Google Cloud eindeutig identifiziert.

Wichtig: Wenn Sie Cloud Service Mesh installieren möchten, müssen Sie Version 1.19.3 oder höher installieren. Dies ist erforderlich, da die Flotten- 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 als Ersteller des Clusters angeben, erhalten Sie standardmäßig Administratorberechtigungen für den Cluster. Wenn Sie jedoch --admin-users angeben, um einen anderen Nutzer als Administrator festzulegen, wird der Standardwert überschrieben und Sie müssen sowohl Ihre E-Mail-Adresse als auch die E-Mail-Adresse des anderen Administrators angeben. So fügen Sie beispielsweise zwei Administratoren hinzu:
```
    --admin-users=sara@example.com \
    --admin-users=amal@example.com
```
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 Ihnen und anderen Administratoren die Kubernetes-Rolle clusterrole/cluster-admin zu gewähren, die vollständigen Zugriff auf alle Ressourcen im Cluster in allen Namespaces ermöglicht.

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

SERVICE_CIDR_BLOCK: Ein Bereich von IP-Adressen im CIDR-Format, die für Dienste in Ihrem Cluster verwendet werden sollen. 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 werden soll. 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 konfigurieren möchten.
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 die Clusterknoten ihre IP-Adresse von einem von Ihnen angegebenen DHCP-Server abrufen sollen. Lassen Sie dieses Flag weg, wenn Sie statische IP-Adressen für Ihre Clusterknoten bereitstellen oder manuelles Load-Balancing einrichten möchten.

Manueller Load-Balancer und statische IP-Adressen

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

Sie können einen manuellen Load-Balancer nur dann für den Nutzercluster verwenden, wenn Ihr Administratorcluster einen manuellen Load-Balancer verwendet. In Google Distributed Cloud 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 für diese Dienste Ihre eigenen nodePort-Werte im Bereich von 30.000 bis 32.767 aus. Wählen Sie für den Ingress-Proxy einen nodePort-Wert sowohl für HTTP- als auch für 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 den 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 verwenden, der folgendes Format hat:
```
    projects/FLEET_HOST_PROJECT_ID/locations/ADMIN_CLUSTER_REGION/memberships/ADMIN_CLUSTER_NAME
```
Alternativ können Sie --admin-cluster-membership auf den Namen des Administratorclusters festlegen, wie im Beispielbefehl. Wenn Sie nur den Namen des Administratorclusters verwenden, legen Sie die Projekt-ID des Administratorclusters mit der --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 ermitteln müssen, 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
Durch den Clusternamen, das Projekt und den Standort wird der Cluster in Google Cloud eindeutig identifiziert.

Wichtig: Wenn Sie Cloud Service Mesh installieren möchten, müssen Sie Version 1.19.3 oder höher installieren. Dies ist erforderlich, da die Flotten- 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 als Ersteller des Clusters angeben, erhalten Sie standardmäßig Administratorberechtigungen für den Cluster. Wenn Sie jedoch --admin-users angeben, um einen anderen Nutzer als Administrator festzulegen, wird der Standardwert überschrieben und Sie müssen sowohl Ihre E-Mail-Adresse als auch die E-Mail-Adresse des anderen Administrators angeben. So fügen Sie beispielsweise zwei Administratoren hinzu:
```
    --admin-users=sara@example.com \
    --admin-users=amal@example.com
```
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 Ihnen und anderen Administratoren die Kubernetes-Rolle clusterrole/cluster-admin zu gewähren, die vollständigen Zugriff auf alle Ressourcen im Cluster in allen Namespaces ermöglicht.

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

SERVICE_CIDR_BLOCK: Ein Bereich von IP-Adressen im CIDR-Format, die für Dienste in Ihrem Cluster verwendet werden sollen. 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 werden soll. Muss mindestens ein /18-Bereich sein.
Beispiel: --pod-address-cidr-blocks=192.168.0.0/16

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
CONTROL_PLANE_NODE_PORT: Ein nodePort-Wert für den Kubernetes API-Server.
INGRESS_VIP: Die IP-Adresse, die Sie für den 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 enthält 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.
In der Liste der IP-Adressen:
- Sie können eine einzelne IP-Adresse oder einen CIDR-Block von 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 einen Hostnamen nach der IP-Adresse 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 von DNS-Servern für die VMs.
DNS_SEARCH_DOMAIN: Eine durch Kommas getrennte Liste der DNS-Suchdomains, die von den zu verwendenden 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 die Standardwerte verwenden möchten, fügen Sie eines oder mehrere der folgenden Flags hinzu:

--cpus=vCPUS: Die Anzahl der vCPUs (mindestens 4) für jeden Knoten der Steuerungsebene in Ihrem Nutzercluster. Wenn keine Angabe erfolgt, beträgt der Standardwert 4 vCPUs.
--memory=MEMORY: Die Größe des Arbeitsspeichers in Mebibyte (MiB) für jede Steuerungsebene für Ihren Nutzercluster. Der Mindestwert ist 8.192 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 mit 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 vCPU- und Arbeitsspeicherressourcen, die einem Knoten zugewiesen sind, 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 die Steuerungsebene V2 aktivieren möchten, fügen Sie --enable-control-plane-v2 ein. Wenn Steuerungsebene V2 aktiviert ist, wird die Steuerungsebene für einen Nutzercluster auf einem oder mehreren Knoten im Nutzercluster selbst ausgeführt. Standardmäßig wird die Steuerungsebene für einen Nutzercluster auf einem oder mehreren Knoten im Administratorcluster ausgeführt (als Kubeception-Modell bezeichnet). 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. Achten Sie darauf, dass Sie genug IP-Adressen für Ihren Administratorcluster reservieren.

Wenn Sie die Steuerungsebene 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 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 enthält 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.
    
    In der Liste der IP-Adressen:
  - Sie können eine einzelne IP-Adresse oder einen CIDR-Block von 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 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 DRS-Anti-Affinitätsregeln (Distributed Resource Scheduler) von VMware 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. Wenn Ihr Cluster die Anforderungen nicht erfüllt, fügen Sie dieses Flag hinzu.

Hinweis: Wenn Sie der Anleitung Minimale Infrastruktur einrichten gefolgt sind, haben Sie nur einen ESXi-Host. Fügen Sie deshalb dieses Flag ein.
--disable-vsphere-csi: Wenn Sie dieses Flag nicht angeben, werden die CSI-Komponenten (vSphere Container Storage Interface) 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 ihrer Beschreibungen finden Sie in der Referenz zur gcloud CLI.

Bevor Sie den Befehl gcloud zum Erstellen des Clusters ausführen, sollten Sie --validate-only einschließen, 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 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 die OPERATION_ID des Vorgangs mit langer Ausführungszeit. Mit dem folgenden Befehl können Sie den Status des Vorgangs ermitteln:
```
gcloud container vmware operations describe OPERATION_ID \
  --project=FLEET_HOST_PROJECT_ID \
  --location=REGION
```
Weitere Informationen finden Sie unter gcloud container vmware-Vorgänge.

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

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. Das Minimum ist 4.
MEMORY: Die Größe des Arbeitsspeichers in Mebibyte (MiB) für jeden Knoten im Pool. Der Mindestwert 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. Das Minimum ist 3.
Wenn Sie MetalLB als Load-Balancer verwenden, fügen Sie optional --enable-load-balancer hinzu, wenn der MetalLB-Lautsprecher auf den Knoten im Pool ausgeführt werden soll. 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.

gcloud-Beispielbefehle

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

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

F5 BIG-IP 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.29.100-gke.248 \
    --admin-users=sara@example.com \
    --admin-users=amal@example.com \
    --enable-dhcp \
    --service-address-cidr-blocks=10.96.232.0/24 \
    --pod-address-cidr-blocks=192.168.0.0/16 \
    --f5-config-address=203.0.113.2 \
    --f5-config-partition=my-f5-admin-partition \
    --control-plane-vip=172.16.20.61 \
    --ingress-vip=172.16.20.62

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

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

Terraform

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 Version 1.28 erstellt wurden, werden von den globalen Fleet- und Connect-Diensten verwaltet. Ab Version 1.28 können Sie beim Erstellen des Clusters entweder global oder eine Google Cloud-Region angeben.
Rufen Sie eine Liste der verfügbaren Versionen ab:
```
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: Die Mitgliedschaftsregion 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- und 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, werden mit isInstalled=true gekennzeichnet. Das bedeutet, dass der Administratorcluster die versionsspezifischen Komponenten hat, die er zum Verwalten von Nutzerclustern dieser Version benötigt. Wenn Sie einen Nutzercluster mit einer anderen verfügbaren Version erstellen möchten, finden Sie weitere Informationen unter Version höher als die 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 kann. Sie zeigt, wie Sie den gebündelten MetalLB-Load-Balancer konfigurieren und dafür sorgen, dass Ihre Clusterknoten ihre IP-Adressen von einem von Ihnen bereitgestellten DHCP-Server abrufen können.

Klonen Sie das anthos-samples-Repository 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. Im 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, das 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 Google Distributed Cloud-Version für Ihren Nutzercluster. In der Regel geben Sie dieselbe Version wie im Administratorcluster an. Wenn Sie eine neuere Version angeben möchten, installieren Sie eine höhere 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 Eine neuere Version als die 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 unbedingt 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, die vollständigen Zugriff auf jede Ressource im Cluster in allen Namespaces ermöglicht. Auf diese Weise 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 ist 8.192 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 mit 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 für den 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-Schreibweise oder im Format mit Bindestrich. 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), 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: Konfigurieren Sie die Clustereinstellungen in `main.tf`

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

cp main.tf main.tf.bak

IP-Adressierungsmodus für Worker-Knoten

Standardmäßig konfiguriert main.tf den Cluster so, dass er einen von Ihnen bereitgestellten DHCP-Server verwendet, 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 folgende Änderungen an main.tf vor:

Ersetzen Sie den Block network_config 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, die für Dienste in Ihrem Cluster verwendet werden sollen. 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 werden soll. Muss mindestens ein /18-Bereich sein.
- dns_servers: Eine Liste der IP-Adressen von DNS-Servern für die VMs.
- ntp_servers: Eine Liste der IP-Adressen von Zeitservern, die von den VMs verwendet werden sollen.
- Ersetzen Sie im Block static_ip_config die Werte für netmask und gateway durch die Adressen für Ihr Netzwerk. Ersetzen Sie ip und hostname durch die IP-Adressen und Hostnamen der Worker-Knoten.

Steuerungsebene V2 konfigurieren

Standardmäßig konfiguriert main.tf die Steuerungsebene für den Nutzercluster so, dass sie auf einem oder mehreren Knoten im Administratorcluster ausgeführt wird (als kubeception-Modell bezeichnet). Wenn Sie möchten, können Sie die Steuerungsebene V2 aktivieren. Wenn die Steuerungsebene V2 aktiviert ist, wird die Steuerungsebene für einen Nutzercluster auf einem oder mehreren Knoten im Nutzercluster selbst ausgeführt. Nehmen Sie zum Konfigurieren der Steuerungsebene V2 folgende Ä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 Block network_config 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 Steuerebene.

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 und weitere 15 Minuten, um den Knotenpool zu erstellen. Sie können den Cluster in der Google Cloud Console auf der Seite Anthos Clusters anzeigen lassen.

Installieren Sie eine Version, die höher als die Version des Administratorclusters ist

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

Rufen Sie eine Liste der verfügbaren Versionen ab:
```
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 annotiert.
Registrieren Sie den Administratorcluster bei der GKE On-Prem API, falls noch nicht geschehen. Nachdem der Cluster bei 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, auf 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 ein 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

Jetzt starten

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

Manueller Load-Balancer und statische IP-Adressen

Flags der Steuerungsebene

vSphere-Flags

Knotenpool erstellen

gcloud-Beispielbefehle

MetalLB und DHCP

MetalLB- und statische IP-Adressen

F5 BIG-IP und DHCP

Manueller Load-Balancer und statische IP-Adressen

Terraform

Hinweise

Beispiel

Variablen in terraform.tfvars festlegen

Optional: Konfigurieren Sie die Clustereinstellungen in main.tf

IP-Adressierungsmodus für Worker-Knoten

Steuerungsebene V2 konfigurieren

Cluster und einen Knotenpool erstellen

Installieren Sie eine Version, die höher als die Version des Administratorclusters ist

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: Konfigurieren Sie die Clustereinstellungen in `main.tf`