Nutzercluster für die Verwendung mit Topologiedomains erstellen

In Google Distributed Cloud werden Ihre Arbeitslasten auf einem oder mehreren Nutzerclustern ausgeführt. Auf dieser Seite wird gezeigt, wie Sie einen Nutzercluster für die Verwendung in Topologiedomänen in Google Distributed Cloud erstellen. Für die Verwendung von Topologiedomänen ist Google Distributed Cloud-Version 1.31 oder höher erforderlich.

Wenn Sie eine Topologiedomain einrichten möchten, müssen Sie den erweiterten Cluster aktivieren. Beachten Sie die folgenden Einschränkungen der Vorabversion für erweiterte Cluster:

  • Sie können erweiterte Cluster nur beim Erstellen neuer Cluster der Version 1.31 aktivieren.
  • Nachdem die erweiterten Clusterfunktionen aktiviert wurden, können Sie den Cluster nicht mehr auf Version 1.32 aktualisieren. Aktivieren Sie den erweiterten Cluster nur in einer Testumgebung.

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

Hinweise

Verfahrensübersicht

Mit den folgenden Schritten können Sie mit gkectl einen Nutzercluster erstellen:

  1. Konfigurationsdatei für den Nutzercluster ausfüllen
    Geben Sie die Details für den neuen Cluster in der Konfigurationsdatei des Nutzerclusters an.
  2. IP-Blockdatei ausfüllen
    Geben Sie die IP-Adressen für das Gateway, die Netzmaske, die Knoten der Steuerungsebene und optional die Worker-Knoten in einer IP-Blockdatei an.
  3. Nutzercluster erstellen
    Führen Sie gkectl create cluster aus, um einen Cluster zu erstellen, wie in den Konfigurationsdateien angegeben.
  4. Prüfen Sie, ob Ihr Nutzercluster ausgeführt wird
    Rufen Sie mit kubectl die Clusterknoten auf.

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

Konfigurationsdatei für den Nutzercluster ausfüllen

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

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

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

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

Dabei gilt:

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

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

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.31.0-gke.889.

enableAdvancedCluster

Legen Sie enableAdvancedCluster auf true fest.

enableControlplaneV2

Controlplane V2 ist für alle Nutzercluster ab Version 1.30 erforderlich. Legen Sie enableControlplaneV2 auf true fest.

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

enableDataplaneV2

Legen Sie enableDataplaneV2 auf true fest.

vCenter

Entfernen Sie diesen gesamten Abschnitt. Stattdessen konfigurieren Sie die vCenter-Informationen in der Konfigurationsdatei der vSphere-Infrastruktur pro Topologiedomain.

network

  • Entfernen Sie Folgendes aus der Konfigurationsdatei:

    • Den gesamten Abschnitt network.hostConfig. Diese Informationen werden in der Konfigurationsdatei der vSphere-Infrastruktur pro Topologiedomain konfiguriert.
    • Das Feld network.vCenter.networkName. Dieses Feld wird in der Konfigurationsdatei der vSphere-Infrastruktur pro Topologiedomain konfiguriert.
    • Den gesamten Abschnitt network.controlPlaneIPBlock. Die IP-Adressen für das Gateway, die Subnetzmaske und die Knoten der Steuerungsebene werden in einer IP-Blockdatei konfiguriert.

  • Legen Sie für network.ipMode.ipBlockFilePath den Pfad zur IP-Blockdatei fest.

  • 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 statischen IP-Adressen, die Sie in der IP-Blockdatei angeben. Setzen Sie network.ipMode.type auf "static".

    Die Knoten der Steuerungsebene für Ihren Nutzercluster müssen ihre IP-Adressen aus einer Liste statischer Adressen beziehen, die Sie in der IP-Blockdatei angeben. Dies ist auch dann der Fall, wenn Ihre Worker-Knoten ihre Adressen von einem DHCP-Server beziehen.

    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.

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

loadBalancer

advancedNetworking

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

multipleNetworkInterfaces

Legen Sie für multipleNetworkInterfaces den Wert false fest. Mehrere Netzwerkschnittstellen für Pods werden in Topologiedomänen nicht unterstützt.

storage

Legen Sie storage.vSphereCSIDisabled auf true fest, um die Bereitstellung von vSphere-CSI-Komponenten zu deaktivieren.

masterNode

  • Wenn Sie CPU und Arbeitsspeicher für die Knoten der Steuerungsebene des Nutzerclusters angeben möchten, füllen Sie die Felder cpus und memoryMB im Abschnitt masterNode aus.

  • Es werden nur Hochverfügbarkeitscluster (HA) unterstützt. Legen Sie das Feld replicas auf 3 fest, um anzugeben, dass der Cluster drei Knoten der Steuerungsebene haben soll.

  • Wenn Sie die automatische Größenanpassung für die Knoten der Steuerungsebene aktivieren möchten, setzen Sie autoResize.enabled auf true.

  • Entfernen Sie den gesamten Abschnitt masterNode.vsphere.

  • Geben Sie im Feld masterNode.topologyDomains den Namen der Topologiedomain ein, in der sich die Knoten der Steuerungsebene befinden sollen.

nodePools

Ein Knotenpool besteht aus einer Gruppe von Worker-Knoten in einem Cluster, die alle dieselbe Konfiguration haben. Beispiel: Sie möchten für jeden Knotenpool eine separate Topologiedomain einrichten. Sie müssen mindestens einen Knotenpool angeben, indem Sie den Abschnitt nodePools ausfüllen.

Für jeden angegebenen Knotenpool gilt:

  • Geben Sie in das Feld nodePools[i].topologyDomains den Namen der Topologiedomain ein, in der sich der Knotenpool befinden soll.

  • Entfernen Sie alle Felder im Abschnitt nodePools[i].vsphere mit Ausnahme von nodePools[i].vsphere.tags. Sie geben diese Informationen in der vSphere-Infrastrukturkonfigurationsdatei pro Topologiedomain an.

# advanced-cluster-change #

Legen Sie nodePools[i].osImageType auf ubuntu_cgroupv2 oder ubuntu_containerd fest.

Allgemeine Informationen zu Knotenpools finden Sie unter Knotenpools und Knotenpools erstellen und verwalten.

antiAffinityGroups

Legen Sie antiAffinityGroups.enabled auf false fest. Anti-Affinitätsregeln des Distributed Resource Schedulers (DRS) werden von Topologiedomains nicht unterstützt.

stackdriver

Füllen Sie den Abschnitt stackdriver aus, um Cloud Logging und Cloud Monitoring für Ihren Cluster zu aktivieren.

Beachten Sie folgende Anforderungen:

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

  • Die in stackdriver.clusterLocation festgelegte Region für Google Cloud muss mit der in cloudAuditLogging.clusterLocation und gkeConnect.location festgelegten Region ü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.

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.

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

Wenn Sie gkeConnect.location in 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

In diesem Abschnitt wird beschrieben, wie Cluster in der GKE On-Prem API registriert werden.

Das gkectl-Befehlszeilentool ist das einzige verfügbare Tool zum Verwalten des Clusterlebenszyklus für Cluster mit Topologiedomänen. Die Google Cloud -Console, die Google Cloud CLI und Terraform werden zwar nicht für Cluster mit Topologiedomänen unterstützt, Sie können den Cluster aber optional bei der Erstellung in der GKE On-Prem API registrieren.

Wenn die GKE On-Prem API in IhremGoogle Cloud -Projekt aktiviert ist, werden alle Cluster im Projekt automatisch in der in stackdriver.clusterLocation konfigurierten Region in der GKE On-Prem API registriert. Die Region gkeOnPremAPI.location muss mit der Region übereinstimmen, die in cloudAuditLogging.clusterLocation, gkeConnect.location und stackdriver.clusterLocation angegeben ist.

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

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

cloudAuditLogging

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

Beachten Sie folgende Anforderungen:

# advanced-cluster-change #

Legen Sie für cloudAuditLogging.serviceAccountKeyPath denselben Pfad wie für stackdriver.serviceAccountKeyPath fest.

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

  • Die Region in cloudAuditLogging.clusterLocation muss mit der Region übereinstimmen, die in gkeConnect.location (wenn das Feld in Ihrer Konfigurationsdatei enthalten ist) und stackdriver.clusterLocation festgelegt ist. 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.

preparedSecrets

Entfernen Sie das Feld preparedSecrets. Vorbereitete Anmeldedaten werden nicht unterstützt, wenn Topologiedomains aktiviert sind.

Beispiel für ausgefüllte Konfigurationsdateien

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

user-ipblock.yaml

blocks:
  - netmask: 255.255.255.0
    gateway: 172.16.21.1
    ips:
    - ip: 172.16.21.2
      hostname: worker-vm-1
    - ip: 172.16.21.3
      hostname: worker-vm-2
    - ip: 172.16.21.4
      hostname: worker-vm-3
    - ip: 172.16.21.5
      hostname: worker-vm-4
  - netmask: 255.255.255.0
    gateway: 100.115.223.254
    ips:
    - ip: 100.115.222.205
      hostname: cp-1
      isControlPlane: true
    - ip: 100.115.222.206
      hostname: cp-2
      isControlPlane: true
    - ip: 100.115.222.207
      hostname: cp-3
      isControlPlane: true

user-cluster.yaml

cat user-cluster.yaml
apiVersion: v1
kind: UserCluster
name: "my-user-cluster"
gkeOnPremVersion: 1.31.0-gke.889
enableAdvancedCluster: true
enableControlplaneV2: true
enableDataplaneV2: true
network:
  ipMode:
    type: "static"
    ipBlockFilePath: "user-ipblock.yaml"
  serviceCIDR: 10.96.0.0/20
  podCIDR: 192.168.0.0/16
loadBalancer:
  vips:
    controlPlaneVIP: "100.115.222.200"
    ingressVIP: "172.16.21.30"
  kind: "ManualLB"
  manualLB:
    ingressHTTPNodePort: 32527
    ingressHTTPSNodePort: 30139
    controlPlaneNodePort: 30968
masterNode:
  cpus: 4
  memoryMB: 8192
  replicas: 3
nodePools:
- name: "worker-node-pool1"
  cpus: 4
  memoryMB: 8192
  replicas: 3
  topologyDomains:
  - "domain1"
antiAffinityGroups:
  enabled: false
gkeConnect:
  projectID: "my-project-123"
  location: "us-central1"
  registerServiceAccountKeyPath: "connect-register-sa-2203040617.json"
stackdriver:
  projectID: "my-project-123"
  clusterLocation: "us-central1"
  enableVPC: false
  serviceAccountKeyPath: "log-mon-sa-2203040617.json"
autoRepair:
  enabled: true

Im obigen Beispiel sind dies die wichtigsten Punkte:

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

  • Die IP-Adressen für die Knoten der Steuerungsebene und die Worker-Knoten werden in einer IP-Blockdatei angegeben. Die IP-Blockdatei enthält vier Adressen für Worker-Knoten, obwohl es nur drei Worker-Knoten gibt. Die zusätzliche IP-Adresse des Worker-Knotens wird während des Clusterupgrades, des Updates und der automatischen Reparatur benötigt. Die IP-Adressen für die Knoten der Steuerungsebene haben dasisControlPlane: true-Flag.

  • Erweiterte Cluster, Controlplane V2 und Dataplane V2 sind aktiviert.

  • Das Feld masterNode.replicas ist auf 3 festgelegt. Der Cluster hat also eine Steuerungsebene mit Hochverfügbarkeit.

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

IP-Blockdatei ausfüllen

Kopieren Sie die Vorlage für die IP-Blockdatei in die Datei im Verzeichnis, das Sie im Feld network.ipMode.ipBlockFilePath in der Konfigurationsdatei des Nutzerclusters angegeben haben. Erstellen Sie separate IP-Blockdateien für den Administratorcluster und für jeden Nutzercluster.

Fügen Sie der IP-Blockdatei die IP-Adressen für das Gateway, die Subnetzmaske und die Knoten der Steuerungsebene hinzu. Fügen Sie für jede IP-Adresse des Knotens der Steuerungsebene isControlPlane: true hinzu, wie im vorherigen Beispiel gezeigt. Wenn Sie einen hochverfügbaren Nutzercluster (HA, High Availability) wünschen, geben Sie drei IP-Adressen an. Geben Sie andernfalls eine IP-Adresse an. Die Anzahl der IP-Adressen, die Sie für Knoten der Steuerungsebene angeben, muss mit der Anzahl im Feld masterNode.replicas in der Konfigurationsdatei des Nutzerclusters übereinstimmen.

Wenn network.ipMode.type auf "static" gesetzt ist, fügen Sie der IP-Blockdatei die IP-Adressen der Worker-Knoten hinzu. Geben Sie eine zusätzliche IP-Adresse für die Verwendung während des Clusterupgrades, des Updates und der automatischen Reparatur an.

Jede Gateway-Adresse in der IP-Blockdatei muss mit der Adresse übereinstimmen, die in einem topologyDomains[i].network.gateway-Feld in der Konfigurationsdatei der vSphere-Infrastruktur angegeben ist. Weitere Informationen finden Sie im Beispiel für Topologiedomains.

Nutzercluster erstellen

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

gkectl create cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

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

NAME
my-user-cluster

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

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

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

kubectl get nodes --kubeconfig USER_CLUSTER_KUBECONFIG

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

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

PodTemplate konfigurieren

Das Topologielabel wird in die Labels der Knoten in der Topologiedomain eingefügt. Sofern bei der Einrichtung Ihrer Topologiedomain nicht die Standardeinschränkung "topology.kubernetes.io/zone" als Topologieschlüssel verwendet wurde, müssen Sie den Topologieschlüssel in der Pod-Vorlage Ihres Deployments, StatefulSets oder Replicasets konfigurieren.

Angenommen, Sie haben den Schlüssel im Topologielabel als "topology.examplepetstore.com/zone" definiert. In PodTemplate geben Sie den Schlüssel als Wert für das Feld topologySpreadConstraints.topologyKey an. So kann der Kubernetes-Planer Pods über die Topologiedomain verteilen, um eine hohe Verfügbarkeit zu gewährleisten und eine Überkonzentrierung in einem einzelnen Bereich bei einem Ausfall zu verhindern.

Fehlerbehebung

Siehe Fehlerbehebung beim Erstellen und Upgraden von Clustern.

Nächste Schritte