Vorteile großer GKE-Cluster
Für jedes Computersystem, einschließlich Kubernetes, gelten einige Architekturbeschränkungen. Das Überschreiten der Limits kann sich auf die Leistung Ihres Clusters auswirken oder in einigen Fällen sogar zu Ausfallzeiten führen. Befolgen Sie die Best Practices und führen Sie empfohlene Aktionen aus, damit Ihre Cluster Ihre Arbeitslasten zuverlässig in großem Maßstab ausführen.
Einschränkungen großer GKE-Cluster
Wenn GKE einen Cluster auf eine große Anzahl von Knoten skaliert, versucht GKE, die Menge der verfügbaren Ressourcen so zu ändern, dass sie den Anforderungen Ihres Systems entspricht, und gleichzeitig die Service-Level-Ziele (SLOs)einzuhalten. Google Cloud unterstützt große Cluster. Je nach Anwendungsfall müssen Sie jedoch die Einschränkungen großer Cluster berücksichtigen, um besser auf die Anforderungen an die Infrastrukturskalierung reagieren zu können.
In diesem Abschnitt werden die Einschränkungen und Überlegungen beim Design großer GKE-Cluster basierend auf der erwarteten Anzahl von Knoten beschrieben.
Allgemeine Überlegungen zur Clustermigration
Unabhängig von der Zielclustergröße sollten Sie bei der Migration zu höheren Knotenlimits Folgendes berücksichtigen:
- Wenn Sie von zonalen zu regionalen Standardclustern migrieren, müssen Sie den Cluster neu erstellen, um auf höhere Knotenkontingentlimits zuzugreifen.
- Wenn Sie zu Clustern migrieren, die Private Service Connect verwenden, müssen Sie den Cluster neu erstellen, um auf das höhere Knotenkontingentlimit zuzugreifen.
Automatische Clustergrößenlimits
Wenn Sie Ihre Clusterarchitektur entwerfen, sollten Sie berücksichtigen, dass GKE regionale Standardcluster, die sowohl Private Service Connect als auch GKE Dataplane V2 verwenden, automatisch auf bis zu 5.000 Knoten skalieren kann, ohne dass Sie sich an den Support wenden müssen.
Beachten Sie die folgenden Bedingungen:
- Dieses Limit ist nur für regionale Standardcluster verfügbar.
- Regionale Standardcluster müssen sowohl Private Service Connect als auch GKE Dataplane V2 verwenden.
Wenn Sie Ihren Cluster über dieses automatische Limit hinaus skalieren möchten, wenden Sie sich an Cloud Customer Care, um die Clustergröße und das Kontingentlimit zu erhöhen.
Clustergrößen, für die eine Kontingenterhöhung erforderlich ist
Wenn Sie Ihren Cluster über das automatische Limit hinaus skalieren möchten, führen Sie die folgenden Aufgaben aus:
Cluster mit 5.000 bis 15.000 Knoten
In diesem Skalierungsbereich unterstützt GKE große Standardcluster mit bis zu 15.000 Knoten und der Cluster Autoscaler unterstützt bis zu 15.000 Knoten. Wenn Sie auf diese Limits skalieren möchten, müssen Sie sich an Cloud Customer Care wenden, um die Clustergröße und das Kontingentlimit zu erhöhen.
Megacluster (mehr als 15.000 Knoten bis zu 65.000)
In Version 1.31 und höher unterstützt GKE große Cluster mit bis zu 65.000 Knoten. Dieses Limit ist in erster Linie für die Ausführung umfangreicher KI-Arbeitslasten optimiert.
Wenn Sie Ihren Cluster auf 65.000 Knoten skalieren möchten, führen Sie die folgenden Aufgaben aus:
Beachten Sie folgende Einschränkungen:
- Der Cluster Autoscaler wird nicht unterstützt. Skalieren Sie stattdessen Ihre Knotenpools mit der GKE API nach oben oder unten.
- Mehrere Netzwerke werden nicht unterstützt.
- Dienste mit mehr als 100 Pods müssen monitorlos sein.
- Jeder Pod sollte auf einem eigenen Knoten ausgeführt werden, mit Ausnahme von System-DaemonSets. Wenn Sie die Pod-Planung auf bestimmten Knoten definieren möchten, können Sie die Pod-Affinität oder ‑Anti-Affinität von Kubernetes verwenden.
Wenden Sie sich an Cloud Customer Care, um die Clustergröße und das Kontingentlimit je nach Ihren Skalierungsanforderungen auf bis zu 65.000 Knoten zu erhöhen.
Best Practices zum Aufteilen von Arbeitslasten auf mehrere Cluster
Sie können Ihre Arbeitslasten auf einem einzelnen großen Cluster ausführen. Dieser Ansatz ist einfacher zu verwalten, kostengünstiger und eine bessere Ressourcennutzung als mehrere Cluster. In einigen Fällen ist es jedoch erforderlich, die Arbeitslast in mehrere Cluster aufzuteilen:
- Unter Multi-Cluster-Anwendungsfälle finden Sie weitere Informationen zu den allgemeinen Anforderungen und Szenarien für die Verwendung mehrerer Cluster.
- Teilen Sie den Cluster aus Sicht der Skalierbarkeit auch auf, wenn er eines der im Abschnitt unten oder eines der GKE-Kontingente beschriebenen Limits überschreiten kann. Wenn Sie ein Risiko verringern, dass die GKE-Limits erreicht werden, wird das Risiko von Ausfallzeiten oder anderen Zuverlässigkeitsproblemen verringert.
Wenn Sie Ihren Cluster aufteilen, verwenden Sie die Flottenverwaltung, um die Verwaltung einer Multi-Cluster-Flotte zu vereinfachen.
Limits und Best Practices
Prüfen Sie die folgenden Limits und zugehörige Best Practices, um sicherzustellen, dass Ihre Architektur umfangreiche GKE-Cluster unterstützt. Das Überschreiten dieser Beschränkung kann zu einer Beeinträchtigung der Clusterleistung oder Zuverlässigkeit führen.
Diese Best Practices gelten für jeden Kubernetes-Standardcluster ohne installierte Erweiterungen. Es ist üblich, Kubernetes-Cluster mit Webhooks oder benutzerdefinierten Ressourcendefinitionen (Custom Resource Definitions, CRDs) zu erweitern. Dadurch kann jedoch die Skalierbarkeit des Clusters eingeschränkt werden.
Die folgende Tabelle erweitert die Hauptkontingente und Limits für GKE. Außerdem sollten Sie sich mit den Open-Source-Kubernetes-Limits für große Cluster vertraut machen.
Die in der Tabelle genannten GKE-Versionsanforderungen gelten sowohl für die Knoten als auch für die Steuerungsebene.
| GKE-Limit | Beschreibung | Best Practices |
|---|---|---|
| Größe der etcd-Datenbank | Die maximale Größe der etcd-Datenbank beträgt 6 GB. Sie sollten die Größe der etcd-Datenbank Ihres Clusters proaktiv überwachen und Benachrichtigungen konfigurieren, damit Sie informiert werden, wenn die Nutzung sich diesem Limit nähert. Das Überschreiten des Limits kann zu Problemen mit der Steuerungsebene führen. | Mit den folgenden Ressourcen können Sie Ihre Nutzung überwachen:
Weitere Informationen dazu, wie Sie reagieren sollten, wenn Sie sich dem Limit nähern, finden Sie unter Cluster identifizieren, bei denen sich die etcd-Nutzung dem Limit nähert. |
| Gesamtgröße der etcd-Objekte pro Typ | Die Gesamtgröße aller Objekte des angegebenen Ressourcentyps sollte 800 MB nicht überschreiten. Sie können beispielsweise 750 MB Pod-Instanzen und 750 MB Secrets erstellen, aber nicht 850 MB Secrets. Wenn Sie mehr als 800 MB an Objekten erstellen, kann dies dazu führen, dass Ihre Kubernetes- oder benutzerdefinierten Controller nicht initialisiert werden und Störungen verursachen. |
Halten Sie die Gesamtgröße aller in etcd gespeicherten Objekte jedes Typs unter 800 MB. Dies gilt insbesondere für Cluster, die viele große Secrets oder ConfigMaps oder eine große Anzahl von CRDs verwenden. |
| Anzahl der Dienste für Cluster, in denen GKE Dataplane V2 nicht aktiviert ist | Die Leistung von iptables, die von kube-proxy verwendet werden, verschlechtert sich, wenn eines der folgenden Ereignisse eintritt:
Dieses Limit wird aufgehoben, wenn GKE Dataplane V2 aktiviert ist. |
Halten Sie die Anzahl der Services im Cluster unter 10.000. Weitere Informationen finden Sie unter Anwendungen über Services verfügbar machen. |
| Anzahl der Services pro Namespace | Die Anzahl der für Dienste generierten Umgebungsvariablen überschreitet möglicherweise die Shell-Limits. Dies kann dazu führen, dass Pods beim Start abstürzen. |
Die Anzahl der Service pro Namespace muss unter 5.000 liegen. Sie können diese Umgebungsvariablen deaktivieren. In der Dokumentation können Sie nachlesen, wie Sie Weitere Informationen finden Sie unter Anwendungen über Services verfügbar machen. |
| Anzahl der Pods hinter einem einzelnen Service für Cluster, in denen GKE Dataplane V2 nicht aktiviert ist |
Jeder Knoten führt einen kube-proxy aus, der zur Überwachung von Dienständerungen Watches verwendet. Je größer ein Cluster ist, desto mehr änderungsbezogene Daten werden vom Agent verarbeitet. Dies ist besonders in Clustern mit mehr als 500 Knoten sichtbar. Informationen zu den Endpunkten werden auf separate Endpunktobjekte sind weiter für Komponenten verfügbar, aber jeder Endpunkt über 1.000 Pods wird automatisch abgeschnitten. |
Halten Sie die Anzahl der Pods hinter einem einzelnen Service unter 10.000. Weitere Informationen finden Sie unter Anwendungen über Services verfügbar machen. |
| Anzahl der Pods hinter einem einzelnen Service für Cluster, in denen GKE Dataplane V2 aktiviert ist. |
GKE Dataplane V2 enthält Limits für die Anzahl der Pods, die von einem einzelnen Dienst bereitgestellt werden. Für Autopilot-Cluster gilt das gleiche Limit wie für GKE Dataplane V2. |
Halten Sie in GKE 1.23 und früheren Versionen die Anzahl der Pods hinter einem einzelnen Service unter 1.000. Halten Sie in GKE 1.24 und höher die Anzahl der Pods hinter einem einzelnen Service unter 10.000. Weitere Informationen finden Sie unter Anwendungen über Services verfügbar machen. |
| DNS-Einträge pro monitorlosem Dienst |
Die Anzahl der DNS-Einträge pro monitorlosem Dienst ist sowohl für kube-dns als auch für Cloud DNS begrenzt. |
Die Anzahl der DNS-Einträge pro monitorlosem Dienst sollte für kube-dns unter 1.000 und für Cloud DNS unter 3.500/2.000 (IPv4/IPv6) liegen. |
| Anzahl aller Dienstendpunkte | Die Anzahl der Endpunkte in allen Diensten kann Limits erreichen. Dies kann die Programmierlatenz erhöhen oder dazu führen, dass überhaupt keine neuen Endpunkte programmiert werden können. |
Die Zahl aller Endpunkte in allen Diensten sollte unter 260.000 liegen. GKE Dataplane V2, die Standard-Datenebene für GKE Autopilot, basiert auf eBPF-Karten,die derzeit in allen Diensten auf 260.000 Endpunkte beschränkt sind. |
| Anzahl der horizontalen Pod-Autoscaler-Objekte pro Cluster |
Jeder horizontale Pod-Autoscaler (HPA) wird alle 15 Sekunden verarbeitet. Mehr als 300 HPA-Objekte können zu linearen Leistungseinbußen führen. |
Halten Sie die Anzahl der HPA-Objekte innerhalb dieser Limits. Andernfalls kann es zu einer linearen Beeinträchtigung der Häufigkeit der HPA-Verarbeitung kommen. In GKE 1.22 mit 2.000 HPAs wird beispielsweise ein einzelner HPA alle 100 Sekunden neu verarbeitet. Weitere Informationen finden Sie unter Autoscaling auf Basis der Ressourcennutzung und Skalierbarkeit des horizontalen Pod-Autoscalings. |
| Anzahl der Pods pro Knoten | GKE hat ein festes Limit von 256 Pods pro Knoten. Dabei wird von durchschnittlich zwei oder weniger Containern pro Pod ausgegangen. Wenn Sie die Anzahl der Container pro Pod erhöhen, kann dieses Limit niedriger sein, da GKE mehr Ressourcen pro Container zuweist. |
Wir empfehlen die Verwendung von Worker-Knoten mit mindestens einer vCPU pro 10 Pods. Weitere Informationen finden Sie unter Manuelles Upgrade eines Clusters oder Knotenpools durchführen. |
| Rate der Pod-Änderungen |
Kubernetes hat interne Limits, die sich auf die Rate der Erstellung oder des Löschens von Pods (Abwanderung von Pods) als Reaktion auf Skalierungsanfragen auswirken. Weitere Faktoren wie das Löschen eines Pods, der Teil eines Service ist, können sich auch auf die Pod-Abwanderungsrate auswirken. Bei Clustern mit bis zu 500 Knoten können Sie mit einer durchschnittlichen Rate von 20 Pods pro Sekunde (erstellen) und 20 Pods pro Sekunde (löschen) rechnen. Bei Clustern mit mehr als 500 Knoten können Sie mit einer durchschnittlichen Rate von 100 Pods pro Sekunde (erstellen) und 100 Pods pro Sekunde (löschen) rechnen. |
Berücksichtigen Sie bei der Planung der Skalierung Ihrer Arbeitslasten die Begrenzung der Pod-Erstellungs- und -Löschrate. Pods haben denselben Löschdurchsatz wie andere Ressourcentypen (z. B. EndpointSlices). Sie können den Löschdurchsatz reduzieren, wenn Sie Pods als Teil eines Service definieren. Vermeiden Sie zu restriktive PodDisruptionBudgets und lange Kulanzzeiträume für die Beendigung, damit Cluster Autoscaler Pods effektiv aus nicht ausgelasteten Knoten entfernen kann. Auch Platzhalter-Toleranzen werden nicht empfohlen, da diese dazu führen können, dass Arbeitslasten auf Knoten geplant werden, die gerade entfernt werden. |
| Anzahl der offenen Beobachtungen | Knoten erstellen eine Beobachtung für jedes Secret und jede ConfigMaps, die Sie für Pods konfigurieren. Die kombinierte Menge an Beobachtungen, die von allen Knoten erzeugt wird, kann zu einer erheblichen Belastung der Steuerungsebene des Clusters führen. Wenn Sie mehr als 200.000 Beobachtungen pro Cluster haben, kann dies die Initialisierungszeit des Clusters beeinträchtigen. Dieses Problem kann dazu führen, dass die Steuerungsebene häufig neu gestartet wird. |
Definieren Sie größere Knoten, um die Wahrscheinlichkeit und den Schweregrad von Problemen zu verringern, die durch eine große Anzahl von Überwachungen verursacht werden. Eine höhere Pod-Dichte (weniger große Knoten) kann die Anzahl der Überwachungen verringern und den Schweregrad des Problems mindern. Weitere Informationen finden Sie im Vergleich der Maschinenserien. |
| Anzahl der Secrets pro Cluster, wenn die Verschlüsselung von Secrets auf Anwendungsebene aktiviert ist | Ein Cluster muss beim Starten des Clusters alle Secrets entschlüsseln, wenn die Verschlüsselung von Secrets auf Anwendungsebene aktiviert ist. Wenn Sie mehr als 30.000 Secrets speichern, wird Ihr Cluster während des Starts oder Upgrades möglicherweise instabil, was zu Arbeitslastausfällen führt. | Speichern Sie weniger als 30.000 Secrets, wenn Sie die Verschlüsselung von Secrets auf Anwendungsebene verwenden. Weitere Informationen finden Sie unter Secrets auf Anwendungsebene verschlüsseln. |
| Logbandbreite pro Knoten |
Die maximale Anzahl von Logs, die von jedem Knoten an die Cloud Logging API gesendet werden, ist begrenzt. Das Standardlimit liegt je nach Last zwischen 100 kbit/s und 500 kbit/s. Bei Standardclustern können Sie das Limit auf 10 MiB erhöhen, indem Sie eine Logging-Agent-Konfiguration mit hohem Durchsatz bereitstellen. Eine Überschreitung dieses Limits kann dazu führen, dass Logeinträge gelöscht werden. |
Konfigurieren Sie Ihr Logging so, dass es innerhalb der Standardlimits bleibt, oder konfigurieren Sie einen Logging-Agent mit hohem Durchsatz. Weitere Informationen finden Sie unter Logdurchsatz anpassen. |
| Knotenpools | Eine große Anzahl von Knotenpools kann sich auf die Latenz der Infrastruktur-Autoskalierung auswirken, da die Anzahl der Knoten erhöht wird, die dem Cluster potenziell hinzugefügt werden können. Funktionen wie die Arbeitslasttrennung oder benutzerdefinierte ComputeClasses erhöhen die Anzahl der Knotenpools. | Die Anzahl der Knotenpools sollte unter 200 liegen. |
| Sicherung für GKE-Limits |
Sie können Backup for GKE verwenden, um Ihre GKE-Arbeitslasten zu sichern und wiederherzustellen. Backup for GKE unterliegt den Limits, die Sie bei der Definition Ihrer Sicherungspläne berücksichtigen müssen. |
Einschränkungen für Backup for GKE Wenn Ihre Arbeitslast diese Limits überschreiten kann, empfehlen wir, mehrere Sicherungspläne zu erstellen, um Ihre Sicherung zu partitionieren und innerhalb der Limits zu bleiben. |
| Config Connector-Limits |
Mit Config Connector können Sie Google Cloud Ressourcen über Kubernetes verwalten. Config Connector hat zwei Betriebsmodi:
|
Weitere Informationen zu Ressourcenlimits finden Sie in den Skalierbarkeitsrichtlinien für Config Controller. Informationen zum Verwalten einer großen Anzahl von Ressourcen finden Sie unter Best Practices für Config Connector. |