Skalierbarkeit

Auf dieser Seite werden Best Practices für das Erstellen, Konfigurieren und Ausführen von Clustern beschrieben, die mit Google Distributed Cloud (nur Software) für VMware erstellt wurden, um Arbeitslasten zu berücksichtigen, die sich dem Kubernetes-Grenzwert für die Skalierbarkeit 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 die folgenden Limits:

Informationen zu Limits

Da die Distributed Cloud von Google ein komplexes System mit einer großen Integrationsoberfläche ist, umfasst die Cluster-Skalierung viele miteinander verknüpfte Dimensionen. Google Distributed Cloud kann beispielsweise 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 möglicherweise 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 Knoten benötigt eine DHCP- oder statisch zugewiesene IP-Adresse.

Zum Beispiel sind 307 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
VMs der Administratorcluster-Steuerungsebene 3
Steuerungsebene-VM des Nutzercluster 1 (Nicht-HA) 1
Worker-Knoten-VMs des Nutzerclusters 1 50
Steuerungsebenen-VMs des Nutzer-Cluster 2 (HA) 3
Worker-Knoten-VMs des Nutzerclusters 2 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 Ihre Nutzercluster Controlplane V2 aktiviert ist, hat Ihr Administratorcluster nur drei Knoten und es sind genügend Pod-IP-Adressen verfügbar. Jedes Mal, wenn Sie einen Nutzercluster erstellen, der kubeception anstelle der Steuerungsebene V2 verwendet, werden dem Administratorcluster ein oder drei Knoten hinzugefügt:

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

  • Jeder nicht hochverfügbare kubeception-Nutzercluster fügt dem Administratorcluster einen Knoten hinzu.

Wenn Sie einen Cluster mit N Knoten benötigen, müssen Sie darauf achten, dass der Pod-CIDR-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-Kubeception-Nutzerclustern gibt es drei Knoten für die Administrator-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 verwendet 14 Dienste. Um 100 kubeception-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 kubeception-Nutzercluster.

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

Anzahl der Nutzercluster von kubeception 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 kubeception-Nutzercluster ausführen. Um mehr als 20 kubeception-Nutzercluster zu erstellen, müssen Sie zuerst die Größe des Administratorclusterknotens von 16 GB auf 90 GB anpassen.

GKE Hub

Standardmäßig können Sie pro Flotte maximal 250 Cluster mit globalen Mitgliedschaften 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

Weitere Informationen zu Clusterkontingenten, die auf Mitgliedschaftseinstellungen basieren, finden Sie unter Zuteilungskontingente.

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 ist die CPU- und Arbeitsspeicherkapazität angegeben, die ein 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

Google Distributed Cloud skaliert die Systemkomponenten im Cluster automatisch entsprechend der Anzahl der Knoten, ohne dass Sie die Konfiguration ändern müssen. Die Informationen in diesem Abschnitt können Sie für die Ressourcenplanung verwenden.

  • Google Distributed Cloud führt vertikale Skalierungen automatisch durch, indem sie die CPU- und Speicheranforderungen/-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.

  • Google Distributed Cloud führt automatisch eine horizontale Skalierung in Administrator- und Nutzerclustern durch Skalierung der Anzahl der Replikate der folgenden Systemkomponenten durch:

    • core-dns ist die DNS-Lösung, die für die Diensterkennung verwendet wird. Sie wird als Deployment auf Nutzercluster-Worker-Knoten ausgeführt. Die Google Distributed Cloud 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. Sie wird als Deployment auf Nutzercluster-Worker-Knoten ausgeführt. Google Distributed Cloud skaliert die Anzahl der Calico-Typha-Replikate automatisch basierend auf 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 eingehendem Cluster-Ingress und wird als Deployment auf den Worker-Knoten von Nutzerclustern ausgeführt. Je nach Anzahl des verarbeiteten Ingressgateway-Traffics verwendet Google Distributed Cloud horizontales Pod-Autoscaling, um die Anzahl der Replikate basierend auf ihrer CPU-Auslastung mit mindestens 2 Replikate und maximal 5 Replikate 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 Konnektivitäts-Agent-Replikate automatisch basierend auf der Anzahl der Knoten im Cluster.

      Anzahl der Knoten (N) Anzahl der Replikate des konnectivity-Agents
      1 <= N <= 6 N
      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 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.