Kontingente und Limits

In diesem Dokument sind die Kontingente und Limits für Google Kubernetes Engine aufgeführt.

Ein Kontingent schränkt ein, wie viel von einer bestimmten gemeinsam genutzten Google Cloud-Ressource Ihr Google Cloud-Projekt nutzen kann, einschließlich Hardware, Software und Netzwerkkomponenten. Daher sind Kontingente Teil eines Systems, das Folgendes tut:

  • Ihre Nutzung oder Ihren Verbrauch von Google Cloud-Produkten und -Diensten überwachen.
  • Ihren Verbrauch dieser Ressourcen einschränken, um u. a. für Fairness zu sorgen und Nutzungsspitzen zu reduzieren.
  • Konfigurationen verwalten, die automatisch vorgeschriebene Einschränkungen erzwingen.
  • Möglichkeit, das Kontingent anzufordern oder zu ändern.

Wenn ein Kontingentlimit überschritten wird, blockiert das System in den meisten Fällen den Zugriff auf die entsprechende Google-Ressource und die Aufgabe, die Sie ausführen möchten, schlägt fehl. In den meisten Fällen gelten Kontingente für jedes Google Cloud-Projekt und werden von allen Anwendungen und IP-Adressen geteilt, die dieses Google Cloud-Projekt verwenden.

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 einzelnen 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
  • Keine Knotenbeschränkungen beim containernativen Load-Balancing mit NEG-basiertem Ingress, was nach Möglichkeit empfohlen wird Ab GKE-Version 1.17 ist NEG-basierter Ingress der Standardmodus.
  • 1.000 Knoten, wenn Sie auf Instanzgruppen basierten Ingress verwenden.
 Nicht zutreffend
Pods pro Knoten1 256 Pods

Hinweis: Bei GKE-Versionen vor 1.23.5-gke.1300 beträgt das Limit 110 Pods.

Legen Sie dynamisch einen beliebigen Wert zwischen 8 und 256 fest. GKE berücksichtigt die Clustergröße und die Anzahl der Arbeitslasten, um die maximale Anzahl von Pods pro Knoten bereitzustellen.

  • Bei GKE-Versionen vor 1.28 beträgt das Limit 32 Pods.
  • Bei Pods der Accelerator-Klasse und Pods der Leistungsklasse ist ein Pod pro Knoten zulässig.
Pods pro Cluster2 200.000 Pods1 25.000 Pods
Container pro Cluster 400.000 Container 25.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 Anwendungen, die im Cluster bereitgestellt werden. Sie können diese Kontingente nicht entfernen, da sie von GKE erzwungen werden.

GKE aktualisiert die Ressourcenkontingentwerte 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

  1. Öffnen Sie in der Google Cloud Console die Seite Kontingente.

    Kontingente aufrufen

    2. Auf der Seite Kontingente wird die Liste der Kontingente angezeigt, die nach GKE-Kontingenten gefiltert sind.
  2. Mit dem Feld Filtertabelle 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

  1. 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:

  2. Mit dem folgenden Befehl prüfen Sie das genutzte Kontingent in einer Region: 
    gcloud compute regions describe example-region

Notes

  1. 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. ↩

  2. 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 werden nicht alle Limits gleichzeitig erreicht. Als Best Practice empfehlen wir, dass Sie einen großen Test von Deployments durchführen. ↩