Nutzercluster für die Verwendung mit Topologiedomänen erstellen

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

Zum Einrichten einer Topologiedomäne müssen Sie den erweiterten Cluster aktivieren. Beachten Sie die folgenden Einschränkungen bei der Vorschau des erweiterten Clusters:

  • Sie können den erweiterten Cluster nur beim Erstellen des Clusters für neue Cluster der Version 1.31 aktivieren.
  • Nachdem der erweiterte Cluster aktiviert wurde, können Sie den Cluster nicht 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-Nutzerrollen und -Aufgaben.

Hinweis

Verfahrensübersicht

Die folgenden Hauptschritte sind erforderlich, um mit gkectl einen Nutzercluster zu 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 wie in den Konfigurationsdateien angegeben zu erstellen.
  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 Ihre Administrator-Workstation mit gkeadm erstellt haben, hat gkeadm eine Vorlage für die Konfigurationsdatei des Nutzerclusters mit dem Namen user-cluster.yaml generiert. Außerdem hat gkeadm einige der 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.36.0-gke.532.

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.36.0-gke.532.

enableAdvancedCluster

Setzen Sie enableAdvancedCluster auf true.

enableControlplaneV2

Controlplane V2 ist für alle Nutzercluster der Version 1.30 und höher erforderlich. Setzen Sie enableControlplaneV2 auf true.

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 Topologiedomäne.

network

  • Entfernen Sie Folgendes aus der Konfigurationsdatei:

    • Der gesamte Abschnitt network.hostConfig. Diese Informationen werden in der Konfigurationsdatei der vSphere-Infrastruktur pro Topologiedomäne konfiguriert.
    • Das Feld network.vCenter.networkName. Dieses Feld wird in der Konfigurationsdatei der vSphere-Infrastruktur pro Topologiedomäne konfiguriert.
    • Der gesamte Abschnitt network.controlPlaneIPBlock. Die IP-Adressen für das Gateway, die Netzmaske und die Knoten der Steuerungsebene werden in einer IP-Blockdatei konfiguriert.

  • Setzen Sie network.ipMode.ipBlockFilePath auf den Pfad zur IP-Blockdatei.

  • 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. Setzen Sie network.ipMode.type auf "dhcp".

    • Aus einer Liste der von Ihnen in der IP-Blockdatei angegebenen statischen IP-Adressen. Setzen Sie network.ipMode.type auf "static".

    Die Knoten der Steuerungsebene für Ihren Nutzercluster müssen ihre IP-Adressen aus einer von Ihnen in der IP-Blockdatei bereitgestellten Liste statischer Adressen beziehen. 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.

  • Die 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 Trafficerstellen möchten, legen Sie für advancedNetworking den Wert true fest.

multipleNetworkInterfaces

Setzen Sie multipleNetworkInterfaces auf false. Mehrere Netzwerkschnittstellen für Pods werden mit Topologiedomänen nicht unterstützt.

storage

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

masterNode

  • Wenn Sie CPU und Arbeitsspeicher für die Knoten der Steuerungsebene des Nutzer clusters angeben möchten, füllen Sie die cpus und memoryMB Felder in der masterNode Sektion aus.

  • Es werden nur hochverfügbare Cluster unterstützt. Setzen Sie das Feld replicas auf 3, 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 masterNode.vsphere Abschnitt.

  • Geben Sie im masterNode.topologyDomains Feld den Namen der Topologiedomäne an, 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. Sie können beispielsweise für jeden Knotenpool eine separate Topologiedomäne einrichten. Sie müssen mindestens einen Knotenpool angeben, indem Sie den nodePools Abschnitt ausfüllen.

Für jeden Knotenpool, den Sie angeben:

  • Geben Sie im nodePools[i].topologyDomains Feld den Namen der Topologiedomäne an, in der sich der Knotenpool befinden soll.

  • Entfernen Sie alle Felder im Abschnitt nodePools[i].vsphere mit Ausnahme von nodePools[i].vsphere.tags. Diese Informationen werden in der Konfigurationsdatei der vSphere-Infrastruktur pro Topologiedomäne angegeben.

  • Setzen Sie nodePools[i].osImageType auf ubuntu_cgv2.

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

antiAffinityGroups

Set antiAffinityGroups.enabled auf false. DRS-Anti-Affinitätsregeln (Distributed Resource Scheduler) werden mit Topologiedomänen nicht unterstützt.

stackdriver

Füllen Sie den stackdriver Abschnitt 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 Google Cloud in stackdriver.clusterLocation festgelegte Region muss mit der in cloudAuditLogging.clusterLocation und gkeConnect.location festgelegten Region übereinstimmen. Wenn außerdem gkeOnPremAPI.enabled auf true gesetzt 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 gkeConnect Abschnitt 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.

Optional können Sie in gkeConnect.location eine Region angeben, in der die Flotten- und Connect-Dienste 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 für das Lebenszyklusmanagement von Clustern , die Topologiedomänen verwenden. Obwohl die Google Cloud Console, die Google Cloud CLI und Terraform für Cluster, die Topologie Domänen verwenden, nicht unterstützt werden, können Sie den Cluster optional bei der Erstellung in der GKE On-Prem API registrieren.

Wenn 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 registriert, die in stackdriver.clusterLocationkonfiguriert wurde. 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 cloudAuditLogging Abschnitt aus.

Beachten Sie folgende Anforderungen:

# advanced-cluster-change #

Setzen Sie cloudAuditLogging.serviceAccountKeyPath auf denselben Pfad wie stackdriver.serviceAccountKeyPath.

  • 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 (falls das Feld in der 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 Topologiedomänen aktiviert sind.

schedulerConfiguration

Wenn Sie zusätzliche Konfigurationen einrichten möchten, die an kube-scheduler übergeben werden, fügen Sie der Konfigurationsdatei den schedulerConfiguration Abschnitt hinzu.

Beispiel für ausgefüllte Konfigurationsdateien

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

user-ipblock.yaml

blocks:
  - netmask: 255.255.255.0
    gateway: 172.16.21.1
    ips:
    - ip: 172.16.21.2
      hostname: worker-vm-1
    - ip: 172.16.21.3
      hostname: worker-vm-2
    - ip: 172.16.21.4
      hostname: worker-vm-3
    - ip: 172.16.21.5
      hostname: worker-vm-4
  - 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.36.0-gke.532
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 drei Worker-Knoten in "worker-node-pool" gibt. Alle Worker-Knoten verwenden statische IP Adressen, da network.ipMode.type auf "static" gesetzt 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 für den Worker-Knoten wird während des Clusterupgrades, des Updates und der automatischen Reparatur benötigt. Die IP-Adressen für die Knoten der Steuerungsebene haben das Flag isControlPlane: true.

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

  • Das Feld masterNode.replicas ist auf 3 gesetzt. Der Cluster hat also eine hochverfügbare Steuerungsebene.

  • Die VIP der Steuerungsebene befindet sich im selben VLAN wie die Knoten der Steuerungsebene und die VIP 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 network.ipMode.ipBlockFilePath Feld 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 Netzmaske 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 erstellen möchten, geben Sie drei IP-Adressen an. Andernfalls geben Sie eine IP-Adresse an. Die Anzahl der IP-Adressen, die Sie für die 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 für die Worker-Knoten hinzu. Geben Sie unbedingt 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 Feld topologyDomains[i].network.gateway in der Konfigurationsdatei der vSphere-Infrastruktur angegeben ist. Weitere Informationen finden Sie im Beispiel für Topologiedomänen.

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

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

PodTemplate konfigurieren

Das Topologielabel wird in die Labels der Knoten in der Topologiedomäne eingefügt. Sofern in Ihrer Topologiedomäne nicht die Standardeinschränkung, "topology.kubernetes.io/zone" als Topologieschlüssel verwendet wurde, müssen Sie den Topologieschlüssel gegebenenfalls in der Pod Vorlage Ihrer Bereitstellung, Ihres StatefulSets oder Ihres ReplicaSets konfigurieren.

Angenommen, Sie haben den Schlüssel im Topologielabel als "topology.examplepetstore.com/zone" definiert. In der PodTemplate geben Sie den Schlüssel als Wert für das Feld topologySpreadConstraints.topologyKey an. So kann der Kubernetes-Scheduler Pods in der Topologiedomäne verteilen, um eine Hochverfügbarkeit zu gewährleisten und eine Überkonzentration in einem einzelnen Bereich im Falle eines Fehlers zu verhindern.

Fehlerbehebung

Siehe Fehlerbehebung beim Erstellen und Upgraden von Clustern.

Nächste Schritte