Kontingente und Limits

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

  • Kontingente haben Standardwerte, aber Sie können in der Regel Anpassungen anfordern.
  • Systemlimits sind feste Werte, die nicht geändert werden können.

Google Cloud nutzt Kontingente, um für Fairness zu sorgen und Spitzen bei der Ressourcennutzung und ‑verfügbarkeit zu reduzieren. Ein Kontingent schränkt ein, wie viel von einer Ressource vonGoogle Cloud Ihr Projekt von Google Cloud nutzen kann. 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. Kontingente sollen eine Überlastung von Diensten verhindern und dadurch die Community der Nutzer vonGoogle Cloud schützen. Sie helfen Ihnen auch bei der Verwaltung Ihrer eigenen Ressourcen von Google Cloud .

Das Cloud-Kontingentsystem tut Folgendes:

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 auszuführen versuchen, schlägt dann fehl.

Kontingente gelten in der Regel auf der Ebene des Projekts von Google Cloud . Die Nutzung einer Ressource in einem Projekt hat keinen Einfluss auf das verfügbare Kontingent in einem anderen Projekt. Innerhalb eines Projekts von Google Cloud werden die Kontingente für alle Anwendungen und IP-Adressen gemeinsam genutzt.

Weitere Informationen finden Sie unter Cloud-Kontingente – Übersicht.

Die meisten Kontingente können Sie in der Google Cloud Console anpassen. Weitere Informationen finden Sie unter Kontingentanpassung anfordern.

Für GKE-Ressourcen gelten außerdem Systemlimits. Systemlimits können nicht geändert werden.

Kontingente pro Projekt

Für GKE gelten die folgenden Kontingente:

Hinweis: Cluster, die im Autopilot-Modus erstellt wurden, sind als regionale Cluster vorkonfiguriert.

Kontingent prüfen

Kontingente können in der Google Cloud Console auf der Seite Kontingente aufgerufen werden.

Kontingente aufrufen

Informationen zum Verwalten und Anfordern zusätzlicher Kontingente finden Sie unter Kontingente aufrufen und verwalten.

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 65.000 Knoten

Wenn Sie dieses Limit verwenden möchten, sollten Sie beim Entwerfen Ihrer GKE-Architektur die folgenden Empfehlungen berücksichtigen:

 5.000 Knoten

Wenn Sie dieses Limit verwenden möchten, sollten Sie beim Entwerfen Ihrer GKE-Architektur die folgenden Empfehlungen berücksichtigen:

  • Wenn Sie mehr als 1.000 Knoten ausführen möchten, verwenden Sie GKE Autopilot-Version 1.23 oder höher.
  • 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

2.000 TPU-Knoten pro Zone – erfordert die folgenden oder neueren Versionen: 1.28.5-gke.135500, 1.29.1-gke.1206000, 1.30		 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.

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.

  • 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 200.000 Pods
Container pro Cluster 400.000 Container 400.000 Container
Größe der Etcd-Datenbank 6 GB 6 GB
Gleichzeitige Vorgänge 10 Vorgänge 10 Vorgänge

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.

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.

Hinweise

  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 erreichen Sie nicht alle Limits gleichzeitig. Als Best Practice empfehlen wir, einen Lasttest für große Bereitstellungen auszuführen. ↩