Skalierbarkeit

Auf dieser Seite werden Best Practices für das Erstellen, Konfigurieren und Ausführen von GKE on VMware-Clustern für Arbeitslasten beschrieben, die sich den Skalierbarkeitslimits von Kubernetes nähern.

Regeln für Clusternamen

Für die einzelnen Google Cloud-Projekte gilt:

  • Jeder Nutzercluster muss innerhalb aller Administratorcluster eines Google Cloud-Projekts einen eindeutigen Namen haben.

Skalierbarkeitslimits

Beachten Sie beim Entwerfen Ihrer Anwendungen in GKE on VMware die folgenden Limits:

Informationen zu Limits

Da GKE on VMware ein komplexes System mit einer großen Integrationsfläche ist, umfasst die Skalierbarkeit des Clusters viele miteinander verbundene Dimensionen. Beispielsweise kann GKE on VMware durch die Anzahl der Knoten, Pods oder Dienste skaliert werden. Das Erweitern mehrerer Dimensionen gleichzeitig kann auch in kleineren Clustern Probleme verursachen. Wenn Sie beispielsweise 110 Pods pro Knoten in einem 500-Knotencluster planen, kann die Anzahl der Pods, Pods pro Knoten und Knoten überlastet werden.

Weitere Informationen finden Sie unter Kubernetes-Skalierbarkeitsschwellenwerte.

Die Skalierbarkeitslimits gelten auch für die vSphere-Konfiguration und -Hardware, auf der Ihr Cluster ausgeführt wird. Diese Limits werden in einer Umgebung geprüft, die sich von Ihrer unterscheidet. Daher können Sie die genauen Zahlen nicht reproduzieren, wenn die zugrunde liegende Umgebung den begrenzenden Faktor darstellt.

Skalierung vorbereiten

Berücksichtigen Sie bei der Vorbereitung der Skalierung von Administratorclustern oder Nutzerclustern die folgenden Anforderungen und Einschränkungen.

CPU-, Arbeitsspeicher- und Speicheranforderungen

CPU-, RAM- und Speicheranforderungen für jede einzelne VM

Laufwerk-/Netzwerk-E/A-Anforderungen

Datenintensive Arbeitslasten und bestimmte Komponenten der Steuerungsebene sind empfindlich auf Laufwerk-/Netzwerk-E/A-Latenz. Zum Beispiel sind normalerweise 500 sequentielle IOPS (z. B. eine typische lokale SSD oder ein virtualisiertes Blockgerät mit hoher Leistung) erforderlich, um die Leistung und Stabilität von etcd in einem Cluster mit Dutzenden Knoten und Tausenden von Pods zu verbessern, um die Option zu aktivieren.

Knoten-IP-Adresse

Jeder GKE on VMware-Knoten erfordert eine DHCP- oder statisch zugewiesene IP-Adresse.

Zum Beispiel sind 308 IP-Adressen für einen Nicht-HA-Nutzercluster mit 50 Knoten und einem HA-Nutzercluster mit 250 Knoten erforderlich.

In der folgenden Tabelle sind die IP-Adressen aufgeschlüsselt:

Knotentyp Anzahl der IP-Adressen
VM der Administratorcluster-Steuerungsebene 1
Add-on-Knoten-VMs im Administratorcluster 3
Steuerungsebene-VM des Nutzercluster 1 (Nicht-HA) 1
Knoten-VMs des Nutzercluster 1 50
Steuerungsebenen-VMs des Nutzer-Cluster 2 (HA) 3
Knoten-VMs des Nutzercluster 2 250
Summe 308

Viele Nutzercluster in einem Administratorcluster ausführen

Wenn Sie viele Nutzercluster in einem Administratorcluster ausführen möchten, führen Sie beim Erstellen des Administratorclusters folgende Schritte aus.

Pod-CIDR-Block im Administratorcluster

Der Pod-CIDR-Block ist der CIDR-Block für alle Pods in einem Administratorcluster. Es wird über das Feld network.podCIDR in admin-cluster.yaml konfiguriert.

Aus diesem Bereich werden jedem Knoten kleinere /24-Blöcke zugewiesen. Wenn Sie einen Cluster mit N Knoten benötigen, müssen Sie darauf achten, dass dieser Block groß genug ist, um N /24-Blöcke zu unterstützen.

In der folgenden Tabelle wird die maximale Anzahl an Knoten beschrieben, die von verschiedenen Pod-CIDR-Blockgrößen unterstützt werden:

CIDR-Blockgröße des Pods Maximale Anzahl der unterstützten Knoten
/18 64
/17 128
/16 256
/15 512

Der standardmäßige Pod-CIDR-Block eines Administratorclusters ist 192.168.0.0/16, der 256 Knoten unterstützt.

In einem Administratorcluster mit 100 HA-Nutzerclustern (jeder Nutzercluster hat drei Knoten für Steuerungsebenen) gibt es einen Knoten für die Administrator-Steuerungsebene, zwei Administrator-Add-on-Knoten und 300 Knoten-Steuerungsebenen für Nutzercluster. Die Gesamtzahl der Knoten beträgt 303 (mehr als 256). Daher müssen Sie den Pod-CIDR-Block auf /15 aktualisieren, um bis zu 100 HA-Nutzercluster zu unterstützen.

Zum Konfigurieren des Pod-CIDR-Blocks legen Sie das Feld network.podCIDR in der Konfigurationsdatei des Administratorclusters fest.

Dienst-CIDR-Block im Administratorcluster

Der Dienst-CIDR-Block ist der CIDR-Block für alle Dienste in einem Administratorcluster. Es wird über das Feld network.serviceCIDR in admin-cluster.yaml konfiguriert.

In der folgenden Tabelle wird die maximale Anzahl von Diensten erläutert, die von unterschiedlichen Dienst-CIDR-Blockgrößen unterstützt werden:

Dienst-CIDR-Blockgröße Maximale Anzahl unterstützter Dienste
/24 256
/23 512
/22 1.024

Der Standardwert ist 10.96.232.0/24, welcher 256 Dienste unterstützt.

Jeder Nutzercluster verwendet 6 Dienste und die Steuerungsebene des Administratorclusters verwendet 14 Dienste. Um 100 Nutzercluster auszuführen, müssen Sie den Dienst-CIDR-Block im Administratorcluster ändern, um einen Bereich von /22 zu verwenden.

Cloud Logging und Cloud Monitoring

Mit Cloud Logging und Cloud Monitoring können Sie Ihre Ressourcen verfolgen.

Die CPU- und Arbeitsspeichernutzung der Logging- und Monitoring-Komponenten, die in einem Administratorcluster bereitgestellt werden, entsprechend der Anzahl der Nutzercluster.

In der folgenden Tabelle werden die Menge an CPU-Kapazität und Speicher im Administratorcluster beschrieben, die zum Ausführen einer großen Anzahl von Nutzerclustern erforderlich sind:

Anzahl der Nutzercluster CPU des Administratorclusterknotens Arbeitsspeicher des Administratorclusterknotens
0 bis 10 4 CPUs 16 GB
11 bis 20 4 CPUs 32 GB
20 bis 100 4 CPUs 90 GB

Wenn beispielsweise zwei Administratorcluster-Knoten vorhanden sind und jeder 4 CPUs und 16 GB Arbeitsspeicher hat, können Sie 0 bis 10 Nutzercluster ausführen. Um mehr als 20 Nutzercluster zu erstellen, müssen Sie zuerst die Größe des Administratorclusterknotens von 16 GB auf 90 GB anpassen.

Bearbeiten Sie die MachineDeployment-Konfiguration, um den Arbeitsspeicher des Add-on-Knotens für den Administratorcluster zu ändern:

  1. Führen Sie dazu diesen Befehl aus:

    kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG edit machinedeployment gke-admin-node

    Dabei ist ADMIN_CLUSTER_KUBECONFIG der Pfad der kubeconfig-Datei Ihres Admin-Clusters.

  2. Ändern Sie das Feld spec.template.spec.providerSpec.value.machineVariables.memory in 32768.

  3. Speichern Sie die Änderung. Die Administratorclusterknoten werden mit 32 GB Speicher neu erstellt.

GKE Hub

Standardmäßig können Sie maximal 15 Nutzercluster registrieren.

Für die Registrierung weiterer Cluster in GKE Hub können Sie über die Google Cloud Console eine Anfrage zur Erhöhung Ihres Kontingents stellen:

 [Go to Quotas](https://console.cloud.google.com/apis/api/gkehub.googleapis.com/quotas){: target="console"
 class="button button-primary" track-type="quotas" track-name="consoleLink" track-metadata-end-goal="modifyQuota"}

Viele Knoten und Pods in einem Nutzercluster ausführen

Führen Sie bei der Erstellung vieler Knoten und Pods in einem Nutzercluster die folgenden Schritte aus, wenn Sie den Nutzercluster erstellen.

Pod-CIDR-Block im Nutzercluster

Der Pod-CIDR-Block ist der CIDR-Block für alle Pods in einem Nutzercluster. Es wird über das Feld network.podCIDR in user-cluster.yaml konfiguriert.

Aus diesem Bereich wird jedem Knoten ein kleinerer /24-Block zugewiesen. Wenn Sie einen Cluster mit N Knoten benötigen, müssen Sie darauf achten, dass dieser Block groß genug ist, um N /24-Blöcke zu unterstützen.

In der folgenden Tabelle wird die maximale Anzahl an Knoten beschrieben, die von verschiedenen Pod-CIDR-Blockgrößen unterstützt werden:

CIDR-Blockgröße des Pods Maximale Anzahl der unterstützten Knoten
/18 64
/17 128
/16 256
/15 512

Der Standard-CIDR-Block des Pods ist 192.168.0.0/16 mit 256 Knoten. Wenn Sie beispielsweise einen Cluster mit 500 Knoten erstellen möchten, müssen Sie den Pod-CIDR-Block im Nutzercluster ändern, um einen 15-Bereich zu verwenden.

Dienst-CIDR-Block im Nutzercluster

Der Dienst-CIDR-Block ist der CIDR-Block für alle Dienste in einem Nutzercluster. Es wird über das Feld network.serviceCIDR in user-cluster.yaml konfiguriert.

In der folgenden Tabelle wird die maximale Anzahl von Diensten erläutert, die von unterschiedlichen Dienst-CIDR-Blockgrößen unterstützt werden:

Dienst-CIDR-Blockgröße Maximale Anzahl unterstützter Dienste
/21 2.048
/20 4.096
/19 8.192
/18 16.384

Der Standardwert ist 10.96.0.0/20, welcher 4.096 Dienste unterstützt. Mit dem standardmäßigen Dienst-CIDR-Block können Sie einen Cluster mit 500 Diensten erstellen. Dies ist die maximale Anzahl der Dienste vom Typ LoadBalancer, die GKE on VMware in einem Nutzercluster unterstützt.

Knoten für die Steuerungsebene des Nutzerclusters

Die Arbeitsspeichernutzung der Komponenten der Steuerungsebene des Nutzerclusters wird nach der Anzahl der Knoten im Nutzercluster skaliert.

In der folgenden Tabelle ist die CPU- und Arbeitsspeicherkapazität angegeben, die der Steuerungsebenenknoten des Nutzerclusters je nach Größe des Nutzerclusters benötigt:

Anzahl an Nutzerclusterknoten CPU des Steuerungsebenenknotens Arbeitsspeicher des Steuerungsebenenknotens
0 bis 20 3 CPUs 5 GB
21 bis 75 3 CPUs 6 GB
76 bis 250 4 CPUs 8 GB
251 bis 500 4 CPUs 16 GB

Wenn Sie beispielsweise mehr als 250 Knoten in einem Nutzercluster erstellen möchten, müssen Sie Knoten für die Nutzercluster-Steuerungsebene mit mindestens 16 GB Arbeitsspeicher verwenden.

Die Knotenspezifikation der Nutzercluster-Steuerungsebene kann in user-cluster.yaml im Feld masterNode geändert werden.

Dataplane V2

Für Nutzercluster mit 500 Knoten, die Dataplan V2 verwenden, empfehlen wir 120 GB Arbeitsspeicher und 32 CPU-Kerne für die Knoten der Steuerungsebene des Nutzerclusters.

Cloud Logging und Cloud Monitoring

Mit Cloud Logging und Cloud Monitoring können Sie Ihre Ressourcen verfolgen.

Die CPU- und Arbeitsspeichernutzung der In-Cluster-Agents, die in einem Nutzercluster bereitgestellt werden, skaliert anhand der Anzahl der Knoten und Pods in einem Nutzercluster.

Cloud Logging- und Monitoring-Komponenten wie prometheus-server und stackdriver-prometheus-sidecar haben unterschiedliche CPU- und Speicherressourcennutzung, die auf der Anzahl der Knoten und der Anzahl der Pods basieren. Bevor Sie den Cluster hochskalieren, müssen Sie die Ressourcenanfrage und das Ressourcenlimit gemäß der geschätzten durchschnittlichen Nutzung dieser Komponenten festlegen. In der folgenden Tabelle sehen Sie Schätzungen für die durchschnittliche Nutzung pro Komponente:

Anzahl der Knoten Containername Geschätzte CPU-Auslastung Geschätzte Speichernutzung
0 Pods/Knoten 30 Pods/Knoten 0 Pods/Knoten 30 Pods/Knoten
3 to 50 prometheus-server 100 m 390 m 650 m 1,3 G
stackdriver-prometheus-sidecar 100 m 340 m 1,5 G 1,6 G
51 bis 100 prometheus-server 160m 500m 1,8 G 5,5 G
stackdriver-prometheus-sidecar 200m 500m 1,9G 5,7G
101 bis 250 prometheus-server 400m 2500m 6,5 G 16G
stackdriver-prometheus-sidecar 400m 1300m 7,5G 12G
250 auf 500 prometheus-server 1200 Mio. 2600 Mio. 22G 25G
stackdriver-prometheus-sidecar 400m 2250 Mio. 65G 78G

Achten Sie darauf, dass Ihre Knoten groß genug sind, um die Komponenten von Cloud Logging und Cloud Monitoring zu planen. Eine Möglichkeit besteht darin, zuerst einen kleinen Cluster zu erstellen. Bearbeiten Sie dazu zuerst die Cloud Logging- und Cloud Monitoring-Komponentenressourcen gemäß der obigen Tabelle und erstellen Sie einen Knotenpool, um die Komponenten aufzunehmen. und hochskaliert dann den Cluster schrittweise zu vergrößern.

Sie können einen Knotenpool für die Monitoring- und Logging-Komponenten so groß halten, dass keine anderen Pods in dem Knotenpool geplant werden. Dazu müssen Sie dem Knotenpool die folgenden Holdts hinzufügen:

taints:
  - effect: NoSchedule
    key: node-role.gke.io/observability

Dadurch wird verhindert, dass andere Komponenten für den Knotenpool geplant werden und Nutzerarbeitslasten nicht aufgrund des Ressourcenverbrauchs der Monitoring-Komponenten entfernt werden.

Load-Balancer

Die in diesem Abschnitt beschriebenen Dienste beziehen sich auf die Kubernetes-Dienste mit dem Typ „Load-Balancer“.

Die Anzahl der Knoten in Ihrem Cluster und die Anzahl der Dienste, die Sie auf dem Load-Balancer konfigurieren können, sind begrenzt.

Für das gebündelte Load-Balancing (Seesaw) gibt es außerdem ein Limit für die Anzahl der Systemdiagnosen. Die Anzahl der Systemdiagnosen hängt von der Anzahl der Knoten und der Anzahl der lokalen Dienste des Traffics ab. Ein lokaler Trafficdienst ist ein Dienst, dessen externalTrafficPolicy auf Local gesetzt ist.

Die folgende Tabelle beschreibt die maximale Anzahl von Diensten, Knoten und Systemdiagnosen für das gebündelte Load-Balancing (Seesaw) und das integrierte Load-Balancing (F5):

Gebündeltes Load-Balancing (Seesaw) Integriertes Load-Balancing (F5)
Maximale Anzahl von Diensten 500 250 2
Maximale Anzahl von Knoten 500 250 2
Maximale Systemdiagnosen N + (L * N) <= 10K, wobei N die Anzahl der Knoten und L die Anzahl der lokalen Dienste des Traffics ist 1 N/A 2

1 Angenommen, Sie haben 100 Knoten und 99 lokale Trafficdienste. Die Anzahl der Systemdiagnosen liegt bei 100 + (99 * 100) = 10.000, welche innerhalb des Limits von 10.000 liegt.

2 Weitere Informationen erhalten Sie unter F5. Diese Zahl hängt von Faktoren wie der F5-Hardware-Modellnummer, der CPU- bzw. Speicherkapazität der virtuellen Instanz und den Lizenzen ab.

Systemkomponenten mit automatischer Skalierung

GKE on VMware skaliert die Systemkomponenten in Nutzerclustern automatisch entsprechend der Anzahl der Knoten, ohne dass Sie die Konfigurationen ändern müssen. Die Informationen in diesem Abschnitt können Sie für die Ressourcenplanung verwenden.

  • GKE on VMware führt automatisch eine vertikale Skalierung durch, indem die CPU- und Arbeitsspeicheranfragen/-limits der folgenden Systemkomponenten mithilfe von addon-resizer skaliert werden:

    • kube-state-metrics ist ein Deployment, das auf Cluster-Worker-Knoten ausgeführt wird, die den Kubernetes API-Server überwachen und Messwerte zum Status der Objekte generieren. Die CPU- und Speicheranforderungen und die Skalierung werden basierend auf der Anzahl der Knoten skaliert.

      In der folgenden Tabelle werden die Ressourcenanforderungen/-limits beschrieben, die vom System festgelegt werden, unter Berücksichtigung der Anzahl der Knoten in einem Cluster:

      Anzahl der Knoten Ungefähre1 CPU-Anfrage/Limit (Milli) Ungefähre1 Speicheranfrage/Limit (Mi)
      3 bis 5 105 110
      6 auf 500 100 + num_nodes 100 + (2 * num_nodes)

      1 Es gibt einen Rand von +-5 %, um die Anzahl der Komponentenneustarts während der Skalierung zu verringern.

      Beispiel: In einem Cluster mit 50 Knoten ist die CPU-Anfrage/-grenze auf 150 m/150 Min. und die Speicheranforderung/-grenze auf 200 Mi/200Mi eingestellt. In einem Cluster mit 250 Knoten wird die CPU-Anfrage/-grenze auf 350 m/350 m festgelegt und die Speicheranforderung/-grenze auf 600 Mi.

    • metrics-server ist eine Bereitstellung, die auf Cluster-Worker-Knoten ausgeführt wird, die von integrierten Kubernetes-Autoscaling-Pipelines verwendet werden. Die CPU- und Speicheranforderungen und die Skalierung werden basierend auf der Anzahl der Knoten skaliert.

  • GKE on VMware führt automatisch horizontale Skalierungen sowohl in Administrator- als auch in Nutzerclustern durch. Dazu wird die Anzahl der Replikate der folgenden Systemkomponenten skaliert:

    • core-dns ist die DNS-Lösung, die für die Diensterkennung in GKE on VMware verwendet wird. Sie wird als Deployment auf Nutzercluster-Worker-Knoten ausgeführt. GKE on VMware skaliert die Anzahl der Replikate automatisch entsprechend der Anzahl der Knoten und CPU-Kerne im Cluster. Mit jedem Hinzufügen/Löschen von 16 Knoten oder 256 Kernen wird 1 Replikat erhöht/verringert. Wenn Sie einen Cluster mit N Knoten und C Kernen haben, können Sie max(N/16, C/256)-Replikate erwarten.

    • calico-typha ist eine Komponente zur Unterstützung von Pod-Netzwerken in GKE on VMware. Sie wird als Deployment auf Nutzercluster-Worker-Knoten ausgeführt. GKE on VMware skaliert die Anzahl der Calico-Typha-Replikate automatisch anhand der Anzahl der Knoten im Cluster:

      Anzahl der Knoten (N) Anzahl der calico-typha-Replikate
      N = 1 1
      1 < N < 200 2
      N >= 200 Mindestens drei

    • Das Istio Ingress Gateway ist die Komponente zur Unterstützung von Cluster-Ingress und wird als Deployment auf Worker-Knoten des Nutzerclusters ausgeführt. Abhängig von der Menge des vom Ingress-Gateway verarbeiteten Traffics verwendet GKE on VMware horizontales Pod-Autoscaling, um die Anzahl der Replikate anhand ihrer CPU-Nutzung zu skalieren. Dabei sind mindestens 2 und maximal 5 Replikate erforderlich.

    • Der konnectivity-Netzwerkproxy (KNP) bietet einen TCP-Proxy für den ausgehenden Traffic von Knoten der Nutzercluster-Steuerungsebene. Er leitet den ausgehenden kube-apiserver-Traffic des Nutzers weiter, der an die Knoten des Nutzerclusters gerichtet ist. Der Konnectivity-Agent wird als Deployment auf Nutzercluster-Worker-Knoten ausgeführt. GKE on VMware skaliert die Anzahl der Konnectivity-Agent-Replikate automatisch anhand der Anzahl der Knoten im Cluster.

      Anzahl der Knoten (N) Anzahl der Replikate des konnectivity-Agents
      1 <= N <= 6 ✘
      6 < N < 10 6
      10 <= N < 100 8
      N >= 100 Mindestens 12

Best Practices

In diesem Abschnitt werden Best Practices zur Skalierung Ihrer Ressourcen beschrieben.

Cluster schrittweise skalieren

Beim Erstellen eines Kubernetes-Knotens wird die Image-Vorlage des Knotenbetriebssystems in eine neue Laufwerksdatei kopiert. Dabei handelt es sich um einen E/A-intensiven vSphere-Vorgang. Es gibt keine E/A-Isolation zwischen dem Klonvorgang und den E/A-Vorgängen der Arbeitslast. Wenn zu viele Knoten gleichzeitig erstellt werden, dauert der Klonvorgang lange, was die Leistung und Stabilität des Clusters und der vorhandenen Arbeitslasten beeinträchtigen kann.

Achten Sie darauf, dass der Cluster in Abhängigkeit von Ihren vSphere-Ressourcen skaliert wird. Wenn Sie beispielsweise die Größe eines Clusters von 3 auf 500 Knoten ändern möchten, sollten Sie ihn in Phasen von 150 auf 350 bis 500 skalieren, um die Last der vSphere-Infrastruktur zu reduzieren.

E/A-Leistung von etcd-Laufwerk optimieren

etcd ist ein Schlüssel/Wert-Speicher, der als Sicherungsspeicher von Kubernetes für alle Clusterdaten verwendet wird. Die Leistung und Stabilität sind für den Zustand eines Clusters von entscheidender Bedeutung und hängen von der E/A-Latenz des Laufwerks und des Netzwerks ab.

  • Optimieren Sie die E/A-Leistung des vSphere-Datenspeichers, der für die VMs auf Steuerungsebene verwendet wird. Beachten Sie dabei die folgenden Empfehlungen:

  • Die Latenz von einigen hundert Millisekunden weist auf einen Engpass auf dem Laufwerk oder der E/A des Netzwerks zu. Dies kann zu einem fehlerhaften Cluster führen. Benachrichtigungsschwellen für die folgenden etcd-E/A-Latenzmesswerte überwachen und festlegen:

    • etcd_disk_backend_commit_duration_seconds
    • etcd_disk_wal_fsync_duration_seconds

E/A-Leistung von Knoten-Bootlaufwerk optimieren

Pods verwenden für ihre internen Vorgänge einen sitzungsspezifischen Speicher, z. B. zum Speichern temporärer Dateien. Flüchtiger Speicher wird von der beschreibbaren Ebene des Containers, dem Logverzeichnis und den emptyDir-Volumes belegt. Der sitzungsspezifische Speicher stammt aus dem Dateisystem des GKE on VMware-Knotens, das vom Bootlaufwerk des Knotens unterstützt wird.

Da auf Kubernetes-Knoten keine Speicher-E/A-Isolierung vorhanden ist, können Anwendungen, die bei ihrem flüchtigen Speicher extrem hohe E/A-Vorgänge verbrauchen, zu Knoteninstabilität führen, indem sie Systemkomponenten wie Kubelet und den Docker-Daemon von Ressourcen.

Prüfen Sie, ob die E/A-Leistungsmerkmale des Datenspeichers, auf denen die Bootlaufwerke bereitgestellt werden, die richtige Leistung für die Verwendung von flüchtigem Speicher und Logging-Traffic bieten.

Konflikte mit physischen Ressourcen überwachen

Achten Sie auf vCPUs und pCPU-Verhältnisse und Speicherüberlastung. Ein suboptimales Verhältnis oder Speicherkonflikte bei den physischen Hosts können die VM-Leistung beeinträchtigen. Sie sollten die physische Ressourcennutzung auf Hostebene überwachen und genügend Ressourcen für die Ausführung großer Cluster zuweisen.