Auf dieser Seite werden die Best Practices beschrieben, die Sie bei der Verwaltung großer Arbeitslasten in mehreren GKE-Clustern befolgen können. Diese Best Practices decken die Verteilung von Arbeitslasten auf mehrere Projekte und die Anpassung der erforderlichen Kontingente ab.
Best Practices zum Verteilen von GKE-Arbeitslasten auf mehrere Google Cloud-Projekte
Für eine bessere Definition Ihrer Google Cloud-Projektstruktur und GKE-Arbeitslastverteilung entsprechend Ihren Geschäftsanforderungen empfehlen wir die folgenden Design- und Planungsaktionen:
- Befolgen Sie die Best Practices für Cloud-Ressourcen verwalten, um erste Entscheidungen über die Struktur Ihrer Organisation für Ordner und Projekte zu treffen. Google Cloud empfiehlt die Verwendung von Elementen der Ressourcenhierarchie wie Ordnern und Projekten, um Ihre Arbeitslast basierend auf Ihren eigenen Organisationsgrenzen oder Zugriffsrichtlinien zu unterteilen.
- Überlegen Sie, ob Sie Ihre Arbeitslasten aufgrund von Projektkontingenten aufteilen müssen. Google Cloud verwendet Kontingente pro Projekt, um die Nutzung freigegebener Ressourcen zu beschränken. Sie müssen die unten beschriebenen Empfehlungen umsetzen und die Projektkontingente für große Arbeitslasten anpassen. Für die meisten Arbeitslasten sollten Sie die erforderlichen, höheren Kontingente nur in einem einzelnen Projekt erreichen können. Das bedeutet, dass Kontingente nicht der Hauptgrund für die Aufteilung Ihrer Arbeitslast auf mehrere Projekte sein sollten. Die Aufteilung Ihrer Arbeitslasten auf eine geringere Anzahl von Projekten vereinfacht die Verwaltung Ihrer Kontingente und Arbeitslasten.
- Überlegen Sie sich, ob Sie sehr große Arbeitslasten (Hunderttausende von CPUs oder mehr) ausführen möchten. In einem solchen Fall kann die Arbeitslast in mehrere Projekte aufgeteilt werden, wodurch sich die Verfügbarkeit von Cloudressourcen wie CPUs oder GPUs erhöhen kann. Dies ist aufgrund der optimierten Konfiguration der Zonenvirtualisierung möglich. Wenden Sie sich in solchen Fällen an Ihren Account Manager, um Support und Empfehlungen zu erhalten.
Best Practices zum Anpassen von Kontingenten für große GKE-Arbeitslasten
In diesem Abschnitt werden Richtlinien für das Anpassen von Kontingenten für Google Cloud-Ressourcen beschrieben, die von GKE-Arbeitslasten verwendet werden. Passen Sie die Kontingente für Ihre Projekte anhand der folgenden Richtlinien an. Informationen zum Verwalten Ihres Kontingents über die Google Cloud Console finden Sie unter Mit Kontingenten arbeiten.
Kontingente und Best Practices für Compute Engine
GKE-Cluster, die sowohl im Autopilot- als auch im Standardmodus ausgeführt werden, verwenden Compute Engine-Ressourcen, um Ihre Arbeitslasten auszuführen. Im Gegensatz zu den Ressourcen der Kubernetes-Steuerungsebene, die intern von Google Cloud verwaltet werden, können Sie Compute Engine-Kontingente, die von Ihren Workflows verwendet werden, verwalten und bewerten.
Compute Engine-Kontingente für Ressourcen und APIs werden von allen GKE-Clustern gemeinsam genutzt, die im selben Projekt und in derselben Region gehostet werden. Dieselben Kontingente werden auch an andere (nicht GKE-bezogene) Compute Engine-Ressourcen weitergegeben (z. B. eigenständige VM-Instanzen oder Instanzgruppen).
Standardwerte können mehrere hundert Worker-Knoten unterstützen und erfordern eine Anpassung bei größeren Arbeitslasten. Als Plattformadministrator können Sie jedoch die Compute Engine-Kontingente proaktiv anpassen, um dafür zu sorgen, dass Ihre GKE-Cluster genügend Ressourcen haben. Sie sollten auch den zukünftigen Ressourcenbedarf berücksichtigen, wenn Sie die Kontingentwerte bewerten oder anpassen.
Kontingente für Compute Engine-Ressourcen, die von GKE-Worker-Knoten verwendet werden
In der folgenden Tabelle sind Ressourcenkontingente für die häufigsten Compute Engine-Ressourcen aufgeführt, die von GKE-Worker-Knoten verwendet werden. Diese Kontingente werden pro Projekt und pro Region konfiguriert. Die Kontingente müssen die maximale kombinierte Größe der von Ihrer Arbeitslast verwendeten GKE-Worker-Knoten und anderer Compute Engine-Ressourcen abdecken, die nicht mit GKE verbunden sind.
| Ressourcenkontingent | Beschreibung |
|---|---|
| CPUs | Anzahl der CPUs, die von allen Worker-Knoten aller Cluster verwendet werden. |
| CPU-Typ | Anzahl jedes CPU-Typs, der von allen Worker-Knoten aller Cluster verwendet wird. |
| VM-Instanzen | Anzahl aller Worker-Knoten. Dieses Kontingent wird automatisch als 10-fache Anzahl der CPUs berechnet. |
| Instanzen pro VPC-Netzwerk | Anzahl aller Worker-Knoten, die mit dem VPC-Netzwerk verbunden sind. |
| Nichtflüchtiger Standardspeicher (GB) | Gesamtgröße der nichtflüchtigen Standardspeicherlaufwerke, die an alle Worker-Knoten angehängt sind. |
| Nichtflüchtiger SSD-Speicher (GB): | Gesamtgröße der nichtflüchtigen SSD-Bootlaufwerke, die an alle Worker-Knoten angehängt sind. |
| Lokale SSD (GB): | Gesamtgröße der flüchtigen lokalen SSD-Laufwerke, die an alle Worker-Knoten angehängt sind. |
Passen Sie auch die von Ressourcen benötigten Kontingente an, z. B. GPUs, IP-Adressen oder Ressourcen auf Abruf.
Kontingente für Compute Engine API-Aufrufe
Große oder skalierbare Cluster erfordern eine höhere Anzahl von Compute Engine API-Aufrufen. GKE führt diese Compute Engine API-Aufrufe bei Aktivitäten wie den folgenden aus:
- Status der Rechenressourcen prüfen.
- Neue Knoten zum Cluster hinzufügen oder daraus entfernen.
- Neue Knotenpools hinzufügen oder entfernen.
- Regelmäßige Labelerstellung von Ressourcen.
Bei der Planung einer großen Clusterarchitektur empfehlen wir Folgendes:
- Beachten Sie den Verlauf des Kontingentverbrauchs.
- Passen Sie die Kontingente nach Bedarf an und behalten Sie dabei einen angemessenen Puffer bei. Sie können sich die folgenden Best Practice-Empfehlungen als Ausgangspunkt ansehen und die Kontingente an Ihre Arbeitslastanforderungen anpassen.
- Da Kontingente pro Region konfiguriert sind, passen Sie die Kontingente nur in den Regionen an, in denen Sie große Arbeitslasten ausführen möchten.
In der folgenden Tabelle sind die Kontingente für Compute Engine API-Aufrufe aufgeführt. Diese Kontingente werden pro Projekt und für jede Region konfiguriert. Sie werden von allen GKE-Clustern gemeinsam genutzt, die im selben Projekt und in derselben Region gehostet werden.
| API-Kontingent | Beschreibung | Best Practices |
|---|---|---|
| Abfragen pro Minute und Region | Diese Aufrufe werden von GKE verwendet, um verschiedene Prüfungen am Status der verschiedenen Rechenressourcen durchzuführen. |
Legen Sie für Projekte und Regionen mit mehreren hundert dynamischen Knoten diesen Wert auf 3.500 fest. Legen Sie für Projekte und Regionen mit mehreren Tausend hochdynamischen Knoten diesen Wert auf 6.000 fest. |
| Leseanfragen pro Minute pro Region | Diese Aufrufe werden von GKE verwendet, um den Status der VM-Instanzen (Knoten) zu überwachen. |
Bei Projekten und Regionen mit mehreren hundert Knoten legen Sie diesen Wert auf 12.000 fest. Bei Projekten und Regionen mit Tausenden von Knoten legen Sie diesen Wert auf 20.000 fest. |
| Anfragen pro Minute und Region auflisten | Diese Aufrufe werden von GKE verwendet, um den Status von Instanzgruppen (Knotenpools) zu überwachen. |
Ändern Sie bei Projekten und Regionen mit mehreren hundert dynamischen Knoten den Standardwert nicht, weil er ausreicht. Legen Sie für Projekte und Regionen mit Tausenden von sehr dynamischen Knoten in mehreren Knotenpools diesen Wert auf 2.500 fest. |
| Anfragen zu Listen-Verweis-URLs für Instanzen pro Minute und Region | Diese Aufrufe werden von GKE verwendet, um Informationen über ausgeführte VM-Instanzen (Knoten) abzurufen. |
Legen Sie für Projekte und Regionen mit Tausenden von sehr dynamischen Knoten diesen Wert auf 6.000 fest. |
| Leseanfragen pro Minute und Region | Diese Aufrufe werden von GKE verwendet, um Informationen zu laufenden Compute Engine API-Vorgängen abzurufen. |
Legen Sie für Projekte und Regionen mit Tausenden von sehr dynamischen Knoten diesen Wert auf 3.000 fest. |
Kontingente und Best Practices für die Cloud Logging API und die Cloud Monitoring API
Je nach Clusterkonfiguration können große Arbeitslasten, die auf GKE-Clustern ausgeführt werden, große Mengen an Diagnoseinformationen generieren. Wenn Sie die Kontingente der Cloud Logging API oder der Cloud Monitoring API überschreiten, gehen die Logging- und Monitoring-Daten möglicherweise verloren. Wir empfehlen, die Ausführlichkeit der Logs zu konfigurieren und die Kontingente der Cloud Logging API und Cloud Monitoring API anzupassen, um generierte Diagnoseinformationen zu erfassen. Managed Service for Prometheus verbraucht Cloud Monitoring-Kontingente.
Da jede Arbeitslast unterschiedlich ist, empfehlen wir Folgendes:
- Beachten Sie den Verlauf des Kontingentverbrauchs.
- Passen Sie die Kontingente oder Logging- und Monitoring-Konfiguration nach Bedarf an. Halten Sie für unerwartete Probleme einen angemessenen Puffer zurück.
In der folgenden Tabelle sind Kontingente für Cloud Logging APIs und Cloud Monitoring API-Aufrufe aufgeführt. Diese Kontingente werden pro Projekt konfiguriert und werden von allen GKE-Clustern gemeinsam genutzt, die im selben Projekt gehostet werden.
| Dienst | Kontingent | Beschreibung | Best Practices |
|---|---|---|---|
| Cloud Logging API | Schreibanfragen pro Minute | GKE verwendet dieses Kontingent, wenn Einträge zu den in Cloud Logging gespeicherten Logdateien hinzugefügt werden. |
Die Rate der Logeinfügung hängt von der Anzahl der Logs ab, die von den Pods in Ihrem Cluster generiert werden. Erhöhen Sie das Kontingent anhand der Anzahl der Pods, der Ausführlichkeit des Anwendungs-Loggings und der Logging-Konfiguration. Weitere Informationen finden Sie unter GKE-Logs verwalten. |
| Cloud Monitoring API | Anfragen zur Zeitachsenaufnahme pro Minute |
GKE verwendet dieses Kontingent, wenn Prometheus-Messwerte an Cloud Monitoring gesendet werden:
|
Überwachen Sie dieses Kontingent und passen Sie es nach Bedarf an. Weitere Informationen finden Sie unter GKE-Messwerte verwalten. |
GKE-Knotenkontingent und Best Practices
GKE unterstützt bis zu 15.000 Knoten in einem einzelnen Cluster, wobei das Standardkontingent auf 5.000 Knoten festgelegt ist. Dieses Kontingent wird für jeden GKE-Cluster separat festgelegt und nicht wie andere Kontingente pro Projekt. Wenn Sie die Skalierung Ihres Clusters auf mehr als 5.000 Knoten planen, führen Sie die folgenden Schritte aus:
- Identifizieren Sie den Cluster, den Sie über 5.000 Knoten hinaus skalieren möchten.
- Achten Sie darauf, dass Ihre Arbeitslast nach der Skalierung innerhalb der Clusterlimits und GKE-Kontingente bleibt.
- Achten Sie darauf, Compute Engine-Kontingente für Ihre skalierte Arbeitslast zu erhöhen.
- Achten Sie darauf, dass der Verfügbarkeitstyp Ihres Clusters regional und die Netzwerkisolierung privat ist.
- Beantragen Sie die Erhöhung des Kontingents für die Anzahl der Knoten pro Cluster, indem Sie ein Support-Ticket erstellen.
Das GKE-Team wird Sie kontaktieren, um zu garantieren, dass Ihre Arbeitslast den Best Practices für die Skalierbarkeit entspricht und bereit ist, in einem einzelnen Cluster auf mehr als 5.000 Knoten zu skalieren.
Best Practices zur Vermeidung anderer Limits für große Arbeitslasten
Beschränkung für die Anzahl der Cluster mit VPC-Netzwerk-Peering pro Netzwerk und Standort
Sie können pro Standort maximal 75 private Cluster erstellen, die VPC-Netzwerk-Peering im selben VPC-Netzwerk verwenden (Zonen und Regionen werden als separate Standorte behandelt). Versuche, zusätzliche Cluster über das Limit hinaus zu erstellen, schlagen mit einem Fehler wie dem folgenden fehl:
CREATE operation failed. Could not trigger cluster creation:
Your network already has the maximum number of clusters: (75) in location us-central1.
Private GKE-Cluster verwenden VPC-Netzwerk-Peering, um eine interne Kommunikation zwischen dem von Google verwalteten Kubernetes API-Server und privaten Knoten zu ermöglichen, die nur interne Adressen haben.
Zur Behebung dieses Problems können Sie Cluster verwenden, die die PSC-Verbindung (Private Service Connect) nutzen. Cluster mit PSC-Konnektivität bieten die gleiche Isolation wie ein privater Cluster ohne die Einschränkung von 75 Clustern. Cluster, die auf PSC basieren, verwenden kein VPC-Netzwerk-Peering und sind nicht vom Limit der Anzahl der VPC-Peerings betroffen.
Mithilfe der Anleitung unter Wiederverwendung von VPC-Netzwerk-Peering können Sie feststellen, ob Ihre Cluster VPC-Netzwerk-Peering verwenden.
So vermeiden Sie beim Erstellen neuer Cluster das Limit:
- Erstellen Sie einen PSC-Cluster mit dem Parameter
no-enable-private-nodeswährend der Clustererstellung. - Konfigurieren Sie die Isolation für Knotenpools mithilfe des Parameters
enable-private-nodesfür jeden Knotenpool als privat. - Optional können Sie die Isolation für die Steuerungsebene mithilfe des Parameters
enable-private-endpointauf Clusterebene konfigurieren. Weitere Informationen finden Sie unter Clusterisolation ändern.
Alternativ können Sie das Google Cloud-Supportteam kontaktieren, um das Limit von 75 privaten Clustern mit VPC-Netzwerk-Peering zu erhöhen. Solche Anfragen werden von Fall zu Fall geprüft. Wenn eine Erhöhung des Limits möglich ist, wird eine einstellige Erhöhung vorgenommen.
Nächste Schritte
- Weitere Informationen finden Sie in den Folgen zum Erstellen großer GKE-Cluster.