Kontingente und Limits

Auf dieser Seite werden die Kontingente und Limits von Anthos-Cluster auf Bare-Metal-Versionen 1.12 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 beschränken. 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 entsprechend die Anzahl der Knoten im Cluster auf 136 oder weniger beschränken. In der folgenden Tabelle finden Sie Beispiele für Konfigurationen, die empfohlen werden und 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 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 Anthos-Cluster auf Bare-Metal-Geräten, um Arbeitslasten mit bis zu 500 Knoten auszuführen. Für eine 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 Absolute maximale Anzahl von Knoten
Nutzer, eigenständig oder gemischt 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

Anthos on Bare Metal-Cluster unterstützen die Konfiguration der maximalen Anzahl von Pods pro Knoten in der Einstellung nodeConfig.PodDensity.MaxPodsPerNode der Clusterkonfigurationsdatei. In der folgenden Tabelle sind die Mindest- und Höchstwerte aufgeführt, 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 gilt 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 dieselben Pods verweisen, zählt diese Situation als zwei separate Endpunkte. Die zugrunde liegende nftable-Implementierung unter RHEL und CentOS führt zu dieser Einschränkung; sie ist keine intrinsische Einschränkung von Anthos-Clustern auf Bare-Metal-Servern.

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-iptables 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. Anstiege in den folgenden Bereichen können dazu führen, dass die Anzahl der Einträge wächst:

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

Wir empfehlen, die tatsächliche Anzahl der vom Cluster verwendeten Einträge im Blick zu behalten, 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 empfehlen wir die Verwendung Ihrer eigenen Monitoring-Pipeline, um Messwerte aus dem Daemon anetd zu erfassen. Prüfen 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 den Balancer und NodePort-Dienste

Das Portlimit für Load-Balancer und NodePort-Dienste beträgt 2.768. Der Standardportbereich ist 30.000–32.767. Wenn Sie das Limit überschreiten, können Sie keine neuen Balancer- oder NodePort-Dienste erstellen und keine neuen Knotenports für vorhandene Dienste hinzufügen.

Mit dem folgenden Befehl können Sie die Anzahl der aktuell zugewiesenen Ports prüfen:

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

Verbindungslimits von gebündelten Load-Balancer-Knoten

Die Anzahl der zulässigen Verbindungen pro Knoten für das gebündelte Load-Balancing (MetalLB) beträgt 28.000. Der standardmäßige sitzungsspezifische Portbereich für diese Verbindungen ist 32768-60999. Wenn Sie das Verbindungslimit überschreiten, schlagen Anfragen an den Load-Balancer möglicherweise fehl.

Wenn Sie einen Load-Balancer-Dienst verfügbar machen möchten, der beispielsweise eine beträchtliche Anzahl von Verbindungen verarbeiten kann (z. B. für Ingress), empfehlen wir Ihnen, eine alternative Load-Balancing-Methode zu verwenden, 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 zum Erhöhen Ihres Kontingents senden:

Kontingente aufrufen

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