Auf dieser Seite werden die Kontingente und Limits von GKE on Bare Metal Version 1.16 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 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 dieselbe Gruppe 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 für große Cluster einen Wechsel vom Standard-nftables zum Legacy-iptables.
eBPF-Limit in 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:
Skalierungsprobleme
In diesem Abschnitt werden einige Punkte beschrieben, die Sie beim Skalieren von Clustern berücksichtigen sollten.
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, damit diesen Daemons die erforderlichen Ressourcen zur Verfügung stehen. Ohne dieses standardmäßig aktivierte Feature können Pods möglicherweise die meisten Ressourcen auf einem Knoten nutzen, 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. Beachten Sie, dass die CPU-Einheit „mCPU“ für „Tausendstel eines Kerns“ steht. 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 deren CPU- oder Arbeitsspeichernutzung die zugewiesenen Beträge überschreitet.
Etcd-Leistung
Die Laufwerksgeschwindigkeit ist entscheidend für die Leistung und Stabilität von etcd. Ein langsames Laufwerk erhöht die Latenz von etcd-Anfragen, was zu Problemen bei der Clusterstabilität führen kann. Zur Verbesserung der Clusterleistung speichert GKE on Bare Metal Ereignisobjekte in einer separaten, dedizierten etcd-Instanz. Die Standard-etcd-Instanz verwendet /var/lib/etcd als Datenverzeichnis und Port 2379 für Clientanfragen. Die Instanz etcd-events verwendet /var/lib/etcd-events als Datenverzeichnis und Port 2382 für Clientanfragen.
Wir empfehlen die Verwendung eines Solid State Disk (SSD) für Ihre etcd-Speicher. Für eine optimale Leistung sollten Sie separate Laufwerke für /var/lib/etcd und /var/lib/etcd-events bereitstellen. Die Verwendung dedizierter Laufwerke sorgt dafür, dass die beiden etcd-Instanzen keine Laufwerks-E/A gemeinsam nutzen.
Die etcd-Dokumentation enthält zusätzliche Hardwareempfehlungen, um die beste etcd-Leistung beim Ausführen Ihrer Cluster in der Produktion sicherzustellen.
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.