Kontingente und Limits

Auf dieser Seite werden die Kontingente und Limits von GKE on Bare Metal Version 1.14 für Google Cloud-Projekte, -Cluster und -Knoten erläutert.

Limits

Beachten Sie die folgenden Limits und Empfehlungen für Ihre Cluster.

Maximale Anzahl von Pods pro Cluster

Wir empfehlen,die Anzahl der Pods pro Cluster 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 Folge
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 maximale Anzahl von Pods pro Clusterempfehlung hat Vorrang vor den Empfehlungen für Pods pro Knoten und Knoten pro Cluster in den folgenden Abschnitten.

Maximale Anzahl von Knoten pro Cluster

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, beim Ausführen von Arbeitslasten in der Produktion 200 Knoten pro Cluster nicht zu überschreiten.

Clustertyp Minimale Knotenanzahl Empfohlene maximale Anzahl von Knoten Maximale Anzahl von Knoten
„Nutzer“, „Eigenständig“ oder „Hybrid“ 1 200 500

Bei Clustern mit einzelnem 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 der maximalen Anzahl von Pods pro Knoten in der Einstellung nodeConfig.PodDensity.MaxPodsPerNode der Clusterkonfigurationsdatei. Die folgende Tabelle zeigt die Mindest- und Höchstwerte, die für MaxPodsPerNode unterstützt werden. Dazu gehören auch 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

Bei RHEL und CentOS 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 denselben Satz von Pods verweisen, zählt dies als zwei separate Gruppen von Endpunkten. Die zugrunde liegende nftable-Implementierung unter RHEL und CentOS verursacht diese Einschränkung. Es ist keine intrinsische Einschränkung von GKE on Bare Metal.

Möglichkeiten zur Behebung des Problems

Für RHEL und CentOS gibt es keine Einschränkungen. Für Ubuntu- und Debian-Systeme empfehlen wir bei großen Clustern, vom Standard-nftables zum Legacy-iptables zu wechseln.

eBPF-Limit für 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 ansteigt:

  • Anzahl der Dienste
  • Anzahl der Ports pro Dienst
  • Anzahl der Back-Ends pro Dienst

Wir empfehlen, die tatsächliche Anzahl der von Ihrem Cluster verwendeten Einträge zu überwachen, damit 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 empfiehlt es sich, eine eigene Monitoringpipeline zu verwenden, um Messwerte aus dem DaemonSet anetd zu erfassen. Achten Sie auf die folgenden Bedingungen, um festzustellen, ob 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 LoadBalancer- und NodePort-Dienste 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 vorhandenen Diensten keine neuen Knotenports hinzufügen.

Standardmäßig weist Kubernetes Diensten vom Typ LoadBalancer Knotenports zu. Diese Zuweisungen können die verfügbaren Knotenports der 2.768, die Ihrem Cluster zugewiesen sind, schnell erschöpfen. Deaktivieren Sie zum Speichern von Knotenports die Zuweisung von Load-Balancer-Knotenports. Setzen Sie dazu das Feld allocateLoadBalancerNodePorts in der LoadBalancer-Dienstspezifikation auf false. Diese Einstellung verhindert, dass Kubernetes LoadBalancer-Diensten Knotenports zuweist. Weitere Informationen finden Sie in der Kubernetes-Dokumentation unter Load-Balancer-NodePort-Zuweisung deaktivieren.

Verwenden Sie den folgenden Befehl, um die Anzahl der aktuell zugewiesenen Ports zu prüfen:

kubectl get svc -A | grep : | tr -s ' ' | cut -d ' '  -f6 | tr ',' '\n' | wc -l

Verbindungslimits für Load-Balancer-Knoten im Bundle

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 bereitstellen 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:

Kontingente aufrufen

Skalierungsprobleme

In diesem Abschnitt werden einige Punkte beschrieben, die beim Skalieren von Clustern zu beachten sind.

Für System-Daemons reservierte Ressourcen

Ab Version 1.14 reserviert GKE on Bare Metal automatisch Ressourcen auf einem Knoten für System-Daemons wie sshd oder udev. CPU- und Arbeitsspeicherressourcen werden auf einem Knoten für System-Daemons reserviert, sodass diese Daemons über die benötigten Ressourcen verfügen. Ohne dieses standardmäßig aktivierte Feature können Pods möglicherweise die meisten Ressourcen auf einem Knoten verbrauchen, sodass System-Daemons ihre Aufgaben nicht ausführen können.

GKE on Bare Metal reserviert 50 Millicore CPU (50 mCPU) und 280 Mebibyte (280 MiB) Arbeitsspeicher auf jedem Knoten für System-Daemons. Die CPU-Einheit „mCPU“ steht für „Tausendstel eines Kerns“. Daher sind 50/1.000 oder 5% eines Kerns auf jedem Knoten für System-Daemons reserviert. Die Menge der reservierten Ressourcen ist gering und hat keinen großen Einfluss auf die Pod-Leistung. Das Kubelet auf einem Knoten kann jedoch Pods entfernen, wenn die CPU- oder Arbeitsspeichernutzung die ihnen zugewiesenen Beträge überschreitet.

Etcd-Leistung

Die Laufwerksgeschwindigkeit ist entscheidend für Leistung und Stabilität von etcd. Ein langsames Laufwerk erhöht die Latenz von etcd-Anfragen, was zu Problemen mit der Clusterstabilität führen kann. Wir empfehlen die Verwendung eines Solid State Disk (SSD) für Ihren etcd-Speicher. Die etcd-Dokumentation enthält zusätzliche Hardwareempfehlungen, um eine optimale etcd-Leistung beim Ausführen Ihrer Cluster in der Produktion zu gewährleisten.

Prüfen Sie die etcd- und Laufwerksleistung mit den folgenden etcd-E/A-Latenzmesswerten im Metrics Explorer:

  • etcd_disk_backend_commit_duration_seconds: Die Dauer sollte für das 99. Perzentil (p99) weniger als 25 Millisekunden betragen.
  • etcd_disk_wal_fsync_duration_seconds: Die Dauer sollte für das 99. Perzentil (p99) weniger als 10 Millisekunden betragen.

Weitere Informationen zur etcd-Leistung finden Sie unter Was bedeutet die etcd-Warnung "Anwenden von Einträgen zu lang"? und Was bedeutet die etcd-Warnung "Heartbeat konnte nicht rechtzeitig gesendet werden"?

Sie haben die gewünschten Informationen nicht gefunden? Klicken Sie auf Feedback geben und teilen Sie uns mit, was fehlt.