Auf dieser Seite werden die Kontingente und Limits von Google Distributed Cloud Release 1.29 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 Google Distributed Cloud.
Maximale Nutzercluster pro Administratorcluster
Administratorcluster verwalten den Lebenszyklus von Nutzerclustern und den zugehörigen Knoten. Administratorcluster steuern wichtige Nutzerclustervorgänge wie das Erstellen, Zurücksetzen von Clustern oder Knoten, Clusterupgrades und Clusteraktualisierungen. Die Gesamtzahl der Nutzerclusterknoten ist einer der Hauptfaktoren, die die Leistung und Zuverlässigkeit beeinträchtigen.
Basierend auf laufenden Tests kann ein Administratorcluster zuverlässig maximal 100 Nutzercluster mit jeweils 10 Knoten und insgesamt 1.000 Knoten unterstützen.
Maximale Anzahl von Pods pro Nutzercluster
Wir empfehlen,die Anzahl der Pods pro Nutzercluster auf maximal 15.000 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 die Anzahl der Knoten in Ihrem Cluster entsprechend auf 136 oder weniger beschränken. Die folgende Tabelle enthält Beispiele für Konfigurationen, die empfohlen 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 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 Google Distributed Cloud, um Arbeitslasten mit bis zu 500 Knoten auszuführen. Für eine optimale Leistung und Zuverlässigkeit empfehlen wir jedoch, 200 Knoten pro Cluster beim Ausführen von Arbeitslasten in der Produktion nicht zu überschreiten.
| Clustertyp | Minimale Knotenanzahl | Empfohlene maximale Knotenanzahl | Absolute maximale Knoten |
|---|---|---|---|
| Nutzer, eigenständig oder gemischt | 1 | 200 | 500 |
Bei Clustern mit einem einzelnen 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
Google Distributed Cloud unterstützt die Konfiguration der maximalen Anzahl von Pods pro Knoten in der Einstellung nodeConfig.PodDensity.MaxPodsPerNode der Clusterkonfigurationsdatei. Die folgende Tabelle zeigt die für MaxPodsPerNode unterstützten Mindest- und Höchstwerte, einschließlich 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 Red Hat Enterprise Linux (RHEL) 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 denselben Satz von Pods verweisen, wird dies als zwei separate Gruppen von Endpunkten gezählt. Die zugrunde liegende nftable-Implementierung unter RHEL verursacht diese Einschränkung. Sie ist keine intrinsische Einschränkung von Google Distributed Cloud.
Möglichkeiten zur Behebung des Problems
Für RHEL gibt es keine Abhilfemaßnahmen. Für Ubuntu- und Debian-Systeme empfehlen wir bei großen Clustern, vom standardmäßigen nftables zum Legacy-iptables zu wechseln.
GKE Dataplane V2
Google Distributed Cloud verwendet GKE Dataplane V2, eine mit Cilium und eBPF implementierte Cluster-Dataplane, die für Kubernetes-Netzwerke optimiert ist.
NetworkPolicy-Limits für GKE Dataplane V2
GKE Dataplane V2 verwendet Cilium, um Kubernetes-NetworkPolicy-Ressourcen zu verwalten. Die folgenden Limits gelten für Ihre GKE on Bare Metal-Cluster:
| Dimension | Unterstützte Limits |
|---|---|
| Maximale Änderungsrate für Namespace-Labels | Höchstens eine Änderung pro Stunde für jeden Namespace.
In den meisten Fällen ist diese Beschränkung nicht erforderlich. Solange Änderungen nicht häufig auftreten (z. B. jede Sekunde) oder die Anzahl der Cilium-Identitäten (eindeutige Labelsätze) nicht nahe am Limit ist: 16.000 Labelsätze mit Netzwerkrichtlinien allow all oder 65.535 Labelsätze pro Cluster. |
| Maximale Anzahl von Dienstendpunkten pro Cluster | 100.000 Endpunkte sind das getestete und empfohlene Limit. Das hartcodierte Limit für Dienstendpunkte beträgt 262.000. |
| Maximale Anzahl von Netzwerkrichtlinien und -regeln | Höchstens 40.000 Netzwerkrichtlinien und 80.000 Regeln. Sie können beispielsweise 40.000 Netzwerkrichtlinien mit jeweils zwei Regeln angeben oder 20.000 Richtlinien mit jeweils vier Regeln. |
| Maximale Änderungsrate für Netzwerkrichtlinien | Höchstens 20 Änderungen (Erstellungen oder Löschungen) pro Sekunde. |
| Maximale Anzahl eindeutiger Pod-Labelsätze | 65.535 (216-1). Dies ist das Limit von Cilium Security Identity. |
| Maximale Anzahl eindeutiger Pod-Labelsätze, die über die Richtlinienauswahl ausgewählt werden | 16.000 (die feste eBPF-Kartengröße). Ein gegebener Eintrag für eine Richtlinienauswahlzuordnung besteht aus folgenden Elementen: Sicherheitsidentität, Port und Protokoll. |
eBPF-Limit für GKE Dataplane V2
Die maximale Anzahl der Einträge im BPF-lbmap-Element für Dataplane V2 beträgt 65.536. Eine Erhöhung in den folgenden Bereichen kann dazu führen, dass die Gesamtzahl der Einträge steigt:
- Anzahl der Dienste
- Anzahl der Ports pro Dienst
- Anzahl der Back-Ends pro Dienst
Wir empfehlen Ihnen, die tatsächliche Anzahl der von Ihrem Cluster verwendeten Einträge zu überwachen, um sicherzustellen, dass Sie das Limit nicht überschreiten. 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, Ihre eigene Monitoring-Pipeline 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 Services
Das Portlimit für LoadBalancer- und NodePort-Dienste beträgt 2.768. Der Standardportbereich liegt zwischen 30000 und 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.
Durch diese Zuweisungen können die verfügbaren Knotenports schnell von den 2.768 zugewiesenen Ports Ihres Clusters aufgebraucht werden. Wenn Sie Knotenports speichern möchten, deaktivieren Sie die Portzuweisung für Load-Balancer. Dazu setzen Sie das Feld allocateLoadBalancerNodePorts in der LoadBalancer-Dienstspezifikation auf false. Diese Einstellung verhindert, dass Kubernetes Knotenports zu LoadBalancer-Diensten zuweist. Weitere Informationen finden Sie unter NodePort-Zuweisung des Load-Balancers deaktivieren in der Kubernetes-Dokumentation.
Verwenden Sie den folgenden Befehl, um die Anzahl der zugewiesenen Ports zu prüfen:
kubectl get svc -A | grep : | tr -s ' ' | cut -d ' ' -f6 | tr ',' '\n' | wc -l
Gebündelte Load-Balancer-Knotenverbindungslimits
Die Anzahl der zulässigen Verbindungen für jeden Knoten, der für das gebündelte Load-Balancing (MetalLB) verwendet wird, beträgt 28.000. 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 zur Verfügung stellen 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:
Informationen zur Skalierung
Die Informationen in diesem Dokument sind für die Planung der Hochskalierung Ihrer Cluster relevant. Weitere Informationen finden Sie unter Google Distributed Cloud-Cluster hochskalieren.
Sie haben die gewünschten Informationen nicht gefunden? Klicken Sie auf Feedback geben und teilen Sie uns mit, was fehlt.