Auf dieser Seite werden die Kontingente und Limits von GKE on Bare Metal Version 1.29 für Google Cloud-Projekte, -Cluster und -Knoten erläutert.
Limits
In den folgenden Abschnitten werden einige grundlegende Limits für Ihre Cluster beschrieben. Berücksichtigen Sie diese Limits beim Entwerfen Ihrer Anwendungen für die Ausführung in GKE on Bare Metal.
Maximale Nutzercluster pro Administratorcluster
Administratorcluster verwalten den Lebenszyklus von Nutzerclustern und der zugehörigen Knoten. Administratorcluster steuern kritische Nutzerclustervorgänge wie das Erstellen von Clustern, das Zurücksetzen von Clustern oder Knoten, Clusterupgrades und Clusteraktualisierungen. Die Gesamtzahl der Nutzerclusterknoten ist einer der Hauptfaktoren, die die Leistung und Zuverlässigkeit einschränken.
Basierend auf laufenden Tests kann ein Administratorcluster zuverlässig maximal 100 Nutzercluster mit jeweils 10 Knoten und damit insgesamt 1.000 Knoten unterstützen.
Maximale Anzahl von Pods pro Nutzercluster
Wir empfehlen,die Anzahl der Pods pro Nutzercluster auf 15.000 oder weniger zu begrenzen. Wenn Ihr Cluster beispielsweise 200 Knoten hat, sollten Sie die Anzahl der Pods pro Knoten auf 75 oder weniger beschränken. Wenn Sie 110 Pods pro Knoten ausführen möchten, sollten Sie die Anzahl der Knoten in Ihrem Cluster auf 136 oder weniger beschränken. Die folgende Tabelle enthält Beispiele für Konfigurationen, die nicht empfohlen werden.
| Pods pro Knoten | Knoten pro Cluster | Pods pro Cluster | Ergebnis |
|---|---|---|---|
| 110 | 200 | 22.000 | Zu viele Pods, nicht empfohlen |
| 110 | 136 | 14.960 | Innerhalb des Limits |
| 100 | 150 | 15.000 | Innerhalb des Limits |
| 75 | 200 | 15.000 | Innerhalb des Limits |
Die Empfehlung für die maximale Anzahl von Pods pro Nutzercluster hat Vorrang vor den Empfehlungen für Pods pro Knoten und Knoten pro Nutzercluster in den folgenden Abschnitten.
Maximale Anzahl von Knoten pro Nutzercluster
Wir testen GKE on Bare Metal, um Arbeitslasten mit bis zu 500 Knoten auszuführen. Für optimale Leistung und Zuverlässigkeit empfehlen wir jedoch, 200 Knoten pro Cluster nicht zu überschreiten, wenn Sie Arbeitslasten in der Produktion ausführen.
| Clustertyp | Minimale Knotenanzahl | Empfohlene maximale Anzahl von Knoten | Maximale Anzahl von Knoten |
|---|---|---|---|
| Nutzer, eigenständig oder hybrid | 1 | 200 | 500 |
Bei Clustern mit einem Knoten müssen Sie die Markierung node-role.kubernetes.io/master:NoSchedule entfernen, um Arbeitslasten auf dem Knoten auszuführen.
Weitere Informationen finden Sie unter Kubernetes-Markierungen und -Toleranzen.
Maximale Anzahl von Pods pro Knoten
GKE on Bare Metal unterstützt die Konfiguration einer maximalen Anzahl von Pods pro Knoten in der Einstellung nodeConfig.PodDensity.MaxPodsPerNode der Clusterkonfigurationsdatei. Die folgende Tabelle enthält die Mindest- und Höchstwerte, die für MaxPodsPerNode unterstützt werden. Dazu gehören Pods, auf denen Add-on-Dienste ausgeführt werden:
| Clustertyp | Zugelassener Mindestwert | Empfohlener Maximalwert | Zulässiger Höchstwert |
|---|---|---|---|
| Alle HA-Cluster und Nicht-HA-Cluster | 32 | 110 | 250 |
| Alle anderen Cluster ohne Hochverfügbarkeit | 64 | 110 | 250 |
Maximale Anzahl von Endpunkten
Unter Red Hat Enterprise Linux (RHEL) gibt es eine Beschränkung auf Clusterebene von 100.000 Endpunkten. Diese Zahl ist die Summe aller Pods, auf die ein Kubernetes-Dienst verweist. Wenn zwei Dienste auf dieselbe Gruppe von Pods verweisen, zählt dies als zwei separate Gruppen von Endpunkten. Die zugrunde liegende nftable-Implementierung unter RHEL verursacht diese Einschränkung. Es ist keine intrinsische Einschränkung von GKE on Bare Metal.
Möglichkeiten zur Behebung des Problems
Für RHEL gibt es keine Risikominderungen. Für Ubuntu- und Debian-Systeme empfehlen wir für große Cluster den Wechsel vom Standard-nftables zum Legacy-iptables.
GKE Dataplane V2
GDCV für Bare Metal verwendet GKE Dataplane V2, eine mit Cilium und eBPF implementierte Cluster-Datenebene, die für Kubernetes-Netzwerke optimiert ist.
NetworkPolicy-Limits in GKE Dataplane V2
GKE Dataplane V2 verwendet Cilium, um Kubernetes-NetworkPolicy-Ressourcen zu verwalten. Die folgenden Limits gelten für Ihre GKE on Bare-Metal-Cluster:
| Dimension | Unterstützte Limits |
|---|---|
| Maximale Änderungsrate für Namespace-Labels | Höchstens eine Änderung pro Stunde für jeden Namespace.
In den meisten Fällen ist diese Beschränkung nicht erforderlich. Solange Änderungen nicht häufig erfolgen (z. B. pro Sekunde) oder die Anzahl der Cilium-Identitäten (eindeutige Labelsätze) nicht annähernd das Limit erreicht: 16.000 Labelsätze mit Alle zulassen Netzwerkrichtlinien oder 65.535 Labelsätze pro Cluster. |
| Maximale Anzahl von Dienstendpunkten pro Cluster | 100.000 Endpunkte ist das getestete und empfohlene Limit. Das hartcodierte Limit für Dienstendpunkte beträgt 262.000. |
| Maximale Anzahl von Netzwerkrichtlinien und -regeln | Maximal 40.000 Netzwerkrichtlinien und 80.000 Regeln. Sie können beispielsweise 40.000 Netzwerkrichtlinien mit jeweils zwei Regeln oder 20.000 Richtlinien mit jeweils vier Regeln angeben. |
| Maximale Änderungsrate für Netzwerkrichtlinien | Maximal 20 Änderungen (Erstellung oder Löschungen) pro Sekunde. |
| Maximale Anzahl eindeutiger Pod-Labelsätze | 65.535 (216-1). Das ist das Limit der Cilium-Sicherheitsidentität. |
| Maximale Anzahl eindeutiger Pod-Labelsätze, die über die Richtlinienauswahl ausgewählt wurden | 16.000 (die feste eBPF-Kartengröße). Ein bestimmter Eintrag für die Richtlinienauswahlzuordnung besteht aus folgenden Elementen: security-identity, Port und Protocol. |
eBPF-Limit in GKE Dataplane V2
Die maximale Anzahl der Einträge in der BPF-lbmap für Dataplane V2 beträgt 65.536. Zunahmen in den folgenden Bereichen können dazu führen, dass die Gesamtzahl der Einträge zunimmt:
- Anzahl der Dienste
- Anzahl der Ports pro Dienst
- Anzahl der Back-Ends pro Dienst
Es wird empfohlen, die tatsächliche Anzahl der von Ihrem Cluster verwendeten Einträge zu überwachen, um sicherzustellen, dass das Limit nicht überschritten wird. Verwenden Sie den folgenden Befehl, um die aktuellen Einträge abzurufen:
kubectl get po -n kube-system -l k8s-app=cilium | cut -d " " -f1 | grep anetd | head -n1 | \
xargs -I % kubectl -n kube-system exec % -- cilium bpf lb list | wc -l
Außerdem empfehlen wir Ihnen, eine eigene Monitoringpipeline zu verwenden, um Messwerte aus dem DaemonSet anetd zu erfassen. Achten Sie auf die folgenden Bedingungen, um festzustellen, wann die Anzahl der Einträge Probleme verursacht:
cilium_bpf_map_ops_total{map_name="lb4_services_v2",operation="update",outcome="fail" } > 0
cilium_bpf_map_ops_total{map_name="lb4_backends_v2",operation="update",outcome="fail" } > 0
Portlimit für LoadBalancer und NodePort-Dienste
Das Portlimit für die Dienste LoadBalancer und NodePort beträgt 2.768. Der Standardportbereich ist 30000–32767. Wenn Sie das Limit überschreiten, können Sie keine neuen LoadBalancer- oder NodePort-Dienste erstellen und keine neuen Knotenports für vorhandene Dienste hinzufügen.
Standardmäßig weist Kubernetes Diensten vom Typ LoadBalancer Knotenports zu.
Diese Zuweisungen können die verfügbaren Knotenports von den 2.768, die Ihrem Cluster zugewiesen sind, schnell erschöpfen. Wenn Sie Knotenports speichern möchten, deaktivieren Sie die Portzuweisung für Load-Balancer-Knoten. Dazu setzen Sie das Feld allocateLoadBalancerNodePorts in der LoadBalancer-Dienstspezifikation auf false. Diese Einstellung verhindert, dass Kubernetes Knotenports LoadBalancer-Diensten zuweist. Weitere Informationen finden Sie in der Kubernetes-Dokumentation unter Load-Balancer-NodePort-Zuweisung deaktivieren.
Prüfen Sie mit dem folgenden Befehl die Anzahl der zugewiesenen Ports:
kubectl get svc -A | grep : | tr -s ' ' | cut -d ' ' -f6 | tr ',' '\n' | wc -l
Verbindungslimits für gebündelte Load-Balancer-Knoten
Für jeden Knoten, der für das gebündelte Load-Balancing (MetalLB) verwendet wird, sind 28.000 Verbindungen zulässig. Der sitzungsspezifische Standardportbereich für diese Verbindungen ist 32768–60999. Wenn Sie das Verbindungslimit überschreiten, schlagen Anfragen an den LoadBalancer-Dienst möglicherweise fehl.
Wenn Sie einen Load-Balancer-Dienst verfügbar machen müssen, der eine erhebliche Anzahl von Verbindungen verarbeiten kann (z. B. für Ingress), sollten Sie eine alternative Load-Balancing-Methode in Betracht ziehen, um diese Einschränkung mit MetalLB zu vermeiden.
Clusterkontingente
Sie können standardmäßig höchstens 15 Cluster registrieren. Wenn Sie weitere Cluster in GKE Hub registrieren möchten, können Sie in der Google Cloud Console eine Anfrage zur Erhöhung Ihres Kontingents senden:
Skalierungsinformationen
Die Informationen in diesem Dokument sind für die Planung des Hochskalierens von Clustern relevant. Weitere Informationen finden Sie unter GKE on Bare-Metal-Cluster hochskalieren.
Sie haben die gewünschten Informationen nicht gefunden? Klicken Sie auf Feedback geben und teilen Sie uns mit, was fehlt.