Auf dieser Seite werden Kontingente und Limits der Google Distributed Cloud-Version 1.30 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, wenn Sie Ihre Anwendungen für die Ausführung in Google Distributed Cloud entwerfen.
Maximale Anzahl von Nutzerclustern pro Administratorcluster
Administratorcluster verwalten den Lebenszyklus von Nutzerclustern und ihren zugehörigen Knoten. Administratorcluster steuern wichtige Nutzerclustervorgänge wie das Erstellen von Clustern, das Zurücksetzen von Clustern oder Knoten, Clusterupgrades und Clusterupdates. Die Gesamtzahl der Nutzerclusterknoten ist einer der Hauptfaktoren, die sich auf die Leistung und Zuverlässigkeit auswirken.
Basierend auf laufenden Tests kann ein Administratorcluster zuverlässig maximal 100 Nutzercluster mit jeweils 10 Knoten unterstützen, also insgesamt 1.000 Knoten.
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 empfohlene und nicht empfohlene Konfigurationen.
| Pods pro Knoten | Knoten pro Cluster | Pods pro Cluster | Ergebnis |
|---|---|---|---|
| 110 | 200 | 22.000 | Zu viele Pods, nicht empfohlen |
| 110 | 136 | 14.960 | Im Limit |
| 100 | 150 | 15.000 | Im Limit |
| 75 | 200 | 15.000 | Im Limit |
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 für die Ausführung von Arbeitslasten mit bis zu 500 Knoten. Für optimale Leistung und Zuverlässigkeit empfehlen wir jedoch, bei der Ausführung von Arbeitslasten in der Produktionsumgebung nicht mehr als 200 Knoten pro Cluster zu verwenden.
| Clustertyp | Minimale Knotenanzahl | Empfohlene maximale Knotenanzahl | Absolute maximale Knotenanzahl |
|---|---|---|---|
| Nutzer-, eigenständige oder Hybrid-Cluster | 1 | 200 | 500 |
Für Cluster 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 Konfigurationsdatei des Clusters. Die folgende Tabelle zeigt die für MaxPodsPerNode unterstützten Mindest- und Höchstwerte, einschließlich Pods, die Add-on-Dienste ausführen:
| 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 Red Hat Enterprise Linux (RHEL) 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, wird dies als zwei separate Gruppen von Endpunkten gezählt. Die zugrunde liegende nftable-Implementierung unter RHEL führt zu dieser Einschränkung. Dies ist keine Systeminstabilität von Google Distributed Cloud.
Möglichkeiten zur Behebung des Problems
Für RHEL gibt es keine Einschränkungen. Für Ubuntu- und Debian-Systeme wird empfohlen, in großen Clustern von Standard-nftables zu Legacy-iptables zu wechseln.
GKE Dataplane V2
In Google Distributed Cloud wird GKE Dataplane V2 verwendet, eine Clusterdatenebene, die mit Cilium und eBPF implementiert und für das Kubernetes-Netzwerk optimiert ist.
GKE Dataplane V2-NetworkPolicy-Limits
GKE Dataplane V2 verwendet Cilium, um Kubernetes-NetworkPolicy-Ressourcen zu verwalten. Für Ihre Google Distributed Cloud-Cluster gelten die folgenden Limits:
| Dimension | Unterstützte Limits |
|---|---|
| Maximale Änderungsrate für Namespace-Labels | Maximal eine Änderung pro Stunde für jeden Namespace.
In den meisten Fällen ist dieses Limit nicht erforderlich. Solange Änderungen nicht häufig erfolgen, z. B. jede Sekunde, oder die Anzahl der Cilium-IDs (eindeutige Labelsätze) nicht an das Limit grenzt: 16.000 Labelsätze mit allow all-Netzwerkrichtlinien oder 65.535 Labelsätze pro Cluster. |
| Maximale Anzahl von Dienstendpunkten pro Cluster | Das getestete und empfohlene Limit umfasst 100.000 Endpunkte. Das hartcodierte Limit für Dienstendpunkte beträgt 262.000. |
| Maximale Anzahl von Netzwerkrichtlinien und Regeln | Maximal 40.000 Netzwerkrichtlinien und 80.000 Regeln. Sie können beispielsweise 40.000 Netzwerkrichtlinien mit jeweils zwei Regeln oder 20.000 Richtlinien mit jeweils vier Regeln angeben. |
| Maximale Änderungsrate für Netzwerkrichtlinien | Maximal 20 Änderungen (Erstellungen oder Löschungen) pro Sekunde. |
| Maximale Anzahl eindeutiger Pod-Labelsätze | 65.535 (216-1). Dies ist das Limit für die Cilium-Sicherheits-ID. |
| Maximale Anzahl von eindeutigen Pod-Labelsätzen, die die über Richtlinienauswahl ausgewählt werden | 16.000 (die feste Größe der eBPF-Zuordnung). Ein bestimmter Eintrag in der Zuordnungstabelle für die Richtlinienauswahl besteht aus den folgenden Elementen: Sicherheits-ID, Port und Protokoll. |
eBPF-Limit für GKE Dataplane V2
Die maximale Anzahl von Einträgen in der BPF-LBMAP für Dataplane V2 beträgt 65.536. Eine Erhöhung in den folgenden Bereichen kann zu einer Steigerung der Gesamtzahl der Einträge führen:
- Anzahl der Services
- Anzahl der Ports pro Dienst
- Anzahl der Backends pro Dienst
Wir empfehlen, die tatsächliche Anzahl der Einträge im Cluster 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
Wir empfehlen außerdem, Ihre eigene Monitoring-Pipeline zu verwenden, um Messwerte aus dem anetd-DaemonSet zu erfassen. Beobachten Sie die folgenden Bedingungen, um festzustellen, ob 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 Standard-Portbereich 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.
Durch diese Zuweisungen können die verfügbaren Knotenports (2.768 Ports sind Ihrem Cluster zugewiesen) schnell aufgebraucht werden. Wenn Sie Knotenports sparen möchten, deaktivieren Sie die Zuweisung von Load Balancer-Knotenports, indem Sie in der LoadBalancer-Dienstspezifikation das Feld allocateLoadBalancerNodePorts auf false festlegen. Mit dieser Einstellung verhindert Kubernetes, dass Knotenports LoadBalancer-Diensten zugewiesen werden. Weitere Informationen finden Sie in der Kubernetes-Dokumentation unter Zuweisung von NodePorts für Load Balancer deaktivieren.
Mit dem folgenden Befehl können Sie die Anzahl der 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 Verbindungen, die für jeden Knoten zulässig sind, der für das gebündelte Load Balancing (MetalLB) verwendet wird, beträgt 28.000. Der Standardbereich für sitzungsspezifische Ports für diese Verbindungen ist 32768–60999. Wenn Sie das Verbindungslimit überschreiten, schlagen Anfragen an den Load Balancer-Dienst möglicherweise fehl.
Wenn Sie einen Load-Balancer-Dienst bereitstellen möchten, der eine große Anzahl von Verbindungen verarbeiten kann (z. B. für Ingress), sollten Sie eine alternative Load Balancing-Methode in Betracht ziehen, um diese Einschränkung bei MetalLB zu vermeiden.
Clusterkontingente
Standardmäßig können Sie pro Flotte maximal 250 Cluster mit globalen Mitgliedschaften registrieren. Für die Registrierung weiterer Cluster in GKE Hub können Sie über die Google Cloud Console eine Anfrage zur Erhöhung Ihres Kontingents stellen:
Weitere Informationen zu Clusterkontingenten, die auf Mitgliedschaftseinstellungen basieren, finden Sie unter Zuteilungskontingente.
Informationen zur Skalierung
Die Informationen in diesem Dokument sind relevant für die Planung der Hochskalierung Ihrer Cluster. Weitere Informationen finden Sie unter Google Distributed Cloud-Cluster hochskalieren.
Sie haben die gewünschten Informationen nicht gefunden? Klicken Sie auf Feedback senden und teilen Sie uns mit, was fehlt.