Skalierbarkeit

Auf dieser Seite werden Best Practices zum Erstellen, Konfigurieren und Betreiben von Google Distributed Cloud-Clustern beschrieben, um Arbeitslasten zu berücksichtigen, die sich den Skalierbarkeitslimits von Kubernetes annä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 Integrationsoberfläche ist, umfasst die Skalierbarkeit von Clustern viele zusammengehörige Dimensionen. GKE on VMware kann beispielsweise über die Anzahl der Knoten, Pods oder Dienste skalieren. 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 werden Sie möglicherweise nicht die genauen Zahlen reproduzieren, wenn die zugrunde liegende Umgebung der begrenzende Faktor ist.

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 benötigt eine DHCP- oder statisch zugewiesene IP-Adresse.

Beispielsweise sind in einer Einrichtung mit einem Nicht-HA-Nutzercluster mit 50 Knoten und einem Hochverfügbarkeits-Nutzercluster mit 250 Knoten 307 IP-Adressen erforderlich.

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

Knotentyp Anzahl der IP-Adressen
VMs der Steuerungsebene des Administratorclusters 3
Steuerungsebene-VM des Nutzercluster 1 (Nicht-HA) 1
VMs von Nutzercluster 1 mit Worker-Knoten 50
Steuerungsebenen-VMs des Nutzer-Cluster 2 (HA) 3
VMs von Nutzercluster 2 mit Worker-Knoten 250
Summe 307

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 für alle Nutzercluster die Steuerungsebene V2 aktiviert ist, hat Ihr Administratorcluster nur drei Knoten und es sind viele Pod-IP-Adressen verfügbar. Jedes Mal, wenn Sie jedoch einen Nutzercluster erstellen, der kubeception anstelle von Steuerungsebene V2 verwendet, werden dem Administratorcluster ein oder drei Knoten hinzugefügt:

  • Jeder kubeception-Nutzercluster mit Hochverfügbarkeit fügt dem Administratorcluster drei Knoten hinzu.

  • Jeder kubeception-Nutzercluster ohne Hochverfügbarkeit fügt dem Administratorcluster einen Knoten hinzu.

Wenn Sie einen Administratorcluster mit N Knoten benötigen, müssen Sie darauf achten, dass der Pod-CIDR-Block N /24-Blöcke unterstützt.

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 kubeception-Nutzerclustern für Hochverfügbarkeit gibt es 3 Knoten für die Administratorcluster-Steuerungsebene und 300 Knoten für die Nutzercluster-Steuerungsebene. 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-kubeception-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 kubeception-Nutzercluster verwendet 6 Dienste und die Steuerungsebene des Administratorclusters 14 Dienste. Wenn Sie 100 kubeception-Nutzercluster ausführen möchten, müssen Sie daher den Dienst-CIDR-Block im Administratorcluster so ändern, dass ein /22-Bereich verwendet wird.

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, skaliert entsprechend der Anzahl der kubeception-Nutzercluster.

In der folgenden Tabelle werden die CPU- und Arbeitsspeichermenge für Administratorclusterknoten beschrieben, die zum Ausführen einer großen Anzahl von kubeception-Nutzerclustern erforderlich sind:

Anzahl der kubeception-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 es beispielsweise 2 Administratorclusterknoten mit jeweils 4 CPUs und 16 GB Arbeitsspeicher gibt, können Sie 0 bis 10 kubeception-Nutzercluster ausführen. Wenn Sie mehr als 20 kubeception-Nutzercluster erstellen möchten, müssen Sie zuerst die Größe des Arbeitsspeichers des Knotenarbeitsspeichers des Administratorclusters von 16 GB auf 90 GB ändern.

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:

Kontingente aufrufen

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

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 sind die CPU und der Arbeitsspeicher aufgeführt, die für den Knoten der Steuerungsebene eines Nutzerclusters je nach Größe des Nutzerclusters erforderlich sind:

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 von 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. Dabei werden die CPU- und Arbeitsspeicheranfragen/-limits der folgenden Systemkomponenten mithilfe von addon-resizer skaliert:

    • 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 eine horizontale Skalierung sowohl in Administrator- als auch in Nutzerclustern durch. Dabei 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

    • Istio Ingress-Gateway ist die Komponente zur Unterstützung von Cluster-Ingress und wird als Deployment auf Nutzercluster-Worker-Knoten ausgeführt. Abhängig von der Menge des vom eingehenden Traffic verarbeiteten Traffics verwendet GKE on VMware horizontales Pod-Autoscaling, um die Anzahl der Replikate basierend auf ihrer CPU-Nutzung mit mindestens zwei und maximal fünf Replikaten zu skalieren.

    • 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. Google Distributed Cloud skaliert die Anzahl der Replikate des Konnektivitäts-Agents 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. Sitzungsspezifischer 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.