Nutzercluster erstellen

In Google Distributed Cloud werden Ihre Arbeitslasten in einem oder mehreren Nutzerclustern ausgeführt. In diesem Dokument wird gezeigt, wie Sie einen Nutzercluster erstellen. Wenn Sie Topologiedomains verwenden möchten, lesen Sie den Abschnitt Nutzercluster zur Verwendung mit Topologiedomains erstellen.

Diese Seite richtet sich an Administratoren, Architekten und Betreiber, die technische Infrastrukturen einrichten, überwachen und verwalten. Weitere Informationen zu gängigen Rollen und Beispielaufgaben, auf die wir in Google Cloud -Inhalten verweisen, finden Sie unter Häufig verwendete GKE-Nutzerrollen und -Aufgaben.

Ab Version 1.33 werden alle neuen Cluster als erweiterte Cluster erstellt. Lesen Sie sich unbedingt den Abschnitt Unterschiede beim Ausführen erweiterter Cluster durch.

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

• gkectl
• Google Cloud Console
• Google Cloud CLI
• Terraform

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

Informationen dazu, welches Tool für Sie geeignet sein könnte, finden Sie unter Tool zum Verwalten des Clusterlebenszyklus auswählen.

Hinweise

• Wenn Sie den Nutzercluster mit gkectl erstellen möchten, müssen Sie Ihre Administrator-Workstation einrichten und sich bei ihr anmelden können, wie unter Administrator-Workstation erstellen beschrieben.

• Prüfen Sie, ob auf Ihrer Administrator-Workstation die erforderliche Version von gkectl installiert ist. In der Regel verwenden Sie dieselbe Version von gkectl wie die Version, die beim Erstellen des Clusters verwendet wird. Sie geben die Clusterversion im Feld gkeOnPremVersion in der Clusterkonfigurationsdatei an. Bei der Clustererstellung werden die folgenden Versionsregeln erzwungen:

  • Die Nebenversion gkectl darf nicht niedriger als die Nebenversion für den Cluster sein. So ist es beispielsweise nicht zulässig, einen Cluster der Version 1.30 mit gkectl Version 1.29 zu erstellen. Patchversionen spielen keine Rolle. Sie können beispielsweise gkectl Version 1.29.0-gke.1456 verwenden, um einen Cluster mit einer höheren Patchversion wie 1.29.1000-gke.94 zu erstellen.

  • Die Nebenversion gkectl darf nicht mehr als zwei Nebenversionen höher als die Clusterversion sein. Wenn Sie beispielsweise einen Cluster der Version 1.28 erstellen, kann die gkectl-Version 1.29 oder 1.30 sein. Sie können gkectl Version 1.31 jedoch nicht verwenden, da sie drei Nebenversionen höher ist als die Clusterversion.

  Falls erforderlich, lesen Sie den Abschnitt gkectl herunterladen, um eine unterstützte Version von gkectl zu erhalten.

• Richten Sie Ihre Google Cloud -Ressourcen ein, falls noch nicht geschehen. Eine Anleitung dazu finden Sie in den folgenden Dokumenten:

  • Google Cloud CLI installieren
  • Cloud-Projekte erstellen
  • Dienstkonten erstellen

  Denken Sie bei der Einrichtung Ihres Flotten-Hostprojekts an die Wahl Ihres Tools, denn wenn Sie sich für einen der GKE On-Prem API-Clients entschieden haben, gibt es zusätzliche APIs, die Sie aktivieren müssen. Eine Liste der APIs finden Sie unter APIs in Ihrem Flotten-Hostprojekt aktivieren.

• Bevor Sie einen Nutzercluster erstellen, müssen Sie einen Administratorcluster haben, um den Nutzercluster zu verwalten. Erstellen Sie, falls noch nicht geschehen, eine Administratorworkstation und einen Administratorcluster.

• Legen Sie die Version des Nutzerclusters fest, die Sie installieren möchten. Wenn Sie einen Nutzercluster erstellen, installieren Sie in der Regel die Version, die der Version des Administratorclusters entspricht. Wenn Sie eine andere Version in einem Nutzercluster installieren möchten, lesen Sie den Abschnitt Versionsregeln.

• Wenn Sie Version 1.30 oder höher installieren möchten, ist Controlplane V2 erforderlich. Auch wenn Sie Version 1.29 oder niedriger installieren, empfehlen wir, Controlplane V2 zu aktivieren. Wenn Controlplane V2 aktiviert ist, wird die Steuerungsebene für den Nutzercluster auf einem oder mehreren Knoten im Nutzercluster selbst ausgeführt. 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.

• Lesen Sie das Dokument zur Planung von IP-Adressen und achten Sie darauf, dass genügend IP-Adressen verfügbar sind.

• Lesen Sie die Übersicht über das Load Balancing und prüfen Sie noch einmal Ihre Entscheidung, welche Art von Load Balancer Sie verwenden möchten. Sie können den gebündelten MetalLB-Load-Balancer verwenden oder einen Load-Balancer Ihrer Wahl manuell konfigurieren. Beim manuellen Load-Balancing müssen Sie den Load-Balancer einrichten, bevor Sie Ihren Nutzercluster erstellen.

• Überlegen Sie sich, wie viele Knotenpools Sie benötigen und welches Betriebssystem Sie in jedem Ihrer Pools ausführen möchten.

• Überlegen Sie sich, ob Sie separate vSphere-Cluster für Ihren Administratorcluster und Ihre Nutzercluster verwenden möchten und ob Sie separate Rechenzentren verwenden möchten. Überlegen Sie 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 in den Firewallregeln für Administratorcluster nach „Preflight-Prüfungen“ und achten Sie darauf, dass alle erforderlichen Firewallregeln konfiguriert sind.

  Bei serverseitigen Preflight-Prüfungen werden die Preflight-Prüfungen bei der Erstellung eines Nutzerclusters mit gkectl auf dem Administratorcluster und nicht lokal auf der Administrator-Workstation ausgeführt. Serverseitige Preflight-Prüfungen werden auch ausgeführt, wenn Sie einen Nutzercluster mit der Google Cloud Console, der Google Cloud CLI oder Terraform erstellen.

Nutzercluster mit dem Tool Ihrer Wahl erstellen

In diesem Abschnitt finden Sie eine Anleitung zum Erstellen eines Nutzerclusters mit gkectl, der Console, der gcloud CLI und Terraform.

gkectl

Verfahrensübersicht

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

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

2. Optional: Importieren Sie Betriebssystem-Images in vSphere und übertragen Sie Container-Images in die private Registry, falls erforderlich.

   Führen Sie gkectl prepare aus.

3. Nutzercluster erstellen

   Führen Sie gkectl create cluster aus, um einen Cluster zu erstellen, wie in der Konfigurationsdatei angegeben.

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

   Rufen Sie mit kubectl die Clusterknoten auf.

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

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

Ihre Konfigurationsdateien ausfüllen

Wenn Sie gkeadm zum Erstellen Ihrer Administrator-Workstation verwendet haben, hat gkeadm eine Vorlage für die Konfigurationsdatei des Nutzerclusters mit dem Namen user-cluster.yaml generiert. Außerdem hat gkeadm einige Felder mit Werten versehen.

Wenn Sie Ihre Administrator-Workstation nicht mit gkeadm erstellt haben, können Sie mit gkectl eine Vorlage für die Konfigurationsdatei des Nutzerclusters generieren.

So generieren Sie eine Vorlage für die Konfigurationsdatei des Nutzerclusters:

gkectl create-config cluster --config=OUTPUT_FILENAME --gke-on-prem-version=VERSION

Dabei gilt:

OUTPUT_FILENAME: Pfad Ihrer Wahl für die generierte Vorlage. Wenn Sie dieses Flag weglassen, benennt gkectl die Datei user-cluster.yaml und speichert sie im aktuellen Verzeichnis.

VERSION: die gewünschte Versionsnummer. Beispiel: gkectl create-config cluster --gke-on-prem-version=1.33.100-gke.89.

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. Gibt die Version von Google Distributed Cloud an. Beispiel: 1.33.100-gke.89.

enableAdvancedCluster

Wenn Sie in Version 1.31 das erweiterte Cluster-Feature aktivieren möchten, legen Sie enableAdvancedCluster auf true fest. Dieses Feld muss auf true festgelegt werden, wenn für den Administratorcluster erweiterte Cluster aktiviert sind.

Beachten Sie die folgenden Unterschiede zwischen den Versionen:

• In Version 1.31 befindet sich das erweiterte Cluster-Feature in der Vorschau:

  • Sie können Advanced Cluster nur beim Erstellen neuer Cluster der Version 1.31 aktivieren.

  • Nachdem der erweiterte Cluster aktiviert wurde, können Sie kein Upgrade des Clusters auf Version 1.32 durchführen. Aktivieren Sie den erweiterten Cluster nur in einer Testumgebung.

• In Version 1.32 ist die erweiterte Clusterfunktion allgemein verfügbar.

  • Nutzercluster werden standardmäßig als erweiterte Cluster erstellt. Sie müssen enableAdvancedCluster explizit auf false setzen, wenn Sie einen Cluster ohne erweiterte Funktionen erstellen möchten.

  • Für Cluster, in denen die Funktion „Erweiterte Cluster“ aktiviert ist, werden Clusterupgrades unterstützt.

• In Version 1.33 und höher werden alle Cluster als erweiterte Cluster erstellt. Wenn Sie enableAdvancedCluster auf false festlegen, schlägt die Clustererstellung fehl.

enableControlplaneV2

Zum Erstellen eines Nutzerclusters, für den Controlplane V2 aktiviert ist, legen Sie Folgendes fest: enableControlplaneV2 auf true.

Wenn Sie erweiterte Cluster aktivieren, müssen Sie enableControlplaneV2 auf true festlegen.

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

kubeception

Wenn Sie dieses Feld auf false festlegen, verwendet der Cluster Kubeception. Mit kubeception läuft die Steuerungsebene für den Nutzercluster auf Knoten im Administratorcluster.

Für einen Kubeception-Cluster:

• Setzen Sie enableControlplaneV2 auf false.

• Füllen Sie den Abschnitt controlPlaneIPBlock nicht aus.

• Geben Sie IP-Adressen für die Knoten der Steuerungsebene des Nutzerclusters in der IP-Blockdatei des Administratorclusters an.

enableDataplaneV2

Legen Sie enableDataplaneV2 auf true fest.

vCenter

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

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

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

Insbesondere möchten Sie vielleicht getrennte vSphere-Cluster für Ihren Administrator-Cluster und Ihre Nutzercluster verwenden, und Sie möchten vielleicht getrennte Rechenzentren für Ihren Administrator-Cluster und Ihre Nutzercluster verwenden.

Ein Rechenzentrum und einen vSphere-Cluster verwenden

Die Standardoption ist die Verwendung eines Rechenzentrums und eines vSphere-Clusters für den Administrator- und Nutzercluster. Legen Sie für diese Option keine vCenter-Werte in der Konfigurationsdatei des Nutzerclusters 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 Administrator- 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 in der Konfigurationsdatei des Nutzerclusters vCenter.datacenter angeben, müssen Sie außerdem 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 Administratorcluster-Rechenzentrum, während das vCenter-Konto für den Nutzercluster nur auf das Rechenzentrum des Nutzerclusters zugreifen muss.

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 bedeutet, dass der Administratorcluster und ein zugehöriger Nutzercluster unterschiedliche vCenter Server-Instanzen verwenden.

An einem Edge-Standort könnten Sie beispielsweise einen physischen Computer mit vCenter Server und einen oder mehrere physische Computer mit ESXi einsetzen. 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 Abschnitt vCenter in der Nutzercluster-Konfigurationsdatei. 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. Beispiele:

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 Worker-Knoten ihre IP-Adressen abrufen sollen. Folgende Optionen sind verfügbar:

• Von einem DHCP-Server, den Sie im Voraus eingerichtet haben. Legen Sie network.ipMode.type auf "dhcp" fest.

• Aus einer Liste der von Ihnen angegebenen statischen IP-Adressen. Legen Sie network.ipMode.type auf "static" fest und erstellen Sie eine IP-Blockdatei, die die statischen IP-Adressen bereitstellt. Ein Beispiel für eine IP-Blockdatei finden Sie unter Beispiel für ausgefüllte Konfigurationsdateien.

Wenn Sie sich für die Verwendung statischer IP-Adressen für Ihre Worker-Knoten entschieden haben, füllen Sie 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 beziehen. Dies ist auch dann der Fall, wenn Ihre Worker-Knoten ihre Adressen von einem DHCP-Server beziehen. Um statische IP-Adressen für die Knoten der Steuerungsebene anzugeben, füllen Sie den Abschnitt network.controlPlaneIPBlock aus. Wenn Sie einen hochverfügbaren Nutzercluster (HA, High Availability) erstellen möchten, geben Sie drei IP-Adressen an. Geben Sie andernfalls 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. Wenn Sie statische IP-Adressen für Ihre Worker-Knoten 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. Wie viele IP-Adressen Sie benötigen, erfahren 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 auf der Steuerungsebene Sie für Ihren Nutzercluster wünschen: Geben Sie 3 für einen hochverfügbaren (HA) Cluster oder 1 für einen Nicht-HA-Cluster an. Sie können auch einen Datenspeicher für die Knoten der Steuerungsebene angeben und festlegen, ob die automatische Größenanpassung für die Knoten der Steuerungsebene aktiviert werden soll.

Wenn das Feld enableAdvancedCluster true ist, müssen Sie das Feld replicas auf 3 setzen. In erweiterten Clustern werden nur HA-Nutzercluster unterstützt.

Vergessen Sie nicht, dass Sie die IP-Adressen für die Knoten der Steuerungsebene im Abschnitt network.controlPlaneIPBlock 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.

Wenn Sie einen erweiterten Cluster aktivieren, legen Sie nodePools[i]osImageType auf ubuntu_cgroupv2 oder ubuntu_containerd fest.

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 Anti-Affinitätsregeln von Distributed Resource Scheduler (DRS) für Ihre Worker-Knoten erstellt, wodurch diese 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. Wenn Sie diesen Abschnitt nicht ausfüllen, müssen Sie bei der Ausführung von gkectl create cluster das Flag --skip-validation-stackdriver angeben.

Beachten Sie die folgenden Anforderungen für neue Cluster:

• Die ID in stackdriver.projectID muss mit der ID in gkeConnect.projectID und cloudAuditLogging.projectID übereinstimmen.

• Die in stackdriver.clusterLocation festgelegte Google Cloud -Region muss mit der in cloudAuditLogging.clusterLocation und gkeConnect.location übereinstimmen. Wenn gkeOnPremAPI.enabled 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 ID in stackdriver.projectID und cloudAuditLogging.projectID ü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.

Wichtig: Wenn Sie Cloud Service Mesh in einem regionalen Cluster installieren möchten, müssen Sie Version 1.19.3 oder höher installieren.

Wenn Sie gkeConnect.location in die Konfigurationsdatei aufnehmen, muss die von Ihnen 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 und höher die GKE On-Prem API in IhremGoogle Cloud -Projekt aktiviert ist, werden alle Cluster im Projekt automatisch in der GKE On-Prem API in der Region angemeldet, die in stackdriver.clusterLocation konfiguriert wurde. Die Region gkeOnPremAPI.location muss mit der Region übereinstimmen, die in cloudAuditLogging.clusterLocation, gkeConnect.location (wenn das Feld in Ihrer Konfigurationsdatei enthalten ist) und stackdriver.clusterLocation angegeben ist.

• Wenn Sie alle Cluster im Projekt für die GKE On-Prem API registrieren möchten, müssen Sie die Schritte unter Vorbereitung zur Aktivierung und Verwendung der GKE On-Prem API im Projekt ausführen.

• Wenn Sie den Cluster nicht in der GKE On-Prem API registrieren möchten, fügen Sie diesen Abschnitt hinzu und setzen Sie gkeOnPremAPI.enabled auf false. Wenn Sie keine Cluster in dem Projekt registrieren möchten, deaktivieren Sie gkeonprem.googleapis.com (der Dienstname für die GKE On-Prem API) in dem Projekt. Eine Anleitung finden Sie unter Dienste deaktivieren.

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 folgende Anforderungen:

• Wenn Sie den erweiterten Cluster aktivieren, legen Sie cloudAuditLogging.serviceAccountKeyPath auf denselben Pfad wie stackdriver.serviceAccountKeyPath fest.

• 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 in gkeConnect.location und stackdriver.clusterLocation übereinstimmen. Wenn außerdem gkeOnPremAPI.enabled true ist, 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

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

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.33.100-gke.89
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

Im obigen Beispiel sind dies die wichtigsten Punkte:

• Das Feld nodePools.replicas ist auf 3 gesetzt. Das bedeutet, dass es drei Worker-Knoten in "worker-node-pool" gibt. Alle Worker-Knoten verwenden statische IP-Adressen, da network.ipMode.type auf "static" festgelegt ist.

• Die statischen IP-Adressen für die Worker-Knoten werden in einer IP-Blockdatei angegeben. Die IP-Blockdatei enthält vier Adressen, obwohl es nur drei Worker-Knoten gibt. Die zusätzliche IP-Adresse wird während des Clusterupgrades, des 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 vorgesehen. Das liegt daran, dass die Worker-Knoten statische IP-Adressen haben. Wenn die Worker-Knoten ihre IP-Adressen von einem DHCP-Server beziehen würden, wären diese DNS- und NTP-Server nur für die Knoten der Steuerungsebene.

• Die statischen IP-Adressen für die drei Knoten der Steuerungsebene werden im Abschnitt network.controlPlaneIPBlock der Konfigurationsdatei des Nutzerclusters angegeben. Für diesen Block ist keine zusätzliche IP-Adresse erforderlich.

• Controlplane V2 ist aktiviert.

• Das Feld masterNode.replicas ist auf 3 festgelegt, sodass der Cluster eine Steuerungsebene mit Hochverfügbarkeit hat.

• Die virtuelle IP-Adresse der Steuerungsebene und die virtuelle IP-Adresse für eingehenden Traffic befinden sich beide im selben VLAN wie die Worker-Knoten und die Knoten der Steuerungsebene.

• Die VIPs, die für Dienste vom Typ „LoadBalancer“ reserviert sind, werden im Abschnitt loadBalancer.metalLB.addressPools der Konfigurationsdatei des Nutzerclusters angegeben. Diese VIPs befinden sich im selben VLAN wie die Worker-Knoten und die Knoten der Steuerungsebene. Die in diesem Abschnitt angegebenen VIPs müssen die virtuelle IP-Adresse für eingehenden Traffic und die virtuelle IP-Adresse der Steuerungsebene nicht enthalten.

• Die Konfigurationsdatei des Nutzerclusters enthält keinen vCenter-Abschnitt. Der Nutzercluster verwendet also die gleichen 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.

(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 hat einen anderen vCenter-Ordner 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: Pfad der Datei "kubeconfig" Ihres Administratorclusters

• BUNDLE: der Pfad der Bundle-Datei. Diese Datei befindet sich in Ihrer Administrator-Workstation in /var/lib/gke/bundles/. Beispiele:

  /var/lib/gke/bundles/gke-onprem-vsphere-1.33.100-gke.89-full.tgz
  

• USER_CLUSTER_CONFIG: Pfad Ihrer Nutzercluster-Konfigurationsdatei

Nutzercluster erstellen

Führen Sie den folgenden Befehl aus, um einen Nutzercluster zu erstellen:

gkectl create cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

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

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. Um den Clusternamen anzuzeigen, können Sie Folgendes ausführen:

kubectl config get-clusters --kubeconfig USER_CLUSTER_KUBECONFIG

In der Ausgabe wird der Name des Clusters angezeigt. Beispiele:

NAME
my-user-cluster

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

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. Beispiele:

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

1. Rufen Sie in der Google Cloud Console die Seite VM-Cluster erstellen auf.

   Zur Seite „VM-Cluster erstellen“

2. Wählen Sie das Google Cloud -Projekt aus, in dem Sie den Cluster erstellen möchten. Das ausgewählte Projekt wird 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.

3. Wählen Sie im Abschnitt Clustertyp auswählen die Option Nutzercluster für einen vorhandenen Administratorcluster erstellen aus.

Clustergrundlagen

Geben Sie grundlegende Informationen zum Cluster ein.

1. Geben Sie einen Namen für den Nutzercluster ein.

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

3. Wählen Sie im Feld GCP API-Standort die Region Google Cloud 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)
   • Connect-Dienst (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
   • Die von Cloud-Audit-Logs erstellten Administrator-Audit-Logs

   Anhand des Clusternamens, des Projekts und des Standorts kann der Cluster in Google Cloudeindeutig identifiziert werden.

4. Wählen Sie die Google Distributed Cloud-Version für Ihren Nutzercluster.

5. Als Ersteller des Clusters erhalten Sie Administratorberechtigungen für den Cluster. Optional: Geben Sie im Bereich Autorisierung im Feld Administratornutzer des Clusters die E-Mail-Adresse eines anderen Nutzers ein, der den Cluster verwalten wird.

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

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

6. Klicken Sie auf Weiter, um zum Abschnitt Steuerungsebene zu gelangen.

Steuerungsebene

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

1. Geben Sie im Feld vCPUs für Knoten der Steuerungsebene die Anzahl der vCPUs (mindestens 4) für jeden Knoten der Steuerungsebene für Ihren Nutzercluster ein.

2. Geben Sie im Feld Arbeitsspeicher für Knoten der Steuerungsebene die Arbeitsspeichergröße in MiB (muss mindestens 8.192 und ein Vielfaches von 4 sein) für jede Steuerungsebene für Ihren Nutzercluster ein.

3. Wählen Sie unter Knoten der Steuerungsebene die Anzahl der Knoten der Steuerungsebene für den Nutzercluster aus. Sie können beispielsweise einen Knoten für die Steuerungsebene für eine Entwicklungsumgebung und drei Knoten für die Steuerungsebene für Hochverfügbarkeit- und Produktionsumgebungen auswählen.

4. Wählen Sie optional Knotengröße automatisch anpassen aus. Bei der Größenanpassung werden die einem Knoten zugewiesenen vCPU- und Arbeitsspeicherressourcen automatisch angepasst. Wenn diese Option aktiviert ist, wird die Größe der Knoten auf der Steuerungsebene des Nutzerclusters entsprechend der Anzahl der Worker-Knoten im Nutzercluster angepasst. Wenn Sie also dem Nutzercluster weitere Worker-Knoten hinzufügen, wird die Größe der Knoten auf der Steuerungsebene erhöht.

5. Geben Sie im Abschnitt IP-Adressen der Knoten der Steuerungsebene die IP-Adressen für das Gateway, die Subnetzmaske und die Knoten der Steuerungsebene ein.

6. Klicken Sie auf Weiter, um den Abschnitt Netzwerk aufzurufen.

Netzwerk

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

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

2. 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 VM-Namen aus vSphere als Hostnamen.

   4. Klicken Sie nach Bedarf auf + IP-Adresse hinzufügen, um weitere IP-Adressen einzugeben.

3. Im Abschnitt Service- und Pod-CIDRs stellt die Console die folgenden Adressbereiche für Ihren Kubernetes-Service und -Pod bereit:

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

4. Wenn Sie Modus für statische IP-Adressen oder Steuerungsebene v2 aktivieren ausgewählt haben, geben Sie folgende Informationen im Abschnitt Hostkonfiguration ein:

   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.

5. Klicken Sie auf Weiter, um zum Abschnitt Load-Balancer zu gelangen.

Load-Balancer

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

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

Gebündelt mit MetalLB

Konfigurieren Sie gebündeltes Load-Balancing mit MetalLB. Sie können MetalLB nur dann 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 von MetalLB und einen Vergleich mit den anderen Load-Balancing-Optionen finden Sie unter Gebündeltes Load-Balancing mit MetalLB.

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

2. Klicken Sie ggf. auf Adresspool hinzufügen.

3. 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 des Nutzerclusters gesendeten Traffic 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.

4. 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. Achten Sie darauf, den F5 BIG-IP-ADC vor der Einbindung in Google Distributed Cloud zu installieren und zu konfigurieren.

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

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

2. Geben Sie im Feld Adresse die Adresse Ihres F5 BIG-IP-Load-Balancers ein.

3. Geben Sie im Feld Partition den Namen einer BIG-IP-Partition ein, die Sie für Ihren Administratorcluster erstellt haben.

4. Geben Sie im Feld SNAT-Poolname gegebenenfalls den Namen des SNAT-Pools ein.

5. Klicken Sie auf Weiter.

Manuell

Sie können nur dann einen manuellen Load-Balancer für den Nutzercluster verwenden, wenn Ihr Administratorcluster einen manuellen Load-Balancer verwendet. In Google Distributed Cloud werden der Kubernetes API-Server und der Ingress-Proxy jeweils von einem Kubernetes-Service vom Typ LoadBalancer bereitgestellt. Wählen Sie für diese Services Ihre eigenen nodePort-Werte im Bereich von 30.000 bis 32.767 aus. Für den Ingress-Proxy muss ein nodePort-Wert sowohl für HTTP- als auch HTTPS-Traffic ausgewählt werden. Weitere Informationen finden Sie unter Manuellen Load-Balancing-Modus aktivieren.

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

2. Geben Sie im Feld Port für Knoten der Steuerungsebene den Wert nodePort für den Kubernetes API-Server ein.

3. Geben Sie im Feld Ingress-HTTP-Knotenport einen nodePort-Wert für HTTP-Traffic zum Ingress-Proxy ein.

4. Geben Sie im Feld Knotenport für eingehenden HTTPS-Traffic einen nodePort-Wert für den HTTPS-Traffic zum Ingress-Proxy ein.

5. Geben Sie im Feld Knotenport für Konnectivity-Server einen nodePort-Wert für den Konnectivity-Server ein.

6. Klicken Sie auf Weiter.

Features

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

1. Folgendes ist automatisch aktiviert und kann nicht deaktiviert werden:

   • Cloud Logging von Systemdiensten

   • Cloud Monitoring von Systemdiensten

   • Audit-Log für Administratoraktivitäten

2. 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 nativen Kubernetes-Cluster ausgeführt, der in vSphere implementiert ist, 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 der Einrichtung der minimalen Infrastruktur gefolgt sind, haben Sie nur einen ESXi-Host. Achten Sie daher darauf, Anti-Affinitätsgruppen aktivieren zu deaktivieren.

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

1. 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 (mindestens 4 pro Nutzercluster-Worker) ein.
   3. Geben Sie die Größe des Arbeitsspeichers in Mebibyte (MiB) für jeden Knoten im Pool ein (mindestens 8.192 MiB pro Nutzercluster-Worker-Knoten und muss ein Vielfaches von 4 sein).
   4. Geben Sie im Feld Knoten die Anzahl der Knoten im Pool ein (mindestens 3). Wenn Sie im Abschnitt Netzwerk für die Knoten-IP-Adressen statische IP-Adressen eingegeben haben, achten Sie darauf, dass Sie genügend IP-Adressen eingegeben haben, um diese Knoten des Nutzerclusters zu verarbeiten.
   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 für MetalLB hinzu.

2. Wenn Sie Labels und Markierungen von Kubernetes hinzufügen möchten, gehen Sie im Abschnitt Knotenpool-Metadaten (optional) 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 den Effekt für die Markierung ein. Wiederholen Sie diese Schritte für alle Suchabfragen, für die dies erforderlich ist.

3. 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 geprüft und der Cluster in Ihrem Rechenzentrum erstellt wird.

   Wenn bei der Prüfung der Einstellungen ein Fehler auftritt, wird in der Console eine Fehlermeldung angezeigt, die klar genug sein sollte, um das Konfigurationsproblem zu beheben. Versuchen Sie danach noch einmal, den Cluster zu erstellen.

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

gcloud-CLI

Mit dem folgenden Befehl erstellen Sie einen Nutzercluster:

gcloud container vmware clusters create

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

gcloud container vmware node-pools create

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

Informationen einholen

Erfassen Sie Informationen, die Sie zum Erstellen des Clusters benötigen.

1. 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, in dem 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 Flotten- und Connect-Dienste ausgeführt werden. Vor 1.28 erstellte Administratorcluster werden von der globalen Flotte und Connect-Diensten verwaltet. Ab 1.28 können Sie entweder global oder eine Google Cloud -Region angeben, wenn Sie den Administratorcluster erstellen. Sie geben die Region im Flag --admin-cluster-membership-location in den folgenden Beispielbefehelen an.

2. 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, bei dem der Administratorcluster registriert ist.

   • ADMIN_CLUSTER_REGION: Die Region der Flottenmitgliedschaft für den Administratorcluster. Diese ist entweder global oder eine Google CloudRegion. 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 Nutzerclusters verwenden möchten. In dieser Region wird die GKE On-Prem API ausgeführt und ihre Metadaten gespeichert.

     • Wenn der Administratorcluster in der GKE On-Prem API registriert ist, verwenden Sie dieselbe Region wie für den Administratorcluster. Führen Sie den folgenden Befehl aus, um die Region des Administratorclusters zu ermitteln:

       gcloud container vmware admin-clusters list \
         --project=FLEET_HOST_PROJECT_ID \
         --location=-
       

     • Wenn der Administratorcluster nicht in der GKE On-Prem API registriert ist, geben Sie us-west1 oder eine andere unterstützte Region an. Wenn Sie den Administratorcluster anschließend in der GKE On-Prem API registrieren, verwenden Sie dieselbe Region wie für den Nutzercluster.

   Die Ausgabe des gcloud container vmware clusters query-version-config-Befehls sieht in etwa so aus:

   versions:
   - isInstalled: true
     version: 1.28.800-gke.109
   - version: 1.29.0-gke.1456
   - version: 1.29.100-gke.248
   - version: 1.29.200-gke.245
   - version: 1.29.300-gke.184
   

   Außerdem wird eine Erklärung zu den Versionen ausgegeben, die Sie zum Erstellen oder Aktualisieren von Nutzerclustern verwenden können. Zulässige Versionen sind mit isInstalled: true annotiert. Das bedeutet, dass der Administratorcluster über die versionsspezifischen Komponenten verfügt, die er zur Verwaltung von Nutzerclustern dieser Version benötigt. Wenn Sie eine im Administratorcluster installierte Version verwenden möchten, fahren Sie mit dem Abschnitt Beispiele fort, um den Nutzercluster zu erstellen.

Andere Version installieren

Ein Administratorcluster kann Nutzercluster mit unterschiedlichen Versionen verwalten. In der Ausgabe des Befehls query-version-config werden andere Versionen aufgeführt, die Sie beim Erstellen des Clusters verwenden können. Wenn Sie einen Nutzercluster erstellen möchten, der eine andere Version als der Administratorcluster hat, müssen Sie die Komponenten, die der Administratorcluster zur Verwaltung von Nutzerclustern dieser Version benötigt, folgendermaßen herunterladen und bereitstellen:

gcloud container vmware admin-clusters update ADMIN_CLUSTER_NAME \
    --project=FLEET_HOST_PROJECT_ID \
    --location=REGION \
    --required-platform-version=VERSION

Ersetzen Sie VERSION durch eine der Versionen, die in der Ausgabe des query-version-config-Befehls aufgeführt sind.

Mit diesem Befehl wird die Version der Komponenten, die Sie in --required-platform-version angeben, auf den Administratorcluster heruntergeladen und anschließend bereitgestellt. Sie können jetzt einen Nutzercluster mit der angegebenen Version erstellen.

Wenn Sie gcloud container vmware clusters query-version-config noch einmal ausführen, wird die von Ihnen angegebene Version mit isInstalled: true gekennzeichnet.

Beispiele

In den folgenden Beispielen wird gezeigt, wie Sie einen Nutzercluster mit verschiedenen Load Balancern erstellen, bei dem Controlplane V2 aktiviert ist. Mit Controlplane V2 wird die Steuerungsebene für einen Nutzercluster auf einem oder mehreren Knoten im Nutzercluster selbst ausgeführt. Wir empfehlen, Controlplane V2 zu aktivieren. Ab Version 1.30 muss Controlplane V2 für neue Nutzercluster aktiviert sein. Informationen zu den verfügbaren Load-Balancing-Optionen finden Sie unter Übersicht über Load-Balancer.

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

Bevor Sie den gcloud-Befehl zum Erstellen des Clusters ausführen, können Sie --validate-only einfügen, um die Konfiguration zu prüfen, die Sie in den Flags des gcloud-Befehl angegeben haben. Wenn Sie den Cluster erstellen möchten, entfernen Sie dieses Flag und führen den Befehl aus.

Wenn Sie nach etwa einer Minute oder länger nach dem Ausführen des Befehls gcloud container vmware clusters create einen Fehler erhalten, prüfen Sie mit dem folgenden Befehl, ob der Cluster teilweise erstellt wurde:

gcloud container vmware clusters list \
    --project=FLEET_HOST_PROJECT_ID \
    --location=-

Wenn der Cluster nicht in der Ausgabe aufgeführt ist, beheben Sie den Fehler und führen gcloud container vmware clusters create noch einmal aus.

Wenn der Cluster in der Ausgabe aufgeführt ist, löschen Sie ihn mit dem folgenden Befehl:

gcloud container vmware clusters delete USER_CLUSTER_NAME \
    --project=FLEET_HOST_PROJECT_ID \
    --location=REGION \
    --force \
    --allow-missing

Beheben Sie dann den Fehler und führen Sie gcloud container vmware clusters create noch einmal aus.

Nachdem der Cluster ausgeführt wird, müssen Sie einen Knotenpool hinzufügen, bevor Sie Arbeitslasten bereitstellen können, 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 Cluster-Worker-Knoten zu erhalten.

Sie können MetalLB nur dann für den Nutzercluster verwenden, wenn Ihr Administratorcluster MetalLB verwendet. Diese Load Balancing-Option erfordert nur 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 einen Vergleich mit den anderen Load-Balancing-Optionen finden Sie unter Gebündeltes Load-Balancing mit MetalLB.

Mit dem Beispielbefehl wird ein Nutzercluster mit den folgenden Eigenschaften erstellt, die Sie nach Bedarf für Ihre Umgebung ändern können.

Flag	Beschreibung
--admin-users	Sie und ein anderer Nutzer erhalten vollständige Administratorrechte für den Cluster.
--enable-control-plane-v2	Aktiviert Controlplane V2, was ab Version 1.30 empfohlen und erforderlich ist.
--control-plane-ip-block	Eine IP-Adresse für den Knoten der Steuerungsebene. Wenn Sie einen hochverfügbaren Nutzercluster (HA, High Availability) erstellen möchten, geben Sie drei IP-Adressen an und fügen das Flag --replicas=3 hinzu.
--metal-lb-config-address-pools	Zwei Adresspools für den MetalLB-Load-Balancer. Sie benötigen mindestens einen Adresspool. Bei Bedarf können Sie weitere angeben. Der Einfachheit halber enthält das Beispiel einen Adresspool mit dem Namen „ingress-vip-pool“, um daran zu erinnern, dass die IP-Adresse für die virtuelle IP-Adresse für eingehenden Traffic in einem der Adresspools enthalten sein muss. Sie geben den CIDR für eine einzelne IP-Adresse an, indem Sie /32 an die IP-Adresse anhängen.

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=10.96.0.0/20 \
    --pod-address-cidr-blocks=192.168.0.0/16 \
    --metal-lb-config-address-pools='pool=NAME,avoid-buggy-ips=AVOID_BUGGY_IPS,manual-assign=MANUAL_ASSIGN,addresses=IP_ADDRESS_RANGE_1' \
    --metal-lb-config-address-pools='pool=ingress-vip-pool,avoid-buggy-ips=False,manual-assign=True,addresses=INGRESS_VIP/32' \
    --enable-control-plane-v2 \
    --dns-servers=DNS_SERVER_1 \
    --ntp-servers=NTP_SERVER_1 \
    --control-plane-ip-block 'gateway=CP_GATEWAY,netmask=CP_NETMASK,ips=CP_IP_ADDRESS_1 CP_HOST_1' \
    --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:
  • 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 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. 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 --admin-cluster-membership-Flag können Sie den vollständig spezifizierten Clusternamen verwenden, der das folgende 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 --admin-cluster-membership-project und den Standort mit --admin-cluster-membership-location fest. Der Standort des Administratorclusters ist entweder global oder eine Google Cloud Region. Wenn Sie die Region suchen möchten, 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. Mit dieser Einstellung wird die Region angegeben, in der Folgendes gespeichert ist:
  • Die Metadaten des Nutzerclusters, die die GKE On-Prem API zum Verwalten des Clusterlebenszyklus benötigt
  • Cloud Logging- und Cloud Monitoring-Daten von Systemkomponenten
  • Die von Cloud-Audit-Logs erstellten Administrator-Audit-Logs

  Anhand des Clusternamens, des Projekts und des Standorts kann der Cluster in Google Cloudeindeutig identifiziert werden.

  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 Dienste „Flotte“ und „Connect“ in einer Region ausgeführt werden.
• VERSION: Google Distributed Cloud-Version für Ihren Nutzercluster.
• YOUR_EMAIL_ADDRESS und ANOTHER_EMAIL_ADDRESS: Wenn Sie als Clusterersteller nicht das Flag --admin-users angeben, werden Ihnen standardmäßig Administratorberechtigungen für den Cluster gewährt. Wenn Sie --admin-users einfügen, um einen anderen Nutzer als Administrator festzulegen, überschreiben Sie die Standardeinstellung und müssen sowohl Ihre E-Mail-Adresse als auch die E-Mail-Adresse des anderen Administrators hinzufügen. So fügen Sie beispielsweise zwei Administratoren hinzu:

      --admin-users=[e-mail] \
      --admin-users=[e-mail]

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

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

• SERVICE_CIDR_BLOCK: Ein Bereich von IP-Adressen im CIDR-Format, der für Dienste in Ihrem Cluster verwendet werden soll. 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 ein, um die Konfiguration für Adresspools anzugeben, die vom MetalLB Load Balancer verwendet werden sollen. Der Wert für das Flag hat das folgende Format:
  --metal-lb-config-address-pool 'pool=NAME,avoid-buggy-ips=True|False,manual-assign=True|False,addresses=IP_ADDRESS_RANGE_1;IP_ADDRESS_RANGE_2;...' \

  Der Wert umfasst Segmente, die mit den Keywords pool, avoid-buggy-ip, manual-assign und addresses beginnen. Trennen Sie die einzelnen Segmente durch ein Komma.

  • pool: Ein Name Ihrer Wahl für den Pool.
  • avoid-buggy-ips1: Wenn Sie diesen Wert auf True setzen, weist der MetalLB-Controller den Diensten keine IP-Adressen zu, die mit .0 oder .255 enden. Dadurch wird verhindert, dass fehlerhafte Geräte versehentlich Traffic löschen, der an diese speziellen IP-Adressen gesendet wird. Enthält standardmäßig den Wert False, wenn nichts anderes angegeben ist.
  • manual-assign: Wenn der MetalLB-Controller IP-Adressen aus diesem Pool nicht automatisch Diensten zuweisen soll, legen Sie für dieses Feld True fest. Anschließend können Entwickler einen Service vom Typ LoadBalancer erstellen und eine der Adressen manuell aus dem Pool angeben. Wenn nicht angegeben, wird manual-assign festgelegt auf False.
  • In der Liste der addresses: Jede Adresse muss ein Bereich sein, entweder im Format CIDR oder Bereich mit Bindestrich. Um eine einzelne IP-Adresse in einem Pool (z. B. für die virtuelle IP-Adresse für eingehenden Traffic) anzugeben, verwenden Sie /32 in CIDR-Notation, zum 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.

  Beispiele:

  --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 für den Load-Balancer für den Ingress-Proxy konfiguriert haben.

  Beispiel: --ingress-vip=10.251.134.80

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

• --enable-dhcp: Fügen Sie --enable-dhcp hinzu, wenn Sie möchten, dass Ihre Clusterknoten ihre IP-Adresse von einem von Ihnen bereitgestellten DHCP-Server abrufen. Lassen Sie dieses Flag weg, wenn Sie statische IP-Adressen für Ihre Clusterknoten bereitstellen oder das manuelle 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 Ihren Cluster-Worker-Knoten statische IP-Adressen zuweisen.

Sie können MetalLB nur dann für den Nutzercluster verwenden, wenn Ihr Administratorcluster MetalLB verwendet. Diese Load Balancing-Option erfordert nur 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 einen Vergleich mit den anderen Load-Balancing-Optionen finden Sie unter Gebündeltes Load-Balancing mit MetalLB.

Mit dem Beispielbefehl wird ein Nutzercluster mit den folgenden Eigenschaften erstellt, die Sie nach Bedarf für Ihre Umgebung ändern können.

Flag	Beschreibung
--admin-users	Sie und ein anderer Nutzer erhalten vollständige Administratorrechte für den Cluster.
--enable-control-plane-v2	Aktiviert Controlplane V2, was ab Version 1.30 empfohlen und erforderlich ist.
--control-plane-ip-block	Eine IP-Adresse für den Knoten der Steuerungsebene. Wenn Sie einen hochverfügbaren Nutzercluster (HA, High Availability) erstellen möchten, geben Sie drei IP-Adressen an und fügen das Flag --replicas=3 hinzu.
--metal-lb-config-address-pools	Zwei Adresspools für den MetalLB-Load-Balancer. Sie benötigen mindestens einen Adresspool. Bei Bedarf können Sie weitere angeben. Der Einfachheit halber enthält das Beispiel einen Adresspool mit dem Namen „ingress-vip-pool“, um daran zu erinnern, dass die IP-Adresse für die virtuelle IP-Adresse für eingehenden Traffic in einem der Adresspools enthalten sein muss. Sie geben den CIDR für eine einzelne IP-Adresse an, indem Sie /32 an die IP-Adresse anhängen.
--static-ip-config-ip-blocks	Vier IP-Adressen für die Worker-Knoten in den Clustern. Dazu gehört auch eine Adresse für einen zusätzlichen Knoten, der während Upgrades und Updates verwendet werden kann. Bei Bedarf können Sie weitere IP-Adressen angeben. Der Hostname ist optional.

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=10.96.0.0/20 \
    --pod-address-cidr-blocks=192.168.0.0/16 \
    --metal-lb-config-address-pools='pool=NAME,avoid-buggy-ips=AVOID_BUGGY_IPS,manual-assign=MANUAL_ASSIGN,addresses=IP_ADDRESS_RANGE_1' \
    --metal-lb-config-address-pools='pool=ingress-vip-pool,avoid-buggy-ips=False,manual-assign=True,addresses=INGRESS_VIP/32' \
    --enable-control-plane-v2 \
    --control-plane-ip-block 'gateway=CP_GATEWAY,netmask=CP_NETMASK,ips=CP_IP_ADDRESS_1 CP_HOST_1' \
    --control-plane-vip=CONTROL_PLANE_VIP \
    --ingress-vip=INGRESS_VIP \
    --static-ip-config-ip-blocks='gateway=GATEWAY,netmask=NETMASK,ips=IP_ADDRESS_1 HOST_1;IP_ADDRESS_2 HOST_2;IP_ADDRESS_3 HOST_3;IP_ADDRESS_4 HOST_4' \
    --dns-servers=DNS_SERVER_1 \
    --ntp-servers=NTP_SERVER_1

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:
  • 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 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. 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 --admin-cluster-membership-Flag können Sie den vollständig spezifizierten Clusternamen verwenden, der das folgende 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 --admin-cluster-membership-project und den Standort mit --admin-cluster-membership-location fest. Der Standort des Administratorclusters ist entweder global oder eine Google Cloud Region. Wenn Sie die Region suchen möchten, 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. Mit dieser Einstellung wird die Region angegeben, in der Folgendes gespeichert ist:
  • Die Metadaten des Nutzerclusters, die die GKE On-Prem API zum Verwalten des Clusterlebenszyklus benötigt
  • Cloud Logging- und Cloud Monitoring-Daten von Systemkomponenten
  • Die von Cloud-Audit-Logs erstellten Administrator-Audit-Logs

  Anhand des Clusternamens, des Projekts und des Standorts kann der Cluster in Google Cloudeindeutig identifiziert werden.

  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 Dienste „Flotte“ und „Connect“ in einer Region ausgeführt werden.
• VERSION: Google Distributed Cloud-Version für Ihren Nutzercluster.
• YOUR_EMAIL_ADDRESS und ANOTHER_EMAIL_ADDRESS: Wenn Sie als Clusterersteller nicht das Flag --admin-users angeben, werden Ihnen standardmäßig Administratorberechtigungen für den Cluster gewährt. Wenn Sie --admin-users einfügen, um einen anderen Nutzer als Administrator festzulegen, überschreiben Sie die Standardeinstellung und müssen sowohl Ihre E-Mail-Adresse als auch die E-Mail-Adresse des anderen Administrators hinzufügen. So fügen Sie beispielsweise zwei Administratoren hinzu:

      --admin-users=[e-mail] \
      --admin-users=[e-mail]

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

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

• SERVICE_CIDR_BLOCK: Ein Bereich von IP-Adressen im CIDR-Format, der für Dienste in Ihrem Cluster verwendet werden soll. 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 ein, um die Konfiguration für Adresspools anzugeben, die vom MetalLB Load Balancer verwendet werden sollen. Der Wert für das Flag hat das folgende Format:
  --metal-lb-config-address-pool 'pool=NAME,avoid-buggy-ips=True|False,manual-assign=True|False,addresses=IP_ADDRESS_RANGE_1;IP_ADDRESS_RANGE_2;...' \

  Der Wert umfasst Segmente, die mit den Keywords pool, avoid-buggy-ip, manual-assign und addresses beginnen. Trennen Sie die einzelnen Segmente durch ein Komma.

  • pool: Ein Name Ihrer Wahl für den Pool.
  • avoid-buggy-ips1: Wenn Sie diesen Wert auf True setzen, weist der MetalLB-Controller den Diensten keine IP-Adressen zu, die mit .0 oder .255 enden. Dadurch wird verhindert, dass fehlerhafte Geräte versehentlich Traffic löschen, der an diese speziellen IP-Adressen gesendet wird. Enthält standardmäßig den Wert False, wenn nichts anderes angegeben ist.
  • manual-assign: Wenn der MetalLB-Controller IP-Adressen aus diesem Pool nicht automatisch Diensten zuweisen soll, legen Sie für dieses Feld True fest. Anschließend können Entwickler einen Service vom Typ LoadBalancer erstellen und eine der Adressen manuell aus dem Pool angeben. Wenn nicht angegeben, wird manual-assign festgelegt auf False.
  • In der Liste der addresses: Jede Adresse muss ein Bereich sein, entweder im Format CIDR oder Bereich mit Bindestrich. Um eine einzelne IP-Adresse in einem Pool (z. B. für die virtuelle IP-Adresse für eingehenden Traffic) anzugeben, verwenden Sie /32 in CIDR-Notation, zum 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.

  Beispiele:

  --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 für den Load-Balancer für den Ingress-Proxy konfiguriert haben.

  Beispiel: --ingress-vip=10.251.134.80

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

• --static-ip-config-ip-blocks: Geben Sie das Standardgateway, die Subnetzmaske und eine Liste der statischen IP-Adressen für die Worker-Knoten im Nutzercluster an. Der Wert für das Flag hat das folgende Format:
  --static-ip-config-ip-blocks 'gateway=GATEWAY,netmask=NETMASK,ips=IP_ADDRESS_1;IP_ADDRESS_2 HOST_2;...'

  Der Wert umfasst Segmente, die mit den Keywords gateway, netmask und ips beginnen. Trennen Sie die Segmente durch ein Komma.

  Wichtige Hinweise:

  • Setzen Sie den gesamten Wert in einfache Anführungszeichen.
  • Leerzeichen sind nur zwischen einer IP-Adresse und einem Hostnamen erlaubt.

  In der Liste der IP-Adressen:

  • Sie können eine einzelne IP-Adresse oder einen CIDR-Block mit IP-Adressen angeben.
  • Trennen Sie die einzelnen IP-Adressen oder CIDR-Blöcke durch ein Semikolon.
  • Für eine einzelne IP-Adresse können Sie optional einen Hostnamen nach der IP-Adresse angeben. Trennen Sie die IP-Adresse und den Hostnamen durch ein Leerzeichen. Wenn Sie keinen Hostnamen angeben, verwendet Google Distributed Cloud den Namen der VM aus vSphere als Hostname.
  • Wenn Sie einen CIDR-Block angeben, geben Sie keinen Wert für „hostname“ an.

  Beispiele:

  --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 des DNS-Servers für die VMs.
• DNS_SEARCH_DOMAIN: eine durch Kommas getrennte Liste der DNS-Such-Domains, die von den Hosts verwendet werden können. Diese Domains werden als Teil einer Domainsuchliste verwendet.

  Beispiele:

  --dns-search-domains example.com,examplepetstore.com

• NTP_SERVER: Eine kommagetrennte Liste der IP-Adressen der Zeitserver, die die VMs verwenden sollen.

Manueller Load Balancer und statische IP-Adressen

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

Sie können nur dann einen manuellen Load-Balancer für den Nutzercluster verwenden, wenn Ihr Administratorcluster einen manuellen Load-Balancer verwendet. In Google Distributed Cloud werden der Kubernetes API-Server, der Ingress-Proxy und der Add‑on-Dienst für die Logaggregation von Kubernetes-Diensten vom Typ LoadBalancer bereitgestellt. Wählen Sie für diese Services Ihre eigenen nodePort-Werte im Bereich von 30.000 bis 32.767 aus. Für den Ingress-Proxy muss ein nodePort-Wert sowohl für HTTP- als auch HTTPS-Traffic ausgewählt werden. Weitere Informationen finden Sie unter Manuellen Load-Balancing-Modus aktivieren.

Mit dem Beispielbefehl wird ein Nutzercluster mit den folgenden Eigenschaften erstellt, die Sie nach Bedarf für Ihre Umgebung ändern können.

Flag	Beschreibung
--admin-users	Sie und ein anderer Nutzer erhalten vollständige Administratorrechte für den Cluster.
--enable-control-plane-v2	Aktiviert Controlplane V2, was ab Version 1.30 empfohlen und erforderlich ist.
--control-plane-ip-block	Eine IP-Adresse für den Knoten der Steuerungsebene. Wenn Sie einen hochverfügbaren Nutzercluster (HA, High Availability) erstellen möchten, geben Sie drei IP-Adressen an und fügen das Flag --replicas=3 hinzu.
--static-ip-config-ip-blocks	Vier IP-Adressen für die Worker-Knoten in den Clustern. Dazu gehört auch eine Adresse für einen zusätzlichen Knoten, der während Upgrades und Updates verwendet werden kann. Bei Bedarf können Sie weitere IP-Adressen angeben. Der Hostname ist optional.

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=10.96.0.0/20 \
    --pod-address-cidr-blocks=192.168.0.0/16 \
    --enable-control-plane-v2 \
    --control-plane-ip-block 'gateway=CP_GATEWAY,netmask=CP_NETMASK,ips=CP_IP_ADDRESS_1 CP_HOST_1' \
    --control-plane-vip=CONTROL_PLANE_VIP \
    --ingress-vip=INGRESS_VIP \
    --ingress-http-node-port=INGRESS_HTTP_NODE_PORT \
    --ingress-https-node-port=INGRESS_HTTPS_NODE_PORT \
    --static-ip-config-ip-blocks='gateway=GATEWAY,netmask=NETMASK,ips=IP_ADDRESS_1 HOST_1;IP_ADDRESS_2 HOST_2;IP_ADDRESS_3 HOST_3;IP_ADDRESS_4 HOST_4' \
    --dns-servers=DNS_SERVER_1 \
    --ntp-servers=NTP_SERVER_1

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:
  • 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 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. 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 --admin-cluster-membership-Flag können Sie den vollständig spezifizierten Clusternamen verwenden, der das folgende 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 --admin-cluster-membership-project und den Standort mit --admin-cluster-membership-location fest. Der Standort des Administratorclusters ist entweder global oder eine Google Cloud Region. Wenn Sie die Region suchen möchten, 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. Mit dieser Einstellung wird die Region angegeben, in der Folgendes gespeichert ist:
  • Die Metadaten des Nutzerclusters, die die GKE On-Prem API zum Verwalten des Clusterlebenszyklus benötigt
  • Cloud Logging- und Cloud Monitoring-Daten von Systemkomponenten
  • Die von Cloud-Audit-Logs erstellten Administrator-Audit-Logs

  Anhand des Clusternamens, des Projekts und des Standorts kann der Cluster in Google Cloudeindeutig identifiziert werden.

  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 Dienste „Flotte“ und „Connect“ in einer Region ausgeführt werden.
• VERSION: Google Distributed Cloud-Version für Ihren Nutzercluster.
• YOUR_EMAIL_ADDRESS und ANOTHER_EMAIL_ADDRESS: Wenn Sie als Clusterersteller nicht das Flag --admin-users angeben, werden Ihnen standardmäßig Administratorberechtigungen für den Cluster gewährt. Wenn Sie --admin-users einfügen, um einen anderen Nutzer als Administrator festzulegen, überschreiben Sie die Standardeinstellung und müssen sowohl Ihre E-Mail-Adresse als auch die E-Mail-Adresse des anderen Administrators hinzufügen. So fügen Sie beispielsweise zwei Administratoren hinzu:

      --admin-users=[e-mail] \
      --admin-users=[e-mail]

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

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

• SERVICE_CIDR_BLOCK: Ein Bereich von IP-Adressen im CIDR-Format, der für Dienste in Ihrem Cluster verwendet werden soll. 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

• INGRESS_VIP: Die IP-Adresse, die Sie auf dem Load-Balancer für den Ingress-Proxy konfiguriert haben.

  Beispiel: --ingress-vip=203.0.113.4

• INGRESS_HTTP_NODE_PORT: Ein nodePort-Wert für HTTP-Traffic zum Ingress-Proxy (z. B. 30243).

• INGRESS_HTTPS_NODE_PORT: Ein nodePort-Wert für HTTPS-Traffic zum Ingress-Proxy (z. B. 30879).

• --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 das folgende Format:
  --static-ip-config-ip-blocks 'gateway=GATEWAY,netmask=NETMASK,ips=IP_ADDRESS_1;IP_ADDRESS_2 HOST_2;...'

  Der Wert umfasst Segmente, die mit den Keywords gateway, netmask und ips beginnen. Trennen Sie die Segmente durch ein Komma.

  Wichtige Hinweise:

  • Setzen Sie den gesamten Wert in einfache Anführungszeichen.
  • Leerzeichen sind nur zwischen einer IP-Adresse und einem Hostnamen erlaubt.

  In der Liste der IP-Adressen:

  • Sie können eine einzelne IP-Adresse oder einen CIDR-Block mit IP-Adressen angeben.
  • Trennen Sie die einzelnen IP-Adressen oder CIDR-Blöcke durch ein Semikolon.
  • Für eine einzelne IP-Adresse können Sie optional einen Hostnamen nach der IP-Adresse angeben. Trennen Sie die IP-Adresse und den Hostnamen durch ein Leerzeichen. Wenn Sie keinen Hostnamen angeben, verwendet Google Distributed Cloud den Namen der VM aus vSphere als Hostname.
  • Wenn Sie einen CIDR-Block angeben, geben Sie keinen Wert für „hostname“ an.

  Beispiele:

  --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 des DNS-Servers für die VMs.
• DNS_SEARCH_DOMAIN: eine durch Kommas getrennte Liste der DNS-Such-Domains, die von den Hosts verwendet werden können. Diese Domains werden als Teil einer Domainsuchliste verwendet.

  Beispiele:

  --dns-search-domains example.com,examplepetstore.com

• NTP_SERVER: Eine kommagetrennte Liste der IP-Adressen der Zeitserver, die die VMs verwenden sollen.

Flags der Steuerungsebene

Wenn Sie nicht die Standardwerte für die Konfiguration der Steuerungsebene verwenden möchten, fügen Sie ein oder mehrere der folgenden Flags ein:

• --cpus=vCPUS: Die Anzahl der vCPUs (mindestens 4) für jeden Knoten der Steuerungsebene für Ihren Nutzercluster. Wenn nicht angegeben, ist der Standardwert 4 vCPUs.

• --memory=MEMORY: Die Arbeitsspeichergröße in Mebibyte (MiB) für jede Steuerungsebene für Ihren Nutzercluster. Der Mindestwert ist 8192 und er muss ein Vielfaches von 4 sein. Wenn keine Angabe erfolgt, lautet der Standardwert 8192.

• --replicas=NODES: Die Anzahl der Knoten der Steuerungsebene für Ihren Nutzercluster. Sie können beispielsweise einen Knoten für die Steuerungsebene für eine Entwicklungsumgebung und drei Knoten für die Steuerungsebene für Hochverfügbarkeit- und Produktionsumgebungen 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 hinzu. Bei der Größenanpassung werden die einem Knoten zugewiesenen vCPU- und Arbeitsspeicherressourcen automatisch angepasst. Wenn diese Option aktiviert ist, wird die Größe der Knoten auf der Steuerungsebene des Nutzerclusters entsprechend der Anzahl der Worker-Knoten im Nutzercluster angepasst. Wenn Sie also dem Nutzercluster weitere Worker-Knoten hinzufügen, wird die Größe der Knoten auf der Steuerungsebene erhöht.

• --enable-control-plane-v2: Wenn Sie Controlplane V2 aktivieren möchten, was wir empfehlen, fügen Sie dieses Flag hinzu. Wenn die Steuerungsebene V2 aktiviert ist, wird die Steuerungsebene für einen Nutzercluster auf einem oder mehreren Knoten im Nutzercluster selbst ausgeführt. Ab Version 1.30 ist Controlplane V2 erforderlich.

  Wenn Sie Controlplane V2 aktivieren, müssen Sie auch die folgenden Flags angeben:

  • --dns-servers=DNS_SERVER_1,...: eine kommagetrennte Liste der IP-Adressen des DNS-Servers für die VMs.

  • --ntp-servers=NTP_SERVER_1,...: Eine durch Kommas getrennte Liste der IP-Adressen der Zeitserver, die die VMs verwenden sollen.

  • --control-plane-ip-block mit dem folgenden Format:

      --control-plane-ip-block 'gateway=CP_GATEWAY,netmask=CP_NETMASK,ips=CP_IP_ADDRESS_1;CP_IP_ADDRESS_2 CP_HOST_2'

    Der Wert umfasst Segmente, die mit den Keywords gateway, netmask und ips beginnen. Trennen Sie die Segmente durch ein Komma.

    Wichtige Hinweise:

    • Setzen Sie den gesamten Wert in einfache Anführungszeichen.

    • Leerzeichen sind nur zwischen einer IP-Adresse und einem Hostnamen erlaubt.

      In der Liste der IP-Adressen:

    • Sie können eine einzelne IP-Adresse oder einen CIDR-Block mit IP-Adressen angeben.

    • Trennen Sie die einzelnen IP-Adressen oder CIDR-Blöcke durch ein Semikolon.

    • Für eine einzelne IP-Adresse können Sie optional einen Hostnamen nach der IP-Adresse angeben. Trennen Sie die IP-Adresse und den Hostnamen durch ein Leerzeichen.

    • Wenn Sie einen CIDR-Block angeben, geben Sie keinen Wert für „hostname“ an.

      Beispiele:

      --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-Such-Domains, die von den Hosts verwendet werden können. Diese Domains werden als Teil einer Domainsuchliste verwendet.

    Beispiele:

    --dns-search-domains example.com,examplepetstore.com

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

  vSphere-Flags

  Geben Sie bei Bedarf die folgenden optionalen Flags an:

• --disable-aag-config: Wenn Sie dieses Flag nicht angeben, werden die Anti-Affinitätsregeln des VMware Distributed Resource Scheduler (DRS) automatisch für die Knoten Ihres Nutzerclusters erstellt, wodurch diese auf mindestens 3 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 ein.

  Hinweis: Wenn Sie der Einrichtung der minimalen Infrastruktur gefolgt sind, haben Sie nur einen ESXi-Host. Achten Sie daher darauf, dieses Flag anzugeben.

• --disable-vsphere-csi: Wenn Sie dieses Flag nicht angeben, werden die Komponenten der vSphere Container Storage Interface (CSI) im Nutzercluster bereitgestellt. Der CSI-Treiber läuft in einem nativen Kubernetes-Cluster, der in vSphere bereitgestellt wird, um nichtflüchtige Volumes auf vSphere-Storage 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 ein.

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

  Fortschritt der Clustererstellung verfolgen

  Die Ausgabe des Befehls zum Erstellen eines Clusters sieht in etwa so aus:

  Waiting for operation [projects/example-project-12345/locations/us-west1/operations/operation-1679543737105-5f7893fd5bae9-942b3f97-75e59179] to complete.
  

  In der Beispielausgabe ist der String operation-1679543737105-5f7893fd5bae9-942b3f97-75e59179 der OPERATION_ID des Vorgangs mit langer Ausführungszeit. Sie können den Status des Vorgangs mit dem folgenden Befehl ermitteln:

  gcloud container vmware operations describe OPERATION_ID \
    --project=FLEET_HOST_PROJECT_ID \
    --location=REGION
  

  Weitere Informationen finden Sie unter gcloud container vmware operations.

  Das Erstellen des Nutzerclusters dauert mindestens 15 Minuten. Sie können den Cluster in der Google Cloud Console auf der Seite GKE-Cluster aufrufen.

  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, bei dem 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 dafür 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. Die Mindestgröße beträgt 40 GiB.

• vCPUs: Die Anzahl der CPUs für jeden Knoten im Knotenpool. Der Mindestwert beträgt 4.

• MEMORY: die Arbeitsspeichergröße in Mebibyte (MiB) für jeden Knoten im Pool. Der Mindestwert beträgt 8.192 MiB pro Worker-Knoten des Nutzerclusters und muss ein Vielfaches von 4 sein.

• NODES: Die maximale Anzahl von Knoten im Knotenpool. Der Mindestwert beträgt 3.

• Wenn Sie MetalLB als Load Balancer verwenden, fügen Sie optional --enable-load-balancer ein, wenn Sie zulassen möchten, dass der MetalLB- Speaker auf den Knoten des Pools ausgeführt wird. MetalLB muss in mindestens einem Knotenpool aktiviert sein. Wenn Sie dieses Flag nicht angeben, müssen Sie einen weiteren Knotenpool für MetalLB erstellen.

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

Beispiel für gcloud-Befehle

MetalLB und DHCP

gcloud container vmware clusters create user-cluster-1 \
    --project=example-project-12345 \
    --location=us-west1 \
    --admin-cluster-membership=projects/example-project-12345/locations/us-west1/memberships/admin-cluster-1 \
    --version=1.32.300-gke.85 \
    --admin-users=[e-mail] \
    --admin-users=[e-mail] \
    --enable-dhcp \
    --service-address-cidr-blocks=10.96.0.0/20 \
    --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=192.0.2.0/26;pool=lb-ingress-vip-pool,manual-assign=True,addresses=198.51.100.1/32' \
    --enable-control-plane-v2 \
    --control-plane-vip=203.0.113.1 \
    --ingress-vip=198.51.100.1

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.32.300-gke.85 \
    --admin-users=[e-mail] \
    --admin-users=[e-mail] \
    --static-ip-config-ip-blocks='gateway=192.0.2.254,netmask=255.255.255.0,ips=192.0.2.10 user-vm-1;192.0.2.11 user-vm-2' \
    --static-ip-config-ip-blocks='gateway=192.0.2.254,netmask=255.255.255.0,ips=192.0.2.12 user-vm-3;192.0.2.13 extra-vm' \
    --dns-servers=203.0.113.1,203.0.113.2  \
    --dns-search-domains=example.com,altostrat.com \
    --ntp-servers=203.0.113.3,203.0.113.4 \
    --service-address-cidr-blocks=10.96.0.0/20 \
    --pod-address-cidr-blocks=192.168.0.0/16 \
    --enable-control-plane-v2 \
    --control-plane-ip-block 'gateway=192.0.2.254,netmask=255.255.255.0,ips=198.51.100.1 cp-vm-1;198.51.100.2 cp-vm-2;198.51.100.3 cp-vm-3' \
    --replicas=3 \
    --metal-lb-config-address-pools='pool=lb-pool-1,manual-assign=False,avoid-buggy-ips=True,addresses=192.0.2.0/26;lb-ingress-vip-pool,manual-assign=True,addresses=198.51.100.1/32' \
    --control-plane-vip=172.16.20.61 \
    --ingress-vip=172.16.20.62

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/asia-east1/memberships/admin-cluster-1 \
    --version=1.32.300-gke.85 \
    --admin-users=[e-mail] \
    --admin-users=[e-mail] \
    --static-ip-config-ip-blocks='gateway=192.0.2.254,netmask=255.255.255.0,ips=192.0.2.10 user-vm-1;192.0.2.11 user-vm-2';ips=192.0.2.12 user-vm-3;192.0.2.13 extra-vm'\
    --dns-servers=203.0.113.1,203.0.113.2  \
    --ntp-servers=203.0.113.3,203.0.113.4 \
    --service-address-cidr-blocks=10.96.0.0/20 \
    --pod-address-cidr-blocks=192.168.0.0/16 \
    --enable-control-plane-v2 \
    --control-plane-ip-block 'gateway=192.0.2.254,netmask=255.255.255.0,ips=198.51.100.1 cp-vm-1;198.51.100.2 cp-vm-2;198.51.100.3 cp-vm-3' \
    --replicas=3 \
    --control-plane-vip=192.0.2.60 \
    --ingress-vip=192.0.2.50 \
    --ingress-http-node-port=30243 \
    --ingress-https-node-port=30879

Terraform

Hinweise

1. Rufen Sie den Namen und den Standort der Flottenmitgliedschaft Ihres Admin-Clusters ab:

   gcloud container fleet memberships list \
       --project=FLEET_HOST_PROJECT_ID
   

   Ersetzen Sie FLEET_HOST_PROJECT_ID durch die ID des Projekts, in dem 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 Flotten- und Connect-Dienste ausgeführt werden. Vor 1.28 erstellte Administratorcluster werden von der globalen Flotte und Connect-Diensten verwaltet. Ab Version 1.28 können Sie entweder global oder eine Google Cloud -Region angeben, wenn Sie den Cluster erstellen.

2. 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, bei dem der Administratorcluster registriert ist.

   • ADMIN_CLUSTER_REGION: Die Region der Flottenmitgliedschaft für den Administratorcluster. Diese ist entweder global oder eine Google CloudRegion. 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 möchten. Dies ist die Region, in der die GKE On-Prem API und die Flotten- 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
   

   Außerdem wird eine Erklärung zu den Versionen ausgegeben, die Sie zum Erstellen oder Aktualisieren von Nutzerclustern verwenden können. Zulässige Versionen sind mit isInstalled: true annotiert. Das bedeutet, dass der Administratorcluster über die versionsspezifischen Komponenten verfügt, die er zur Verwaltung von Nutzerclustern dieser Version benötigt. Wenn Sie eine im Administratorcluster installierte Version verwenden möchten, fahren Sie mit dem Abschnitt Beispiel fort, um den Nutzercluster zu erstellen.

Andere Version installieren

Ein Administratorcluster kann Nutzercluster mit unterschiedlichen Versionen verwalten. In der Ausgabe des Befehls query-version-config werden andere Versionen aufgeführt, die Sie beim Erstellen des Clusters verwenden können. Wenn Sie einen Nutzercluster erstellen möchten, der eine andere Version als der Administratorcluster hat, müssen Sie die Komponenten, die der Administratorcluster zur Verwaltung von Nutzerclustern dieser Version benötigt, folgendermaßen herunterladen und bereitstellen:

gcloud container vmware admin-clusters update ADMIN_CLUSTER_NAME \
    --project=FLEET_HOST_PROJECT_ID \
    --location=REGION \
    --required-platform-version=VERSION

Ersetzen Sie VERSION durch eine der Versionen, die in der Ausgabe des query-version-config-Befehls aufgeführt sind.

Mit diesem Befehl wird die Version der Komponenten, die Sie in --required-platform-version angeben, auf den Administratorcluster heruntergeladen und anschließend bereitgestellt. Sie können jetzt einen Nutzercluster mit der angegebenen Version erstellen.

Wenn Sie gcloud container vmware clusters query-version-config noch einmal ausführen, wird die von Ihnen angegebene Version mit isInstalled: true gekennzeichnet.

Beispiel

Sie können das folgende Beispiel für eine Basiskonfiguration verwenden, um einen Nutzercluster mit dem gebündelten MetalLB Load Balancer und einem Knotenpool mit dem Google-Anbieter für Terraform zu erstellen.

Wenn Sie einen Nutzercluster erstellen, muss die Terraform-Konfigurationsdatei mindestens eine google_gkeonprem_vmware_node_pool-Ressource enthalten, um einen Knotenpool zu erstellen. Terraform kann die Knotenpoolressource jedoch erst erstellen, wenn alle Vorgänge für die Upstream-Nutzerclusterressource google_gkeonprem_vmware_cluster abgeschlossen sind. Um diese Abhängigkeit zu erzwingen, fügen Sie der google_gkeonprem_vmware_node_pool-Ressource eine depends_on-Anweisung hinzu, wie im folgenden Beispiel der Datei main.tf gezeigt. Weitere Informationen zur Verwendung von depends_on zum Angeben von Ressourcenabhängigkeiten finden Sie in der Terraform-Ressourcendokumentation.

Weitere Informationen zum Beispiel finden Sie unter folgendem Link:

main.tf zum Erstellen eines Nutzerclusters

Das Beispiel main.tf enthält die folgenden Module und Ressourcen:

• enable_google_apis_primary: Aktiviert die erforderlichen Google-APIs im Projekt. Sie müssen die APIs nur einmal in einem Projekt aktivieren. Wenn die APIs in Ihrem Projekt bereits aktiviert wurden, müssen Sie dies nicht in eine Terraform-Konfigurationsdatei aufnehmen.
• google_project_service: Aktiviert die GKE On-Prem API im Projekt. Wie die anderen erforderlichen Google APIs müssen Sie die GKE On-Prem API nur einmal aktivieren.
• gcloud_update_admin_cluster_platform_controller: Aktualisiert den Plattformcontroller in Ihrem Administratorcluster. Dies ist für Nutzerclusterupgrades erforderlich. Wenn der Administratorcluster bereits die richtige Version hat, ändert sich durch dieses Modul nichts. Dieses Modul ist zwar optional, aber die Erstellung des Nutzerclusters schlägt fehl, wenn die Version des Plattformcontrollers im Administratorcluster nicht mit der Version übereinstimmt, die Sie für den Nutzercluster angeben.
• google_gkeonprem_vmware_cluster: erstellt den Nutzercluster. Diese Ressource ist erforderlich. Der Nutzercluster ist in der GKE On-Prem API registriert und in derselben Flotte wie der Administratorcluster. Im Beispiel wird der Cluster mit dem gebündelten MetalLB erstellt. In der google_gkeonprem_vmware_cluster-Referenzdokumentation finden Sie ein Beispiel für die Konfiguration eines manuellen Load-Balancers.
• google_gkeonprem_vmware_node_pool: Erstellt einen Knotenpool. Diese Ressource ist in der Terraform-Konfigurationsdatei erforderlich. Ein neu erstellter Nutzercluster muss mindestens einen Knotenpool haben, um in einen fehlerfreien Zustand überzugehen.

module "enable_google_apis_primary" {
  source     = "terraform-google-modules/project-factory/google//modules/project_services"
  version    = "~> 18.0"
  project_id = var.project_id
  activate_apis = [
    "cloudresourcemanager.googleapis.com",
    "anthos.googleapis.com",
    "anthosgke.googleapis.com",
    "container.googleapis.com",
    "gkeconnect.googleapis.com",
    "gkehub.googleapis.com",
    "serviceusage.googleapis.com",
    "stackdriver.googleapis.com",
    "monitoring.googleapis.com",
    "logging.googleapis.com",
    "iam.googleapis.com",
    "compute.googleapis.com",
    "anthosaudit.googleapis.com",
    "opsconfigmonitoring.googleapis.com",
    "file.googleapis.com",
    "connectgateway.googleapis.com"
  ]
  disable_services_on_destroy = false
}

# Enable GKE OnPrem API
resource "google_project_service" "default" {
  project            = var.project_id
  service            = "gkeonprem.googleapis.com"
  disable_on_destroy = false
}

# This module is used to update the platform controller on your admin cluster. This
# is a necessary step for the user cluster version update. If the admin cluster is
# already on the correct version, then this module does not change anything
module "gcloud_update_admin_cluster_platform_controller" {
  source                = "terraform-google-modules/gcloud/google"
  version               = "~> 3.0"
  platform              = "linux"
  create_cmd_entrypoint = "gcloud"
  create_cmd_body       = <<EOT
    beta container vmware admin-clusters               \
    update ${var.admin_cluster_name}                   \
    --required-platform-version=${var.on_prem_version} \
    --project ${var.project_id}                        \
    --location ${var.region}
  EOT
}

# Create an anthos vmware user cluster and enroll it with the gkeonprem API
resource "google_gkeonprem_vmware_cluster" "default" {
  name        = var.cluster_name
  description = "Anthos VMware user cluster with MetalLB"
  provider    = google-beta
  depends_on = [
    google_project_service.default,
    module.gcloud_update_admin_cluster_platform_controller
  ]
  location                 = var.region
  on_prem_version          = var.on_prem_version
  admin_cluster_membership = "projects/${var.project_id}/locations/global/memberships/${var.admin_cluster_name}"
  network_config {
    service_address_cidr_blocks = ["10.96.0.0/12"]
    pod_address_cidr_blocks     = ["192.168.0.0/16"]
    dhcp_ip_config {
      enabled = true
    }
  }
  control_plane_node {
    cpus     = var.control_plane_node_cpus
    memory   = var.control_plane_node_memory
    replicas = var.control_plane_node_replicas
  }
  load_balancer {
    vip_config {
      control_plane_vip = var.control_plane_vip
      ingress_vip       = var.ingress_vip
    }
    metal_lb_config {
      dynamic "address_pools" {
        for_each = var.lb_address_pools
        content {
          pool      = address_pools.value.name
          addresses = address_pools.value.addresses
        }
      }
    }
  }
  authorization {
    dynamic "admin_users" {
      for_each = var.admin_user_emails
      content {
        username = admin_users.value
      }
    }
  }
}

# Create a node pool for the anthos vmware user cluster
resource "google_gkeonprem_vmware_node_pool" "default" {
  name           = "${var.cluster_name}-nodepool"
  display_name   = "Nodepool for ${var.cluster_name}"
  provider       = google-beta
  vmware_cluster = google_gkeonprem_vmware_cluster.default.name
  location       = var.region
  config {
    replicas             = 3
    image_type           = "ubuntu_containerd"
    enable_load_balancer = true
  }
  depends_on = [
    google_gkeonprem_vmware_cluster.default
  ]
}

Weitere Informationen und Beispiele finden Sie in der Referenzdokumentation zu google_gkeonprem_vmware_cluster

Variablen in terraform.tfvars festlegen

Das Beispiel enthält eine Beispielvariablendatei, die Sie an main.tf weiterleiten können. Sie zeigt, wie Sie den gebündelten MetalLB Load Balancer konfigurieren und Ihren Clusterknoten ermöglichen, ihre IP-Adressen von einem von Ihnen bereitgestellten DHCP-Server zu erhalten.

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

2. Erstellen Sie eine Kopie der Datei terraform.tfvars.sample.

   cp terraform.tfvars.sample terraform.tfvars
   

3. Ä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 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. Das Flotten-Hostprojekt kann nach dem Erstellen des Clusters nicht mehr geändert werden.

   • region: Die Google Cloud Region, in der die GKE On-Prem API (gkeonprem.googleapis.com), der Flottendienst (gkehub.googleapis.com) und der Connect-Dienst (gkeconnect.googleapis.com) ausgeführt werden. Geben Sie us-west1 oder eine andere unterstützte Region an.

   • admin_cluster_name: der Name des Administratorclusters, der den Nutzercluster verwaltet. In diesem Beispiel wird davon ausgegangen, dass der Administratorcluster „global“ als Region nutzt. Wenn Sie einen regionalen Administratorcluster haben:

     1. Öffnen Sie main.tf in einem Texteditor.
     2. Suchen Sie nach admin_cluster_membership, das 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: Google Distributed Cloud-Version für Ihren Nutzercluster.

   • admin_user_emails: eine Liste der E-Mail-Adressen der Nutzer, denen Administratorberechtigungen für den Cluster gewährt werden sollen. Fügen Sie Ihre E-Mail-Adresse hinzu, wenn Sie den Cluster verwalten möchten.

     Wenn der Cluster erstellt wird, wendet die GKE On-Prem API die Kubernetes-RBAC-Richtlinien (Role-Based Access Control, rollenbasierte Zugriffssteuerung) 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 bietet. So können sich Nutzer auch mit ihrer Google-Identität bei der Console anmelden.

   • 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:

     • 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 auf 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 8192 und er 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 für die Steuerungsebene für eine Entwicklungsumgebung und drei Knoten für die Steuerungsebene für Hochverfügbarkeit- und Produktionsumgebungen auswählen.

   • control_plane_vip: die virtuelle IP-Adresse (VIP), die Sie auf dem Load-Balancer für den Kubernetes API-Server des Nutzerclusters konfigurieren möchten.

   • ingress_vip: Die IP-Adresse, die Sie auf dem Load-Balancer für den Ingress-Proxy konfiguriert haben.

   • lb_address_pools: eine Liste von Zuordnungen, die die zu verwendenden Adresspools definieren, die vom MetalLB-Load-Balancer verwendet werden sollen. Die Ingress-VIP muss sich in einem dieser Pools befinden. Geben Sie Folgendes an:

     • name: Ein Name für den Pool.
     • addresses: Ein Adressbereich entweder in CIDR-Notation oder im Format mit Bindestrich. Um eine einzelne IP-Adresse in einem Pool (z. B. für die virtuelle IP-Adresse für eingehenden Traffic) anzugeben, verwenden Sie /32 in CIDR-Notation (Beispiel: 192.0.2.1/32).

     Ersetzen Sie die Beispiel-IP-Adressen durch Ihre Werte und fügen Sie weitere Adresspools hinzu, falls erforderlich.

4. Speichern Sie die Änderungen in terraform.tfvars. Wenn Sie keine optionalen Änderungen an main.tf vornehmen möchten, springen Sie zum folgenden Abschnitt Cluster und einen Knotenpool erstellen.

Steuerungsebene V2 konfigurieren

Ab Version 1.30 müssen Sie Controlplane V2 aktivieren. In der Beispieldatei main.tf wird Controlplane V2 nicht aktiviert. Sie müssen main.tf ändern, um die Steuerungsebene V2 zu aktivieren und die IP-Adressen für das Gateway, die Netzmaske und die Knoten der Steuerungsebene hinzuzufügen. Erstellen Sie vor dem Vornehmen von Änderungen ein Back-up von main.tf:

  cp main.tf main.tf.bak
  

Zum Konfigurieren von Steuerungsebene V2 nehmen Sie folgende Änderungen an main.tf vor:

1. Fügen Sie dem resource-Block die folgende Zeile hinzu:

     enable_control_plane_v2 = "true"
   

2. Fügen Sie dem network_config-Block eine control_plane_v2_config-Zuweisung 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"
         }
       }
     }
   

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

Optional: Erweiterten Cluster aktivieren

In Version 1.32 und höher ist für Nutzercluster, die mit Terraform erstellt wurden, standardmäßig kein erweiterter Cluster aktiviert. Wenn Sie einen erweiterten Cluster aktivieren möchten, fügen Sie main.tf das folgende Feld der obersten Ebene hinzu:

enable_advanced_cluster = true

Lesen Sie sich unbedingt die Unterschiede beim Ausführen erweiterter Cluster durch, bevor Sie einen erweiterten Cluster aktivieren.

Optional: IP-Adressierungsmodus für Worker-Knoten

In diesem Abschnitt werden einige optionale Konfigurationsänderungen erläutert, die Sie in main.tf vornehmen können. Erstellen Sie vor dem Vornehmen von Änderungen ein Back-up von main.tf:

cp main.tf main.tf.bak

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

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

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

2. Ersetzen Sie Folgendes durch Ihre Werte:

   • service_address_cidr_blocks: Ein Bereich von IP-Adressen im CIDR-Format, der für Dienste in Ihrem Cluster verwendet werden soll. 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 für die zu verwendenden VMs.

   • Ersetzen Sie im static_ip_config-Block die Werte für netmask und gateway durch die Adressen Ihres Netzwerks. Ersetzen Sieip undhostname durch die IP-Adressen und Hostnamen Ihrer Worker-Knoten.

Cluster und einen Knotenpool erstellen

1. Initialisieren und erstellen Sie den Terraform-Plan:

   terraform init
   

   Terraform installiert alle erforderlichen Bibliotheken, z. B. den Google Cloud -Anbieter.

2. Überprüfen Sie die Konfiguration und nehmen Sie bei Bedarf Änderungen vor:

   terraform plan
   

3. Wenden Sie den Terraform-Plan an, um den Nutzercluster zu erstellen:

   terraform apply
   

   Das Erstellen des Nutzerclusters dauert etwa 15 Minuten und das Erstellen des Knotenpools weitere 15 Minuten. Sie können den Cluster in der Google Cloud Console auf der Seite GKE-Cluster aufrufen.

Optional: Befehlszeilentools vor dem Erstellen von Ressourcen ausführen

Bei Bedarf können Sie Befehlszeilentools wie die gcloud CLI und gkectl ausführen, um vor dem Erstellen von Ressourcen Einrichtungs- oder Konfigurationsaufgaben auszuführen. Sie definieren die auszuführenden Befehlszeilen in der Terraform-Konfigurationsdatei mit dem Provisioner local-exec, mit dem Sie die definierten Terraform-Variablen wiederverwenden können.

Das folgende Beispiel zeigt, wie main.tf so geändert wird, dass der Befehl gkectl prepare vor dem Erstellen des Clusters ausgeführt wird:

resource "null_resource" "gkectl_prepare" {
  provisioner "local-exec" {
    command = "gkectl prepare --kubeconfig=${var.kubeconfig} --cluster-name=${var.cluster_name} --vcenter-username=${var.vcenter_username} --vcenter-password=${var.vcenter_password} --vcenter-address=${var.vcenter_address} --datacenter=${var.datacenter} --datastore=${var.datastore} --network=${var.network} --os-image=${var.os_image} --service-account-key-file=${var.service_account_key_file} --location=${var.location}"
    working_dir = path.module  # Important: Set working directory
    environment = {
        # Optional: set environment variables if needed.
        # Example: GOOGLE_APPLICATION_CREDENTIALS = "/path/to/your/credentials.json"
    }
  }
}

resource "google_gkeonprem_vmware_cluster" "cluster" {
  # ... your cluster configuration ...
  # Ensure this depends on the null_resource
  depends_on = [null_resource.gkectl_prepare]

  # ... rest of your cluster configuration ...
  location = var.location
  name = var.cluster_name
  # ... other required fields ...
}

Fehlerbehebung

Siehe Fehlerbehebung beim Erstellen und Upgraden von Clustern.

Nächste Schritte

• Verbindung zu Ihrem Cluster über die Google Cloud Console herstellen.
• Anwendung bereitstellen