Version 1.5

Skalierbarkeit

Auf dieser Seite werden Best Practices für das Erstellen, Konfigurieren und Ausführen von GKE On-Prem-Clustern beschrieben, um Arbeitslasten zu berücksichtigen, bei denen die Grenzwerte für die Kubernetes-Stabilität annähern.

Skalierbarkeitslimits

Beachten Sie beim Entwerfen Ihrer Anwendungen in GKE On-Prem die folgenden Limits:

  • Jeder Administratorcluster unterstützt bis zu 20 Nutzercluster, einschließlich Hochverfügbarkeitscluster und Hochverfügbarkeitscluster.

  • Jeder Nutzercluster unterstützt bis zu:

  • Für jeden Knoten können Sie maximal 110 Pods erstellen (jeder Pod kann aus 1–2 Containern bestehen). Dazu zählen auch Pods, auf denen Add-on-Dienste ausgeführt werden.

Informationen zu Limits

Da GKE On-Prem ein komplexes System mit einer großen Integrationsoberfläche ist, umfasst die Cluster-Skalierung viele miteinander verknüpfte Dimensionen. GKE On-Prem 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 250-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 überprü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 alle Anforderungen und Einschränkungen für vSphere-Infrastruktur, Kubernetes-Netzwerke, GKE Hub sowie Cloud Logging und Cloud Monitoring.

vSphere-Infrastruktur

In diesem Abschnitt werden Skalierbarkeitsaspekte für CPU-, Arbeitsspeicher-, Speicher-, Laufwerk- und Netzwerk-E/A-Anforderungen sowie Knoten-IP-Adressen erläutert.

CPU-, Arbeitsspeicher- und Speicheranforderungen

Für VMs der Steuerungsebene gelten die folgenden Anforderungen:

  • Die Steuerungsebene des Administratorclusters und die Add-on-Knoten können bis zu 20 Nutzercluster unterstützen, einschließlich HA- und Nicht-HA-Nutzercluster. Daher ist auf dem Administratorcluster keine Feinabstimmung erforderlich.

  • Die Standardkonfiguration der VM-Konfiguration für Nutzer-Clustersteuerung (4 CPUs, 8 GB Arbeitsspeicher und 40 GB Speicherplatz) ist für die Ausführung von bis zu 250 Knoten in einem Nutzercluster erforderlich.

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-Prem-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 Administrator-Clustersteuerungsebene 1
Knoten-VMs im Administratorcluster 3
Nutzercluster 1 (ohne HA-Steuerung) – Steuerungsebene-VM 1
Nutzercluster-Knoten-VMs 50
Nutzer-Cluster-Steuerungsebenen (HA) 3
Knoten-VMs für Nutzercluster 2 250
Summe 308

Kubernetes-Netzwerke

In diesem Abschnitt werden Überlegungen zur Skalierbarkeit für den Pod-CIDR-Block und die Kubernetes-Dienste erläutert.

Pod-CIDR-Block

Der Pod-CIDR-Block ist der CIDR-Block für alle Pods in einem Nutzercluster. Aus diesem Bereich werden jedem Knoten kleinere /24-Blöcke zugewiesen. Wenn Sie einen Cluster mit N Knoten benötigen, muss dieser Block groß sein, 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
/19 32
/18 64
/17 128
/16 256

Der Standard-CIDR-Block des Pods ist 192.168.0.0/16 mit 256 Knoten. Mit dem standardmäßigen Pod-CIDR-Block können Sie einen Cluster mit 250 Knoten erstellen. Dies ist die maximale Anzahl von Knoten, die GKE On-Prem in einem Nutzercluster unterstützt.

Kubernetes-Dienste

In diesem Abschnitt werden Überlegungen zur Skalierbarkeit für den Dienst-CIDR-Block und den Load-Balancer erläutert.

Dienst-CIDR-Block

Der Dienst-CIDR-Block ist der CIDR-Block für alle Dienste in einem Nutzercluster. Die in diesem Abschnitt beschriebenen Dienste beziehen sich auf die Kubernetes-Dienste mit dem Typ "LoadBalancer".

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
/20 4.096
/19 8.192
/18 16.384

Der Standardwert ist 10.96.0.0/12, was 1.048.576 Dienste unterstützt. Mit dem standardmäßigen Dienst-CIDR-Block können Sie einen Cluster mit 500 Diensten erstellen. Dies ist die maximale Anzahl von Diensten, die GKE On-Prem in einem Nutzercluster unterstützt.

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 Knotenanzahl 250 250 2
Maximale Systemdiagnosen N + (L * N) <= 10K, wobei N die Anzahl der Knoten und L die Anzahl der lokalen Dienste des Traffics ist1 N/A 2

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

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

GKE Hub

Standardmäßig können Sie maximal 15 Nutzercluster registrieren. Für die Registrierung weiterer Cluster im GKE Hub können Sie über die Cloud Console eine Anfrage zur Erhöhung des Kontingents senden.

Cloud Logging und Cloud Monitoring

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

Viele Knoten in einem Nutzercluster ausführen

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, stackdriver-prometheus-sidecar und stackdriver-log-aggregator 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 bis 50 stackdriver-log-aggregator 150 m 170 m 1,6 G 1,7 G
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 stackdriver-log-aggregator 220m 1100m 1,6 G 1,8 G
Prometheus-Server 160m 500m 1,8 G 5,5 G
stackdriver-prometheus-sidecar 200m 500m 1,9G 5,7G
101 bis 250 stackdriver-log-aggregator 450m 1800m 1,7 G 1,9G
Prometheus-Server 400m 2500m 6,5 G 16G
stackdriver-prometheus-sidecar 400m 1300m 7,5G 12G

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.

Viele Nutzercluster in einem Administratorcluster ausführen

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

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 10 Nutzercluster zu erstellen, müssen Sie zuerst die Größe des Administratorclusterknotens von 16 GB auf 32 GB anpassen.

Bearbeiten Sie die MachineDeployment-Konfiguration, um den Arbeitsspeicher des Administratorclusterknotens 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.

Systemkomponenten mit automatischer Skalierung

GKE On-Prem 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.

  • GKE On-Prem 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 unter Berücksichtigung der Anzahl von Knoten in einem Cluster festgelegt werden:

      Anzahl der Knoten Ungefähr1 CPU-Anfrage/-Limit (Milli) Ungefähre1 Speicheranforderung/-grenze (Mi)
      3 bis 5 105 110
      6 bis 250 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.

  • GKE On-Prem führt automatisch eine horizontale Skalierung durch Skalierung der Anzahl der Replikate der folgenden Systemkomponenten durch:

    • kube-dns ist die DNS-Lösung, die zur Diensterkennung in GKE On-Prem verwendet wird. Es wird als Deployment auf Worker-Knoten von Nutzerclustern ausgeführt. GKE On-Prem 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 maximale Replikate(N/16, C/256) erwarten. Beachten Sie, dass kube-dns seit GKE On-Prem 1.4 aktualisiert wurde, um 1.500 gleichzeitige Anfragen pro Sekunde zu unterstützen.

    • calico-typha ist eine Komponente zur Unterstützung von Pod-Netzwerken in GKE On-Prem. Es wird als Deployment auf Worker-Knoten von Nutzerclustern ausgeführt. GKE On-Prem skaliert die Anzahl der Replikate automatisch basierend auf der Anzahl der Knoten im Cluster. Es gibt ein Replikat von Calico-typha in einem Cluster mit weniger als 200 Knoten und zwei Replikaten in einem Cluster mit 200 oder mehr Knoten.

    • ingress-gateway/istio-pilot sind die Komponenten zur Unterstützung von eingehendem Cluster-Ingress und werden als Deployment auf den Worker-Knoten des Nutzer-Deployments ausgeführt. Je nach der verarbeiteten Traffic-Ingress-Bereitstellung verwendet GKE On-Prem horizontales Pod-Autoscaling, um die Anzahl der Replikate basierend auf ihrer CPU-Auslastung mit mindestens 2 Replikate und maximal 5 Replikate.

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 250 Knoten ändern möchten, sollten Sie ihn in Phasen von 80 bis 160 bis 250 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. Leistung und Stabilität sind für den Zustand eines Clusters von entscheidender Bedeutung und hängen von der E/A-Latenz von Laufwerk und Netzwerk 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. Flüchtiger Speicher stammt aus dem Dateisystem des GKE On-Prem-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überschuss. 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.