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:
Sie haben die gewünschten Informationen nicht gefunden? Klicken Sie auf Feedback geben und teilen Sie uns mit, was fehlt.