Auf dieser Seite werden die Best Practices beschrieben, die Sie bei der Planung und beim Design von sehr großen Clustern befolgen können.
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 denselben Fällen 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.
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. Wenn Sie einen sehr großen Cluster mit Zehntausenden von Ressourcen ausführen, überschreiten Ihre etcd-Instanzen möglicherweise dieses Limit. Sie können den Auslastungsgrad Ihrer Cluster in der Google Cloud Console prüfen. | Wenn Sie dieses Limit überschreiten, markiert GKE Ihre etcd-Instanzen möglicherweise als fehlerhaft. Dadurch reagiert die Steuerungsebene des Clusters nicht mehr.
Wenn Sie dieses Limit überschreiten, wenden Sie sich an den Google Cloud-Support. |
| 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. |
Halten Sie die Anzahl der DNS-Einträge pro monitorlosem Service unter 1.000 für kube-dns und 3.500/2.000 (IPv4/IPv6) für Cloud DNS. |
| 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. Sie können das Limit auf 10 Mbit/s 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 Durchsatz des Logging-Agents erhöhen. |
| 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. |
| Limits für Config Connector |
Mit Config Connector können Sie Google Cloud-Ressourcen über Kubernetes verwalten. Config Connector hat zwei Betriebsmodi:
|
Jede Config Connector-Instanz hat eine CPU-Anfrage von 0,1 und ein Arbeits-Speicherlimit von 512 MB. Daher ist er nicht gut für eine Skalierung auf eine große Menge verwalteter Ressourcen geeignet. Wir empfehlen, nie mehr als 25.000 Google Cloud-Ressourcen pro Config Connector-Instanz zu verwenden. Diese Einschränkung dient nur zu Referenzzwecken, da die Größe des verwendeten Arbeitsspeichers vom Typ der Ressource und den spezifischen Anwendungsfällen abhängt. Wenn Sie eine größere Zahl verwalteter Ressourcen verwalten, empfehlen wir die Verwendung des Namespace-Modus, um die Anzahl der pro Config Connector-Instanz verarbeiteten Ressourcen zu begrenzen. Wir empfehlen die Verwendung von bis zu 500 Namespaces mit Config Connector im Namespace-Modus.
Jede Config Connector-Instanz öffnet zahlreiche Watch-Verbindungen zum kube-apiserver. Eine große Anzahl dieser Instanzen kann die Steuerungsebene des GKE-Clusters überlasten, insbesondere während Upgrades der Steuerungsebene, wenn die Watch-Verbindungen neu initialisiert werden müssen. Wir empfehlen die Verwendung mehrerer GKE-Cluster, um die Anzahl der Ressourcen zu verwalten, die nicht aufgeteilt werden konnten, um zu den oben angegebenen Limits zu passen. Weitere Informationen finden Sie in den Skalierbarkeitsrichtlinien für Config Controller. |