Nutzercluster erstellen

In Google Distributed Cloud werden Ihre Arbeitslasten auf einem oder mehreren Nutzerclustern ausgeführt. In diesem Dokument wird gezeigt, wie Sie einen Nutzercluster erstellen.

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

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

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

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

Hinweise

• Richten Sie Ihre Google Cloud-Ressourcen wie in diesen Dokumenten beschrieben ein, falls Sie dies noch nicht getan haben:

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

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

  Wenn Sie einen der GKE On-Prem API-Clients verwenden, müssen Sie Audit-Logging und Cloud Logging für den Administratorcluster aktivieren.

• Bestimmen Sie die Version des Nutzerclusters, den Sie installieren möchten. Wenn Sie einen Nutzercluster erstellen, installieren Sie normalerweise die Version, die der Version des Administratorclusters entspricht. Sie können jedoch eine spätere Patchversion oder eine neuere Nebenversion installieren. Weitere Informationen finden Sie unter Spätere Version als die Version des Administratorclusters installieren.

• Überlegen Sie, ob Ihr Nutzercluster die Steuerungsebene V2 aktivieren soll. Wenn Steuerungsebene V2 aktiviert ist, wird die Steuerungsebene für den Nutzercluster auf einem oder mehreren Knoten im Nutzercluster selbst ausgeführt. Wir empfehlen dringend, Steuerungsebene V2 zu aktivieren. Alternativ können Sie einen Nutzercluster erstellen, der kubeception verwendet. Im kubeception-Fall 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 sich auch, ob Sie separate Instanzen von vCenter Server verwenden möchten.

• In Version 1.29 und später 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 die Google Cloud Console, die Google Cloud CLI oder Terraform verwenden, um einen Nutzercluster zu erstellen.

Nutzercluster erstellen

gkectl

Verfahrensübersicht

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

1. Verbindung zu Ihrer Administrator-Workstation herstellen

   Die Administrator-Workstation ist eine Maschine mit den erforderlichen Tools zum Erstellen eines Nutzerclusters.

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

3. (Optional) Importieren Sie Betriebssystem-Images in vSphere und übertragen Sie Container-Images gegebenenfalls in die private Registry.

   Führen Sie gkectl prepare aus.

4. Nutzercluster erstellen

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

5. 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". Um diese Fehler zu vermeiden, fügen Sie den --skip-validation-gcp-Parameter an Ihre Befehle an.

Ihre Konfigurationsdateien ausfüllen

Führen Sie diese Schritte auf Ihrer Administratorworkstation aus.

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

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

name

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

gkeOnPremVersion

Dieses Feld ist bereits für Sie ausgefüllt. Gibt die Version von Google Distributed Cloud an. Beispiel: 1.29.200-gke.245.

enableControlplaneV2

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

Wenn Steuerungsebene V2 aktiviert ist, wird die Steuerungsebene für den Nutzercluster auf Knoten im Nutzercluster selbst ausgeführt. Wir empfehlen dringend, Steuerungsebene 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 heißt, der Administratorcluster und ein zugehöriger Nutzercluster verwenden unterschiedliche Instanzen von vCenter Server.

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

vCenter:
  address: "vc-edge.example"
  datacenter: "vc-edge"
  cluster: "vc-edge-workloads"
  resourcePool: "vc-edge-pool
  datastore: "vc-edge-datastore
  caCertPath: "/usr/local/google/home/me/certs/edge-cacert.pem"
  credentials:
    fileRef:
      path: "credential.yaml"
      entry: "vCenter-edge"
  folder: "edge-vm-folder"

Füllen Sie auch das Feld network.vCenter.networkName aus.

network

Legen Sie fest, wie die 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 Nutzercluster mit Hochverfügbarkeit (High Availability, HA) möchten, geben Sie drei IP-Adressen an. Geben Sie andernfalls eine IP-Adresse an.

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

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: einen oder drei. 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.

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.

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 Bereich 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 der in cloudAuditLogging.clusterLocation und gkeConnect.location entsprechen (wenn das Feld in Ihrer Konfigurationsdatei enthalten ist). Wenn gkeOnPremAPI.enabled den Wert true hat, muss dieselbe Region außerdem in gkeOnPremAPI.location festgelegt werden.

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

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 auf 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 1.16 und höher die GKE On-Prem API in Ihrem Google Cloud-Projekt aktiviert ist, werden alle Cluster im Projekt automatisch in der 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. Anweisungen dafür finden Sie unter Dienste deaktivieren.

usageMetering

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

cloudAuditLogging

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

Beachten Sie die folgenden Anforderungen für neue Cluster:

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

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

Dies sind die wichtigsten Punkte im vorherigen Beispiel:

• Die statischen IP-Adressen für die Worker-Knoten werden in einer IP-Blockdatei angegeben. Die IP-Blockdatei hat vier Adressen, obwohl es nur drei Worker-Knoten gibt. Die zusätzliche IP-Adresse wird während des Clusterupgrades, 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 bestimmt. 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. In diesem Block wird keine zusätzliche IP-Adresse benötigt.

• Steuerungsebene V2 ist aktiviert.

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

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

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

• Die Nutzercluster-Konfigurationsdatei enthält keinen Abschnitt vCenter. 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.

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

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

• Ihr Nutzercluster befindet sich in einem anderen vSphere-Rechenzentrum als Ihr Administratorcluster.

• Ihr Nutzercluster hat einen anderen vCenter-Server als Ihr Administratorcluster.

• Ihr Nutzercluster verwendet eine private Container Registry, die sich von der privaten Registry unterscheidet, die von Ihrem Administratorcluster verwendet wird.

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

Ersetzen Sie Folgendes:

• ADMIN_CLUSTER_KUBECONFIG: Pfad der Datei "kubeconfig" Ihres Administratorclusters

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

  /var/lib/gke/bundles/gke-onprem-vsphere-1.29.200-gke.245-full.tgz
  

• USER_CLUSTER_CONFIG: Pfad Ihrer Nutzercluster-Konfigurationsdatei

4. Nutzercluster erstellen

Erstellen Sie einen Nutzercluster:

gkectl create cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG 

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". Um diese Fehler zu vermeiden, fügen Sie den --skip-validation-gcp-Parameter an Ihre Befehle an.

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

Die Ausgabe zeigt den Namen des Clusters. Beispiel:

NAME
my-user-cluster

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

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

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

kubectl get nodes --kubeconfig USER_CLUSTER_KUBECONFIG

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

Die Ausgabe zeigt die Knoten des Nutzerclusters. Beispiel:

cp-vm-1       Ready    control-plane,master   18m
cp-vm-2       Ready    control-plane,master   18m
cp-vm-3       Ready    control-plane,master   18m
worker-vm-1   Ready                           6m7s
worker-vm-2   Ready                           6m6s
worker-vm-3   Ready                           6m14s

Console

Mehr erfahren

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

   Zur Seite „Google Distributed Cloud-Cluster erstellen“

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

Clustergrundlagen

Geben Sie grundlegende Informationen zum Cluster ein.

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 Google Cloud-Region aus der Liste aus. Diese Einstellung gibt die Region an, in der die folgenden APIs und Dienste ausgeführt werden:

   • GKE On-Prem API (gkeonprem.googleapis.com)
   • Flottendienst (gkehub.googleapis.com)
   • Connect-Dienst (gkeconnect.googleapis.com)

   Mit dieser Einstellung wird auch die Region gesteuert, 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

   Der Clustername, das Projekt und der Standort identifizieren den Cluster in Google Cloud eindeutig.

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

5. Als Clusterersteller erhalten Sie Administratorberechtigungen für den Cluster. Geben Sie optional im Abschnitt Autorisierung im Feld Clusteradministrator die E-Mail-Adresse eines anderen Nutzers ein, der den Cluster verwaltet.

   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 optional 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 Automatische Anpassung der Knotengröße aus. Die Größenanpassung bedeutet, dass die einem Knoten zugewiesenen vCPU- und Arbeitsspeicherressourcen automatisch angepasst werden. 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. Wählen Sie optional Steuerungsebene v2 aktivieren aus. Wenn Sie die Steuerungsebene V2 aktivieren, läuft die Steuerungsebene für einen Nutzercluster auf einem oder mehreren Knoten im Nutzercluster selbst und nicht im Administratorcluster (als Kubeception bezeichnet).

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

   Wenn die Steuerungsebene V2 aktiviert ist, gelten die vCPU- und Arbeitsspeicherfelder für die Knoten der Steuerungsebene im Nutzercluster. Die Anzahl der Knoten wird bestimmt durch die Anzahl der eingegebenen IP-Adressen. Wenn die Steuerungsebene V2 nicht aktiviert ist, gelten die Felder für vCPU, Arbeitsspeicher und Anzahl der Knoten der Steuerungsebene für die Knoten im Administratorcluster. Achten Sie darauf, genügend IP-Adressen für Ihren Administratorcluster festzulegen.

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 DHCP 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 einen manuellen Load-Balancer für den Nutzercluster nur verwenden, wenn Ihr Administratorcluster einen manuellen Load-Balancer verwendet. In Google Distributed Cloud werden der Kubernetes API-Server und der Ingress-Proxy jeweils von einem Kubernetes-Dienst vom Typ LoadBalancer bereitgestellt. Wählen Sie 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 wurde. 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

Sie erstellen einen Nutzercluster mit dem folgenden Befehl:

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.

Hinweise

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, bei 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. Dies ist entweder global oder eine Google Cloud-Region. Verwenden Sie den Standort für den Administratorcluster aus der Ausgabe von gcloud container fleet memberships list.

   • REGION: Die Google Cloud-Region, die Sie beim Erstellen des Clusters verwenden 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
   

   Versionen, die Sie zur Erstellung eines Nutzerclusters verwenden können, 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 einen Nutzercluster mit einer anderen verfügbaren Version erstellen möchten, finden Sie unter Neuere Version als die Version des Administratorclusters installieren weitere Informationen.

Beispiele

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

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

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 Clusterknoten zu erhalten.

Sie können MetalLB nur dann für den Nutzercluster verwenden, wenn Ihr Administratorcluster SeeSaw oder 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.

gcloud container vmware clusters create USER_CLUSTER_NAME \
    --project=FLEET_HOST_PROJECT_ID \
    --admin-cluster-membership=ADMIN_CLUSTER_NAME \
    --admin-cluster-membership-project=FLEET_HOST_PROJECT_ID \
    --admin-cluster-membership-location=ADMIN_CLUSTER_REGION \
    --location=REGION \
    --version=VERSION \
    --admin-users=YOUR_EMAIL_ADDRESS \
    --admin-users=ANOTHER_EMAIL_ADDRESS \
    --service-address-cidr-blocks=SERVICE_CIDR_BLOCK \
    --pod-address-cidr-blocks=POD_CIDR_BLOCK \
    --metal-lb-config-address-pools='pool=NAME,avoid-buggy-ips=True|False,manual-assign=True|False,addresses=IP_ADDRESS_RANGE_1;IP_ADDRESS_RANGE_2;...' \
    --control-plane-vip=CONTROL_PLANE_VIP \
    --ingress-vip=INGRESS_VIP \
    --enable-dhcp

Ersetzen Sie Folgendes:

• USER_CLUSTER_NAME: Ein Name Ihrer Wahl für den Nutzercluster. Der Name kann nach dem Erstellen des Clusters nicht mehr geändert werden. Der Name:
  • 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 wird der Cluster in Google Cloud eindeutig identifiziert.

  Wichtig: Wenn Sie Cloud Service Mesh installieren möchten, müssen Sie Version 1.19.3 oder höher installieren. Dies ist erforderlich, da die 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 Kommas.

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

  • Schließen Sie den gesamten Wert in einfache Anführungszeichen ein.
  • Leerzeichen sind nicht zulässig.
  • Trennen Sie die einzelnen IP-Adressbereiche durch ein Semikolon.

  Beispiel:

  --metal-lb-config-address-pool 'pool=pool1,avoid-buggy-ips=True,manual-assign=True,addresses=10.251.134.80/32;192.168.1.0/26;192.168.1.2-192.168.1.3'

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

  Beispiel: --control-plane-vip=203.0.113.3

• INGRESS_VIP: Die IP-Adresse, die Sie 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. Fügen Sie dieses Flag nicht hinzu, wenn Sie statische IP-Adressen für Ihre Clusterknoten angeben 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 Clusterknoten statische IP-Adressen zuweisen.

Sie können MetalLB nur dann für den Nutzercluster verwenden, wenn Ihr Administratorcluster SeeSaw oder 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.

Scrollen Sie gegebenenfalls nach unten, um die ADMIN_CLUSTER_NAME-Platzhalter für das --admin-cluster-membership-Flag auszufüllen. In diesem Beispiel wird der vollständig spezifizierte Administratorcluster-Name verwendet, sodass Sie --admin-cluster-membership-location und --admin-cluster-membership-project nicht angeben müssen.

gcloud container vmware clusters create USER_CLUSTER_NAME \
    --project=FLEET_HOST_PROJECT_ID \
    --admin-cluster-membership=ADMIN_CLUSTER_NAME \
    --admin-cluster-membership-project=FLEET_HOST_PROJECT_ID \
    --admin-cluster-membership-location=ADMIN_CLUSTER_REGION \
    --location=REGION \
    --version=VERSION \
    --admin-users=YOUR_EMAIL_ADDRESS \
    --admin-users=ANOTHER_EMAIL_ADDRESS \
    --service-address-cidr-blocks=SERVICE_CIDR_BLOCK \
    --pod-address-cidr-blocks=POD_CIDR_BLOCK \
    --metal-lb-config-address-pools='pool=NAME,avoid-buggy-ips=True|False,manual-assign=True|False,addresses=IP_ADDRESS_RANGE_1;IP_ADDRESS_RANGE_2;...' \
    --control-plane-vip=CONTROL_PLANE_VIP \
    --ingress-vip=INGRESS_VIP \
    --static-ip-config-ip-blocks='gateway=GATEWAY,netmask=NETMASK,ips=IP_ADDRESS_1;IP_ADDRESS_2 HOST_2;...' \
    --dns-servers=DNS_SERVER,... \
    --dns-search-domains=DNS_SEARCH_DOMAIN,... \
    --ntp-servers=NTP_SERVER,...

Ersetzen Sie Folgendes:

• USER_CLUSTER_NAME: Ein Name Ihrer Wahl für den Nutzercluster. Der Name kann nach dem Erstellen des Clusters nicht mehr geändert werden. Der Name:
  • 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 wird der Cluster in Google Cloud eindeutig identifiziert.

  Wichtig: Wenn Sie Cloud Service Mesh installieren möchten, müssen Sie Version 1.19.3 oder höher installieren. Dies ist erforderlich, da die 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 Kommas.

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

  • Schließen Sie den gesamten Wert in einfache Anführungszeichen ein.
  • Leerzeichen sind nicht zulässig.
  • Trennen Sie die einzelnen IP-Adressbereiche durch ein Semikolon.

  Beispiel:

  --metal-lb-config-address-pool 'pool=pool1,avoid-buggy-ips=True,manual-assign=True,addresses=10.251.134.80/32;192.168.1.0/26;192.168.1.2-192.168.1.3'

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

  Beispiel: --control-plane-vip=203.0.113.3

• INGRESS_VIP: Die IP-Adresse, die Sie 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 Kommas.

  Wichtige Hinweise:

  • Schließen Sie den gesamten Wert in einfache Anführungszeichen ein.
  • Leerzeichen sind nur zwischen einer IP-Adresse und einem Hostnamen zulässig.

  In der Liste der IP-Adressen:

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

  Beispiel:

  --static-ip-config-ip-blocks 'gateway=172.16.23.254,netmask=255.255.252.0,ips=172.16.20.10;172.16.20.11 host2;172.16.20.12/30'

• DNS_SERVER: eine durch Kommas getrennte Liste der IP-Adressen 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.

  Beispiel:

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

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

F5 BIG-IP und DHCP

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

Sie können F5 nur dann für den Nutzercluster verwenden, wenn Ihr Administratorcluster F5 verwendet. Achten Sie darauf, den F5 BIG-IP-ADC vor der Einbindung in Google Distributed Cloud zu installieren und zu konfigurieren.

gcloud container vmware clusters create USER_CLUSTER_NAME \
    --project=FLEET_HOST_PROJECT_ID \
    --admin-cluster-membership=ADMIN_CLUSTER_NAME \
    --admin-cluster-membership-project=FLEET_HOST_PROJECT_ID \
    --admin-cluster-membership-location=ADMIN_CLUSTER_REGION \
    --location=REGION \
    --version=VERSION \
    --admin-users=YOUR_EMAIL_ADDRESS \
    --admin-users=ANOTHER_EMAIL_ADDRESS \
    --service-address-cidr-blocks=SERVICE_CIDR_BLOCK \
    --pod-address-cidr-blocks=POD_CIDR_BLOCK \
    --f5-config-address=F5_CONFIG_ADDRESS \
    --f5-config-partition=F5_CONFIG_PARTITION \
    --f5-config-snat-pool=F5_CONFIG_SNAT_POOL \
    --control-plane-vipCONTROL_PLANE_VIP \
    --ingress-vip=INGRESS_VIP \
    --enable-dhcp

• USER_CLUSTER_NAME: Ein Name Ihrer Wahl für den Nutzercluster. Der Name kann nach dem Erstellen des Clusters nicht mehr geändert werden. Der Name:
  • 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 wird der Cluster in Google Cloud eindeutig identifiziert.

  Wichtig: Wenn Sie Cloud Service Mesh installieren möchten, müssen Sie Version 1.19.3 oder höher installieren. Dies ist erforderlich, da die 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

• F5_CONFIG_ADDRESS: Die Adresse Ihres F5 BIG-IP-Load-Balancers.

• F5_CONFIG_PARTITION: Der Name einer BIG-IP-Partition, die Sie für Ihren Administratorcluster erstellt haben.

• F5_CONFIG_SNAT_POOL: Der Name Ihres SNAT-Pools, falls zutreffend.

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

  Beispiel: --control-plane-vip=203.0.113.3

• INGRESS_VIP: Die IP-Adresse, die Sie 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. Fügen Sie dieses Flag nicht hinzu, wenn Sie statische IP-Adressen für Ihre Clusterknoten angeben oder das manuelle Load-Balancing einrichten möchten.

Manuelles Load-Balancing und statische IP-Adressen

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

Sie können nur dann einen manuellen Load-Balancer für den Nutzercluster verwenden, wenn Ihr Administratorcluster einen manuellen Load-Balancer verwendet. In 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.

gcloud container vmware clusters create USER_CLUSTER_NAME \
    --project=FLEET_HOST_PROJECT_ID \
    --admin-cluster-membership=ADMIN_CLUSTER_NAME \
    --admin-cluster-membership-project=FLEET_HOST_PROJECT_ID \
    --admin-cluster-membership-location=ADMIN_CLUSTER_REGION \
    --location=REGION \
    --version=VERSION \
    --admin-users=YOUR_EMAIL_ADDRESS \
    --admin-users=ANOTHER_EMAIL_ADDRESS \
    --service-address-cidr-blocks=SERVICE_CIDR_BLOCK \
    --pod-address-cidr-blocks=POD_CIDR_BLOCK \
    --control-plane-vip=CONTROL_PLANE_VIP \
    --control-plane-node-port=CONTROL_PLANE_NODE_PORT \
    --ingress-vip=INGRESS_VIP \
    --ingress-http-node-port=INGRESS_HTTP_NODE_PORT \
    --ingress-https-node-port=INGRESS_HTTPS_NODE_PORT \
    --konnectivity-server-node-port=KONNECTIVITY_SERVER_NODE_PORT

Ersetzen Sie Folgendes:

• USER_CLUSTER_NAME: Ein Name Ihrer Wahl für den Nutzercluster. Der Name kann nach dem Erstellen des Clusters nicht mehr geändert werden. Der Name:
  • 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 wird der Cluster in Google Cloud eindeutig identifiziert.

  Wichtig: Wenn Sie Cloud Service Mesh installieren möchten, müssen Sie Version 1.19.3 oder höher installieren. Dies ist erforderlich, da die 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

• CONTROL_PLANE_NODE_PORT: Ein nodePort-Wert für den Kubernetes API-Server.

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

  Beispiel: --ingress-vip=203.0.113.4

• INGRESS_HTTP_NODE_PORT: Ein nodePort-Wert für HTTP-Traffic zum Ingress-Proxy

• INGRESS_HTTPS_NODE_PORT: Ein nodePort-Wert für HTTPS-Traffic zum Ingress-Proxy

• KONNECTIVITY_SERVER_NODE_PORT: Ein nodePort-Wert für den Konnectivity-Server.

• --static-ip-config-ip-blocks: Geben Sie das Standardgateway, die Subnetzmaske und eine Liste der statischen IP-Adressen für die Worker-Knoten im Nutzercluster an. Der Wert für das Flag hat 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 Kommas.

  Wichtige Hinweise:

  • Schließen Sie den gesamten Wert in einfache Anführungszeichen ein.
  • Leerzeichen sind nur zwischen einer IP-Adresse und einem Hostnamen zulässig.

  In der Liste der IP-Adressen:

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

  Beispiel:

  --static-ip-config-ip-blocks 'gateway=172.16.23.254,netmask=255.255.252.0,ips=172.16.20.10;172.16.20.11 host2;172.16.20.12/30'

• DNS_SERVER: eine durch Kommas getrennte Liste der IP-Adressen 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.

  Beispiel:

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

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

Flags der Steuerungsebene

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

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

• --memory=MEMORY: Die Größe des Arbeitsspeichers in Mebibyte (MiB) für jede Steuerungsebene des Nutzerclusters. 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, fügen Sie --enable-control-plane-v2 hinzu. Wenn die Steuerungsebene V2 aktiviert ist, wird die Steuerungsebene für einen Nutzercluster auf einem oder mehreren Knoten im Nutzercluster selbst ausgeführt. Standardmäßig wird die Steuerungsebene für einen Nutzercluster auf einem oder mehreren Knoten auf dem Administratorcluster ausgeführt (als Kubeception-Modell bezeichnet). Wenn die Steuerungsebene v2 aktiviert ist, gelten die Werte für --cpus und --memory für die Knoten der Steuerungsebene im Nutzercluster. Die Anzahl der Knoten wird anhand der Anzahl der IP-Adressen bestimmt, die Sie in --control-plane-ip-block eingeben. Wenn die Steuerungsebene V2 nicht aktiviert ist, gelten die Werte für --cpus, --memory und --replicas für die Knoten der Steuerungsebene im Administratorcluster. Stellen Sie genügend IP-Adressen für Ihren Administratorcluster bereit.

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

  • --dns-servers=DNS_SERVER_1,...: eine durch Kommas getrennte Liste der IP-Adressen 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 folgendem Format:

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

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

    Wichtige Hinweise:

    • Schließen Sie den gesamten Wert in einfache Anführungszeichen ein.

    • 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 den Hostnamen an.

      Beispiel:

      --control-plane-ip-block 'gateway=192.168.0.1,netmask=255.0.0.0,ips=192.168.1.1;192.168.1.2 hostname-2;192.168.2.2/28`
      

  • Optional: --dns-search-domains=DNS_SEARCH_DOMAIN_1,...: Eine durch Kommas getrennte Liste der DNS-Such-Domains, die von den Hosts verwendet werden können. Diese Domains werden als Teil einer Domainsuchliste verwendet.

    Beispiel:

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

  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 und ihrer Beschreibungen finden Sie in der Referenz zur gcloud CLI.

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

  Die Ausgabe des Befehls sieht in etwa so aus:

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

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

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

  Weitere Informationen finden Sie unter gcloud container vmware operations.

  Das Erstellen des Nutzerclusters dauert mindestens 15 Minuten. Sie können den Cluster in der Google Cloud Console auf der Seite 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 einen der folgenden Werte fest: ubuntu_containerd oder cos.

• BOOT_DISK_SIZE: Die Größe des Bootlaufwerks in Gibibyte (GiB) für jeden Knoten im Pool. Das Minimum beträgt 40 GiB.

• vCPUs: Die Anzahl der 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 der Wert 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.

Beispiele für gcloud-Befehle

MetalLB und DHCP

gcloud container vmware clusters create user-cluster-1 \
    --project=example-project-12345 \
    --location=us-west1 \
    --admin-cluster-membership=projects/example-project-12345/locations/global/memberships/admin-cluster-1 \
    --version=1.29.100-gke.248 \
    --admin-users=[e-mail] \
    --admin-users=[e-mail] \
    --enable-dhcp \
    --service-address-cidr-blocks=10.96.232.0/24 \
    --pod-address-cidr-blocks=192.168.0.0/16 \
    --metal-lb-config-address-pools='pool=lb-pool-1,manual-assign=False,avoid-buggy-ips=True,addresses=10.251.133.0/24;10.251.134.80/32;10.251.134.81/32' \
    --metal-lb-config-address-pools='pool=lb-pool-2,manual-assign=True,addresses=172.16.20.62/32' \
    --control-plane-vip=172.16.20.61 \
    --ingress-vip=172.16.20.62

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

MetalLB und statische IP-Adressen

gcloud container vmware clusters create user-cluster-3 \
    --project=example-project-12345 \
    --location=europe-west1 \
    --admin-cluster-membership=projects/example-project-12345/locations/global/memberships/admin-cluster-1 \
    --version=1.29.100-gke.248 \
    --admin-users=[e-mail] \
    --admin-users=[e-mail] \
    --static-ip-config-ip-blocks='gateway=172.16.23.254,netmask=255.255.252.0,ips=172.16.20.10 user-vm-1;172.16.20.11 user-vm-2' \
    --static-ip-config-ip-blocks='gateway=172.16.23.255,netmask=255.255.252.0,ips=172.16.20.12 user-vm-3;172.16.20.13 extra-vm' \
    --dns-servers=203.0.113.1,198.51.100.1 \
    --dns-search-domains=example.com,altostrat.com \
    --ntp-servers=216.239.35.4,216.239.35.5 \
    --service-address-cidr-blocks=10.96.232.0/24 \
    --pod-address-cidr-blocks=192.168.0.0/16 \
    --metal-lb-config-address-pools='pool=lb-pool-1,manual-assign=False,avoid-buggy-ips=True,addresses=10.251.133.0/24;10.251.134.80/32;10.251.134.81/32' \
    --metal-lb-config-address-pools='pool=lb-pool-2,manual-assign=True,addresses=172.16.20.62/32' \
    --control-plane-vip=172.16.20.61 \
    --ingress-vip=172.16.20.62

F5 BIG-IP und DHCP

gcloud container vmware clusters create user-cluster-2 \
    --project=example-project-12345 \
    --location=us-west1 \
    --admin-cluster-membership=projects/example-project-12345/locations/global/memberships/admin-cluster-1 \
    --version=1.29.100-gke.248 \
    --admin-users=[e-mail] \
    --admin-users=[e-mail] \
    --enable-dhcp \
    --service-address-cidr-blocks=10.96.232.0/24 \
    --pod-address-cidr-blocks=192.168.0.0/16 \
    --f5-config-address=203.0.113.2 \
    --f5-config-partition=my-f5-admin-partition \
    --control-plane-vip=172.16.20.61 \
    --ingress-vip=172.16.20.62

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

Manuelles Load-Balancing und statische IP-Adressen

gcloud container vmware clusters create user-cluster-4 \
    --project=example-project-12345 \
    --location=asia-east1 \
    --admin-cluster-membership=projects/example-project-12345/locations/global/memberships/admin-cluster-1 \
    --version=1.29.100-gke.248 \
    --admin-users=[e-mail] \
    --admin-users=[e-mail] \
    --static-ip-config-ip-blocks='gateway=172.16.23.254,netmask=255.255.252.0,ips=172.16.20.10 user-vm-1;172.16.20.11 user-vm-2' \
    --static-ip-config-ip-blocks='gateway=172.16.23.255,netmask=255.255.252.0,ips=172.16.20.12 user-vm-3;172.16.20.13 extra-vm' \
    --dns-servers=203.0.113.1,198.51.100.1  \
    --ntp-servers=216.239.35.4,216.239.35.5 \
    --service-address-cidr-blocks=10.96.232.0/24 \
    --pod-address-cidr-blocks=192.168.0.0/16 \
    --control-plane-vip=172.16.20.61 \
    --control-plane-node-port=30968 \
    --ingress-vip=172.16.20.62 \
    --ingress-http-node-port=32527 \
    --ingress-https-node-port=30139 \
    --konnectivity-server-node-port=30969

Terraform

Hinweise

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, bei 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 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. Dies ist entweder global oder eine Google Cloud-Region. Verwenden Sie den Standort für den Administratorcluster aus der Ausgabe von gcloud container fleet memberships list.

   • REGION: Die Google Cloud-Region, die Sie beim Erstellen des Clusters verwenden 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
   

   Versionen, die Sie zur Erstellung eines Nutzerclusters verwenden können, 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 einen Nutzercluster mit einer anderen verfügbaren Version erstellen möchten, finden Sie unter Neuere Version als die Version des Administratorclusters installieren weitere Informationen.

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 zu erstellen.

Weitere Informationen und Beispiele finden Sie in der Referenzdokumentation zu google_gkeonprem_vmware_cluster

Variablen in terraform.tfvars festlegen

Das Beispiel enthält eine 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, was in etwa so aussieht:

     admin_cluster_membership = "projects/${var.project_id}/locations/global/memberships/${var.admin_cluster_name}"

     1. Ändern Sie global in die Region, die der Administratorcluster verwendet, und speichern Sie die Datei.

   • on_prem_version: Google Distributed Cloud-Version für Ihren Nutzercluster. In der Regel geben Sie die gleiche Version wie der Administratorcluster an. Um eine aktuellere Version anzugeben, installieren Sie eine neuere Version als die Version des Administratorclusters. Wenn Sie die Version des Administratorclusters nicht kennen, führen Sie gcloud container vmware clusters query-version-config aus. Dies ist der erste Schritt unter Spätere Version als die Version des Administratorclusters installieren.

   • admin_user_emails: eine Liste der E-Mail-Adressen der Nutzer, denen Administratorberechtigungen für den Cluster gewährt werden sollen. Fügen Sie 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.

Optional: Clustereinstellungen in main.tf konfigurieren

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

cp main.tf main.tf.bak

IP-Adressierungsmodus für Worker-Knoten

main.tf konfiguriert den Cluster standardmäßig so, dass ein von Ihnen bereitgestellter DHCP-Server verwendet wird, um den Worker-Knoten des Clusters IP-Adressen zuzuweisen. DHCP wird 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 Block network_config und fügen Sie den Block static_ip_config ein. Beispiel:

     network_config {
       service_address_cidr_blocks = ["10.96.0.0/12"]
       pod_address_cidr_blocks = ["192.168.0.0/16"]
       host_config {
         dns_servers = ["10.254.41.1"]
         ntp_servers = ["216.239.35.8"]
       }
       static_ip_config {
         ip_blocks {
           netmask = "255.255.252.0"
           gateway = "10.251.31.254"
           ips {
             ip = "10.251.30.153"
             hostname = "vm-1"
           }
           ips {
             ip = "10.251.31.206"
             hostname = "vm-2"
           }
           ips {
             ip = "10.251.31.193"
             hostname = "vm-3"
           }
           ips {
             ip = "10.251.30.230"
             hostname = "vm-4"
           }
         }
       }
     }
   

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 der DNS-Server 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 Sie ip und hostname durch die IP-Adressen und Hostnamen Ihrer Worker-Knoten.

Steuerungsebene V2 konfigurieren

Standardmäßig konfiguriert main.tf die Steuerungsebene für den Nutzercluster so, dass sie auf einem oder mehreren Knoten im Administratorcluster ausgeführt wird (als Kubeception-Modell bezeichnet). Sie können auch Steuerungsebene V2 aktivieren. Wenn Steuerungsebene V2 aktiviert ist, wird die Steuerungsebene für einen Nutzercluster auf einem oder mehreren Knoten im Nutzercluster selbst ausgeführt. Zum Konfigurieren von Steuerungsebene V2 nehmen Sie folgende Änderungen an main.tf vor:

1. Fügen Sie nach der Zeile mit admin_cluster_membership die folgende Zeile ein:

     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.

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. Prü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 oder länger und das Erstellen des Knotenpools dauert weitere 15 Minuten. Sie können den Cluster in der Google Cloud Console auf der Seite GKE-Cluster aufrufen.

Eine neuere Version als die Version des Administratorclusters installieren

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

1. Rufen Sie eine Liste der verfügbaren Versionen ab:

   gcloud container vmware clusters query-version-config \
       --admin-cluster-membership=ADMIN_CLUSTER_NAME \
       --admin-cluster-membership-project=FLEET_HOST_PROJECT_ID \
       --location=REGION
   

   Ersetzen Sie Folgendes:

   • ADMIN_CLUSTER_NAME: Der Name des Administratorclusters.

   • FLEET_HOST_PROJECT_ID: die ID des Projekts, bei dem der Administratorcluster registriert ist.

   • REGION: Die Google Cloud-Region, in der die GKE On-Prem API ausgeführt wird. Dies ist die Region, die Sie beim Erstellen des Nutzerclusters angeben. Geben Sie us-west1 oder eine andere unterstützte Region an.

   Die Ausgabe dieses Befehls sieht in etwa so aus:

   versions:
   - isInstalled: true
     version: 1.14.3-gke.25
   - version: 1.14.4-gke.54
   - version: 1.15.0-gke.581
   

   Im Administratorcluster installierte Versionen werden mit isInstalled=true annotiert.

2. Falls noch nicht geschehen, registrieren Sie den Administratorcluster in der GKE On-Prem API. Nachdem der Cluster in der GKE On-Prem API registriert wurde, müssen Sie diesen Schritt nicht noch einmal ausführen.

3. Laden Sie die neue Version der Komponenten herunter und stellen Sie sie im Administratorcluster bereit:

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

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

Fehlerbehebung

Siehe Fehlerbehebung beim Erstellen und Upgraden von Clustern.

Nächste Schritte

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