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 Topologiedomänen von Google Distributed Cloud erstellen. Für die Verwendung von Topologiedomains ist Google Distributed Cloud Version 1.31 oder höher erforderlich.

Zum Einrichten einer Topologiedomain müssen Sie Erweiterter Cluster aktivieren.

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 primären Schritte 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 Nutzercluster-Konfigurationsdatei 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 Ihre Administrator-Workstation mit gkeadm erstellt haben, hat gkeadm eine Vorlage für die Konfigurationsdatei Ihres 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.36.200-gke.118.

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.200-gke.118.

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 vSphere-Infrastrukturkonfigurationsdatei pro Topologiedomain.

network

  • Entfernen Sie Folgendes aus der Konfigurationsdatei:

    • Den gesamten Abschnitt network.hostConfig. Diese Informationen werden in der vSphere-Infrastrukturkonfigurationsdatei pro Topologiedomain konfiguriert.
    • Das Feld network.vCenter.networkName. Dieses Feld wird in der vSphere-Infrastrukturkonfigurationsdatei pro Topologiedomain konfiguriert.
    • Den gesamten Abschnitt network.controlPlaneIPBlock. Die IP-Adressen für das Gateway, die Netzmaske 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 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 bereitgestellten Liste statischer Adressen in der IP-Blockdatei 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.

  • 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

  • Legen Sie eine VIP für den Kubernetes API-Server Ihres Nutzerclusters fest. Stellen Sie die VIP als Wert für loadBalancer.vips.controlPlaneVIP bereit.

  • Reservieren Sie eine weitere VIP für den Dienst für eingehenden Traffic Ihres Nutzerclusters. Stellen Sie die VIP als Wert für loadBalancer.vips.ingressVIP bereit.

  • Legen Sie loadBalancer.kind auf "ManualLB" fest und füllen Sie den Abschnitt manualLB aus. Weitere Informationen finden Sie unter Manuelles Load-Balancing.

advancedNetworking

Wenn Sie ein NAT-Gateway für ausgehenden Traffic erstellen 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 Nutzerclusters angeben möchten, füllen Sie die Felder cpus und memoryMB im Abschnitt masterNode aus.

  • Es werden nur Cluster mit Hochverfügbarkeit unterstützt. Setzen Sie das Feld replicas auf 3, um anzugeben, dass der Cluster drei Knoten der Steuerungsebene hat.

  • 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 können 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 Knotenpool, den Sie angeben:

  • Geben Sie im 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. Diese Informationen geben Sie in der vSphere-Infrastrukturkonfigurationsdatei pro Topologiedomain an.

  • Legen Sie den Wert nodePools[i].osImageType auf ubuntu_cgv2 fest.

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

antiAffinityGroups

Legen Sie antiAffinityGroups.enabled auf false fest. Anti-Affinitätsregeln für Distributed Resource Scheduler (DRS) werden mit Topologiedomänen 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 Google Cloud -Region muss der in cloudAuditLogging.clusterLocation und gkeConnect.location entsprechen. 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 zur Verwaltung des Clusterlebenszyklus für Cluster, die Topologiedomänen verwenden. Die Google Cloud Console, die Google Cloud CLI und Terraform werden für Cluster mit Topologiedomänen zwar nicht 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 GKE On-Prem API in der Region registriert, die in stackdriver.clusterLocation konfiguriert 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 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.

schedulerConfiguration

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

Beispiel für ausgefüllte Konfigurationsdateien

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

user-ipblock.yaml

blocks:
  - netmask: 255.255.255.0
    gateway: 172.16.21.1
    ips:
    - ip: 172.16.21.2
      hostname: worker-vm-1
    - ip: 172.16.21.3
      hostname: worker-vm-2
    - ip: 172.16.21.4
      hostname: worker-vm-3
    - ip: 172.16.21.5
      hostname: worker-vm-4
  - 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.200-gke.118
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 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 das Flag isControlPlane: true.

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

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

  • 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 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 die IP-Adressen für das Gateway, die Netzmaske und die Knoten der Steuerungsebene zur IP-Blockdatei 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) erstellen möchten, 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" festgelegt ist, fügen Sie die IP-Adressen für die Worker-Knoten der IP-Blockdatei 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 vSphere-Infrastruktur-Konfigurationsdatei 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

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

NAME
my-user-cluster

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

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

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

kubectl get nodes --kubeconfig USER_CLUSTER_KUBECONFIG

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

Die Ausgabe zeigt die Knoten des Nutzerclusters. 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 Labels von Knoten in der Topologiedomain eingefügt. Wenn in Ihrer Topologiedomäneneinrichtung 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 der PodTemplate geben Sie den Schlüssel als Wert für das Feld topologySpreadConstraints.topologyKey an. So kann der Kubernetes-Planer Pods auf die Topologiedomain verteilen, um Hochverfügbarkeit zu gewährleisten und im Falle eines Ausfalls eine zu starke Konzentration in einem einzelnen Bereich zu verhindern.

Fehlerbehebung

Siehe Fehlerbehebung beim Erstellen und Upgraden von Clustern.

Nächste Schritte