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.
Allgemeine Hinweise zur Clustermigration
Unabhängig von der Zielclustergröße sollten Sie bei der Migration zu höheren Knotenlimits Folgendes beachten:
- Wenn Sie von zonalen zu regionalen Standardclustern migrieren, müssen Sie den Cluster neu erstellen, um auf höhere Knotenkontingentlimits zugreifen zu können.
- Wenn Sie zu Clustern migrieren, die Private Service Connect verwenden, müssen Sie den Cluster neu erstellen, um auf das höhere Knotenkontingent zugreifen zu können.
Beschränkungen und Anforderungen für die Clustergröße
In der folgenden Tabelle sind die Skalierungslimits und -anforderungen von GKE basierend auf der Anzahl der Zielknoten zusammengefasst:
| Knotenlimit | Infrastrukturanforderungen | Netzwerkanforderungen | Zugriffsbeschränkungen | Anwendungsbeispiele |
|---|---|---|---|---|
| Bis zu 1.000 | Für alle Cluster verfügbar. | Keine zusätzlichen Anforderungen. | Keine. Das Hochskalieren auf bis zu 1.000 Knoten erfolgt automatisch. | Allgemeine Arbeitslasten, Entwicklung und Tests. |
| 1.000 bis 5.000 | Verfügbar für regionale Standard- und Autopilot-Cluster. |
|
Keine. Das Hochskalieren auf bis zu 5.000 Knoten erfolgt automatisch,wenn Sie die anderen Anforderungen erfüllen. | Kurzlebige Jobs mit hohem Volumen und Unternehmensdienste. |
| 5.000 bis 15.000 |
|
|
Wenn Sie die Clustergröße und das Kontingentlimit erhöhen möchten, wenden Sie sich an Cloud Customer Care. | HPC- und Datenverarbeitungsarbeitslasten. |
| 15.000 bis 65.000 |
|
|
Wenn Sie eine Kontingenterhöhung anfordern und Unterstützung bei der Skalierung auf die höheren Limits erhalten möchten, wenden Sie sich an Cloud Customer Care. | Training großer Modelle. |
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, um informiert zu 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 sollten, 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 HorizontalPodAutoscaler-Objekte pro Cluster |
Jeder horizontale Pod-Autoscaler (HPA) wird alle 15 Sekunden verarbeitet. Standardmäßig unterstützt GKE bis zu 300 HPA-Objekte. Für höhere Limits erhöht das HPA-Leistungsprofil die Unterstützung auf 1.000 HPA-Objekte in Version 1.31 und höher und auf bis zu 5.000 HPA-Objekte in Version 1.33 und höher. Das Überschreiten dieser Beschränkungen kann zu linearen Leistungseinbußen führen. |
Halten Sie die Anzahl der HPA-Objekte innerhalb des unterstützten Limits für das Profil Ihres Clusters (300, 1.000 oder 5.000 Objekte). Andernfalls kann es zu einer linearen Beeinträchtigung der Häufigkeit der HPA-Verarbeitung kommen. Bei 2.000 HPAs mit Standardeinstellungen wird jeder HPA beispielsweise nur alle 100 Sekunden neu verarbeitet. Weitere Informationen finden Sie unter Autoscaling auf Basis der Ressourcennutzung, Skalierbarkeit des horizontalen Pod-Autoscalings und HPA-Profil für die Leistung konfigurieren. |
| Anzahl der Pods pro Knoten | In Standardclustern hat GKE ein Limit von 512 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 ComputeClasses erhöhen die Anzahl der Knotenpools. | Die Anzahl der Knotenpools sollte unter 200 liegen. |
| Die durchschnittliche und maximale Verzögerung des Zulassungs-Webhooks |
Die Admission-Webhooks werden parallel (Validierung) oder sequenziell (Änderung) aufgerufen. In jedem Fall wird jeder konfigurierten Anfrage, die den Webhook-Selektoren entspricht, eine gewisse Verzögerung hinzugefügt. Wenn der Webhook ausgeführt wird, können gleichbleibende kurze Verzögerungen von z. B. 50–100 ms zu einer erheblichen Leistungsminderung führen. |
Konfigurieren Sie Ihre Webhooks so, dass die durchschnittliche Ausführungslatenz unter 10 ms liegt. Geben Sie den Vorgang, die Ressourcentypen und die Namespaces an, auf die sich der Webhook beziehen soll. Vermeiden Sie das Erfassen von Ereignissen, da dies zu Leistungsproblemen führen kann, z. B. zu einem langsameren Prefetch von Bildern. Führen Sie mehrere Instanzen von Webhook-Endpunkten auf separaten Knoten der Arbeitslast aus und sorgen Sie für eine niedrige Latenz. Erwägen Sie, |
| Limits für Sicherung für GKE |
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. |