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 bei großen GKE-Clustern
Wenn GKE einen Cluster auf eine große Anzahl von Knoten skaliert, versucht GKE, die Menge der verfügbaren Ressourcen an die Anforderungen Ihres Systems anzupassen und dabei die Service Level Objectives (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 Entwerfen großer GKE-Cluster basierend auf der erwarteten Anzahl von Knoten beschrieben.
Cluster mit bis zu 5.000 Knoten
Berücksichtigen Sie beim Entwerfen Ihrer Clusterarchitektur für die Skalierung auf bis zu 5.000 Knoten die folgenden Bedingungen:
- Nur für regionale Cluster verfügbar.
- Nur für Cluster verfügbar, die Private Service Connect verwenden.
- Wenn Sie von zonalen zu regionalen Clustern migrieren, müssen Sie den Cluster neu erstellen, um ein höheres Knotenkontingent zu erhalten.
Wenn Sie Ihren Cluster auf mehr als 5.000 Knoten skalieren möchten,wenden Sie sich an den Cloud-Kundendienst, um das Limit für die Clustergröße und das Kontingent zu erhöhen.
Cluster mit mehr als 5.000 Knoten
GKE unterstützt große Standardcluster mit bis zu 15.000 Knoten. In Version 1.31 und höher unterstützt GKE große Cluster mit bis zu 65.000 Knoten. Das Limit von 65.000 Einheiten ist für die Ausführung großer KI-Arbeitslasten vorgesehen.
Wenn Sie Ihren Cluster auf 15.000 oder 65.000 Knoten skalieren möchten, führen Sie die folgenden Aufgaben aus:
Beachten Sie folgende Einschränkungen:
- Cluster Autoscaler wird nicht unterstützt. Skalieren Sie Ihre Knotenpools stattdessen mit der GKE API.
- Mehrere Netzwerke werden nicht unterstützt.
- Dienste mit mehr als 100 Pods müssen headless 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 Kubernetes-Pod-Affinität oder -Antiaffinität verwenden.
- Wenn Sie von zonalen zu regionalen Clustern migrieren, müssen Sie den Cluster neu erstellen, um ein höheres Knotenkontingent zu erhalten.
- Wenn Sie zu Clustern migrieren, die Private Service Connect verwenden, müssen Sie den Cluster neu erstellen, um das höhere Knotenkontingent zu nutzen.
Wenden Sie sich an den Cloud-Kundenservice, um die Clustergröße und das Kontingentlimit je nach Ihren Skalierungsanforderungen auf 15.000 oder 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. | Die folgenden Ressourcen können Ihnen helfen, Ihre Nutzung zu überwachen:
Weitere Informationen dazu, wie Sie reagieren können, wenn Sie sich dem Limit nähern, finden Sie unter Cluster identifizieren, in denen die etcd-Nutzung sich 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. |
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 variiert 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 Log-Durchsatz anpassen. |
| Knotenpools | Eine große Anzahl von Knotenpools kann sich auf die Latenz beim Infrastruktur-Autoscaling auswirken, da die Anzahl der Knoten, die dem Cluster potenziell hinzugefügt werden können, dadurch steigt. Funktionen wie Arbeitslasttrennung oder benutzerdefinierte Compute-Klassen erhöhen die Anzahl der Knotenpools. | Die Anzahl der Knotenpools sollte unter 200 liegen. |
| Limits für Sicherung für GKE |
Sie können Sicherung für 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. |