In diesem Dokument sind die Kontingente und Limits für Google Kubernetes Engine aufgeführt.
Google Cloud nutzt Kontingente, um Fairness zu gewährleisten und Spitzen bei Ressourcennutzung und -verfügbarkeit zu reduzieren. Ein Kontingent schränkt ein, wie viel von einer Google Cloud-Ressource Ihr Google Cloud-Projekt nutzen darf. Kontingente gelten für eine Reihe von Ressourcentypen, einschließlich Hardware, Software und Netzwerkkomponenten. Mit Kontingenten können Sie beispielsweise die Anzahl der API-Aufrufe an einen Dienst, die Anzahl der von Ihrem Projekt gleichzeitig verwendeten Load Balancer oder die Anzahl der Projekte begrenzen, die Sie erstellen können. Die Kontingente sollen eine Überlastung von Diensten verhindern und dadurch die Community der Google Cloud-Nutzer schützen. Sie helfen Ihnen auch bei der Verwaltung Ihrer eigenen Google Cloud-Ressourcen.
Das Cloud-Kontingentsystem ermöglicht Folgendes:
- Ihren Verbrauch von Google Cloud-Produkten und -Diensten überwachen
- Ihren Verbrauch dieser Ressourcen einschränken
- Eine Möglichkeit bieten, Änderungen am Kontingentwert anzufordern
Wenn Sie versuchen, mehr von einer Ressource zu verbrauchen, als das Kontingent zulässt, blockiert das System in den meisten Fällen den Zugriff auf die Ressource. Die Aufgabe, die Sie ausführen möchten, schlägt fehl.
Kontingente gelten in der Regel auf Google Cloud-Projektebene. Ihre Nutzung einer Ressource in einem Projekt hat keinen Einfluss auf Ihr verfügbares Kontingent in einem anderen Projekt. Innerhalb eines Google Cloud-Projekts werden die Kontingente für alle Anwendungen und IP-Adressen gemeinsam genutzt.
Verwenden Sie zur Erhöhung/Verringerung der meisten Kontingenten die Google Cloud Console. Weitere Informationen finden Sie unter Höheres Kontingentlimit anfordern.
Für GKE-Ressourcen gelten außerdem Limits. Diese Limits stehen nicht im Zusammenhang mit dem Kontingentsystem. Limits können nur geändert werden, wenn dies angegeben ist.
Limits pro Projekt
In einem Projekt können Sie maximal 100 zonale Cluster pro Zone sowie 100 regionale Cluster pro Region erstellen.
Hinweis: Cluster, die im Autopilot-Modus erstellt wurden, sind als regionale Cluster vorkonfiguriert.
Limits pro Cluster
In den folgenden Tabellen werden die Limits pro GKE-Cluster beschrieben.
Alle in der folgenden Tabelle angegebenen GKE-Versionen gelten sowohl für Clusterknoten als auch für die Steuerungsebene.
Limits | GKE-Standardcluster | GKE Autopilot-Cluster |
---|---|---|
Knoten pro Cluster |
15.000 Knoten
Hinweis: Wenn Sie mehr als 2.000 Knoten ausführen möchten, verwenden Sie einen regionalen Cluster. Hinweis: Das Ausführen von mehr als 5.000 Knoten ist nur für egionale Cluster verfügbar, die entweder privat oder mit Private Service Connect und mit deaktivierter GKE Dataplane V2 betrieben werden. Wenden Sie sich an den Support, um dieses Kontingentlimit zu erhöhen. |
5.000 Knoten
Hinweis: Wenn Sie mehr als 1.000 Knoten ausführen möchten, verwenden Sie GKE Autopilot Version 1.23 oder höher. Hinweis: Bei über 400 Knoten ist möglicherweise eine Kontingenterhöhung für die Größe von Clustern erforderlich, die mit früheren Versionen erstellt wurden. Wenden Sie sich an den Support, um Unterstützung zu erhalten. |
Knoten pro Knotenpool | 1.000 Knoten pro Zone | Nicht zutreffend |
Knoten in einer Zone |
|
Nicht zutreffend |
Pods pro Knoten1 |
256 Pods
Hinweis: Bei GKE-Versionen vor 1.23.5-gke.1300 beträgt das Limit 110 Pods. |
Stellen Sie sich dynamisch einen beliebigen Wert zwischen 8 und 256 ein. GKE berücksichtigt die Clustergröße und die Anzahl der Arbeitslasten, um die maximale Anzahl von Pods pro Knoten bereitzustellen.
|
Pods pro Cluster2 | 200.000 Pods1 | 200.000 Pods |
Container pro Cluster | 400.000 Container | 400.000 Container |
Größe der Etcd-Datenbank | 6 GB | 6 GB |
Als Plattformadministrator empfehlen wir Ihnen, sich mit den Auswirkungen von Kontingenten auf große Arbeitslasten in GKE vertraut zu machen. Weitere Empfehlungen, Best Practices, Limits und Kontingente für große Arbeitslasten finden Sie unter Richtlinien für das Erstellen skalierbarer Cluster.
Limit für API-Anfragen
Die standardmäßige Ratenbegrenzung für die Kubernetes Engine API beträgt 3000 Anfragen pro Minute, die in Intervallen von 100 Sekunden erzwungen wird.
Ressourcenkontingente
Bei Clustern mit weniger als 100 Knoten wendet GKE das Kubernetes-Ressourcenkontingent auf jeden Namespace an. Diese Kontingente schützen die Steuerungsebene des Clusters vor Instabilität durch mögliche Programmfehler in auf dem Cluster bereitgestellten Anwendungen. Sie können diese Kontingente nicht entfernen, da sie von GKE erzwungen werden.
GKE aktualisiert die Werte der Ressourcenkontingente automatisch proportional zur Anzahl der Knoten. Bei Clustern mit mehr als 100 Knoten entfernt GKE das Ressourcenkontingent.
Verwenden Sie den folgenden Befehl, um Ressourcenkontingente zu prüfen:
kubectl get resourcequota gke-resource-quotas -o yaml
Geben Sie über die Option --namespace
einen bestimmten Namespace an, um sich dessen Werte anzusehen.
Kontingent prüfen
Console
- Öffnen Sie in der Google Cloud Console die Seite Kontingente. Auf der Seite Kontingente wird die Liste der Kontingente angezeigt, die nach GKE-Kontingenten gefiltert wurden.
- Mit dem Feld Tabelle filtern können Sie nach dem genauen Kontingent suchen. Wenn Sie den Namen des Kontingents nicht kennen, können Sie die Links auf der Seite Kontingente verwenden.
gcloud
- Führen Sie den folgenden Befehl aus, um Ihre Kontingente zu prüfen:
gcloud compute project-info describe --project PROJECT_ID
Ersetzen Sie
PROJECT_ID
durch Ihre Projekt-ID: - Mit dem folgenden Befehl prüfen Sie das genutzte Kontingent in einer Region:
gcloud compute regions describe example-region
Hinweise
-
Die maximale Anzahl von Pods pro GKE Standard-Cluster umfasst auch System-Pods. Die Anzahl der System-Pods variiert je nach Clusterkonfiguration und aktivierten Features. ↩
-
Die maximale Anzahl von Pods, die in einen Knoten passen, hängt von der Größe Ihrer Pod-Ressourcenanfragen und der Kapazität des Knotens ab. Möglicherweise erreichen Sie nicht alle Limits gleichzeitig. Als Best Practice empfehlen wir, einen Lasttest für große Bereitstellungen auszuführen. ↩