Auf dieser Seite werden die Kontingente und Limits von Anthos-Clustern auf Bare-Metal-Releases 1.11 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 maximal 75 beschränken. Wenn Sie 110 Pods pro Knoten ausführen möchten, sollten Sie die Anzahl der Knoten im 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 maximale Anzahl von Pods pro Clusterempfehlung hat in den folgenden Abschnitten Vorrang vor den Empfehlungen für Pods pro Knoten und Knoten pro Cluster.
Maximale Anzahl von Knoten pro Cluster
Wir testen Anthos-Cluster auf Bare Metal, 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, Standalone 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
Anthos-Cluster auf Bare Metal 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 für MaxPodsPerNode aufgeführt. Dazu gehören auch Pods, auf denen Add-on-Dienste ausgeführt werden:
| Clustertyp | Zugelassener Mindestwert | Empfohlener Höchstwert | 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 dies als zwei separate Endpunkte. Diese Einschränkung wird von der zugrunde liegenden nftable-Implementierung unter RHEL und CentOS verursacht. Es handelt sich nicht um eine intrinsische Einschränkung von Anthos-Clustern auf 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 auf großen Clustern, vom Standard-iptables zum Legacy-iptables zu wechseln.
eBPF-Limit für Dataplane V2
Die maximale Anzahl von Einträgen in der BPF-lbmap für Dataplane V2 beträgt 65.536. Wenn Sie in den folgenden Bereichen zunehmen, kann die Gesamtzahl der Einträge steigen:
- Anzahl der Dienste
- Anzahl der Ports pro Dienst
- Anzahl der Back-Ends pro Dienst
Wir empfehlen, die tatsächliche Anzahl von Einträgen zu überwachen, die von Ihrem Cluster verwendet werden, 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 Monitoringpipeline, um Messwerte aus dem DaemonSet anetd zu erfassen. Prüfen Sie 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 LoadBalancer und NodePort-Dienste beträgt 2.768. Der Standardportbereich ist 30.000–32.767. 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.
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 für gebündelte 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, können Anfragen an den LoadBalancer-Dienst möglicherweise fehlschlagen.
Wenn Sie einen Load-Balancer-Dienst verfügbar machen müssen, der eine große Anzahl von Verbindungen verarbeiten kann (z. B. für Ingress), empfehlen wir Ihnen eine alternative Load-Balancing-Methode, 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:
Sie haben die gewünschten Informationen nicht gefunden? Klicken Sie auf Feedback geben und teilen Sie uns mit, was fehlt.