Google Distributed Cloud-Cluster hochskalieren

Wie bei allen Kubernetes-Clustern hat die Skalierbarkeit von Google Distributed Cloud-Clustern viele zusammenhängende Dimensionen. In diesem Dokument werden die Schlüsseldimensionen erläutert, die Sie anpassen können, um Ihre Cluster ohne Beeinträchtigung Ihrer Arbeitslasten zu skalieren.

Informationen zu den Limits

Google Distributed Cloud ist ein komplexes System mit einer großen Integrationsfläche. Die Skalierbarkeit des Clusters hängt von vielen Faktoren ab. Die Anzahl der Knoten ist beispielsweise nur einer von vielen Dimensionen, auf die Google Distributed Cloud eine Skalierung vornehmen kann. Weitere Dimensionen sind die Gesamtzahl von Pods und Diensten. Viele dieser Dimensionen, wie die Anzahl der Pods pro Knoten und die Anzahl der Knoten pro Cluster, sind miteinander verknüpft. Weitere Informationen zu den Dimensionen, die sich auf die Skalierbarkeit auswirken, finden Sie unter Kubernetes-Skalierbarkeitsgrenzwerte im Abschnitt Scalability Special Interest Group (SIG) des Kubernetes Community-Repositorys auf GitHub.

Die Skalierbarkeitslimits hängen auch von der Hardware- und Knotenkonfiguration ab, auf der Ihr Cluster ausgeführt wird. Die in diesem Dokument beschriebenen Limits werden in einer Umgebung überprüft, die wahrscheinlich von Ihrer abweicht. Daher können Sie möglicherweise nicht dieselben Zahlen reproduzieren, wenn die zugrunde liegende Umgebung der begrenzende Faktor ist.

Weitere Informationen zu den Limits, die für Ihre Google Distributed Cloud-Cluster gelten, finden Sie unter Kontingente und Limits.

Skalierung vorbereiten

Beachten Sie bei der Vorbereitung der Skalierung Ihrer Google Distributed Cloud-Cluster die in den folgenden Abschnitten beschriebenen Anforderungen und Einschränkungen.

CPU- und Arbeitsspeicheranforderungen für Knoten der Steuerungsebene

In der folgenden Tabelle ist die empfohlene CPU- und Arbeitsspeicherkonfiguration für Knoten der Steuerungsebene für Cluster beschrieben, auf denen Produktionsarbeitslasten ausgeführt werden:

Anzahl der Clusterknoten Empfohlene CPUs für Steuerungsebene Empfohlener Arbeitsspeicher der Steuerungsebene
1-50 8 Kerne 32 GiB
51–100 16 Kerne 64 GiB

Anzahl der Pods und Dienste

Die Anzahl der Pods und Dienste, die sich in Ihren Clustern befinden können, wird durch die folgenden Einstellungen gesteuert:

Pod-CIDR und maximale Knotenanzahl

Die Gesamtzahl der für Pods in Ihrem Cluster reservierten IP-Adressen ist einer der begrenzenden Faktoren beim Hochskalieren eines Clusters. Diese Einstellung bestimmt zusammen mit der Einstellung für die maximale Anzahl von Pods pro Knoten die maximale Anzahl von Knoten, die Sie in Ihrem Cluster haben können, bevor Sie riskieren, IP-Adressen für Ihre Pods zu erschöpfen.

Beachten Sie dabei Folgendes:

  • Die Gesamtzahl der für Pods in Ihrem Cluster reservierten IP-Adressen wird mit clusterNetwork.pods.cidrBlocks angegeben. Dafür wird ein Bereich von IP-Adressen in CIDR-Notation angegeben. Der vorab ausgefüllte Wert 192.168.0.0/16 gibt beispielsweise einen Bereich von 65.536 IP-Adressen von 192.168.0.0 bis 192.168.255.255 an.

  • Die maximale Anzahl von Pods, die auf einem einzelnen Knoten ausgeführt werden können, wird mit nodeConfig.podDensity.maxPodsPerNode angegeben.

  • Basierend auf der Einstellung für die maximale Anzahl von Pods pro Knoten stellt Google Distributed Cloud ungefähr doppelt so viele IP-Adressen für den Knoten bereit. Die zusätzlichen IP-Adressen verhindern die unbeabsichtigte Wiederverwendung der Pod-IP-Adressen innerhalb kurzer Zeit.

  • Wenn Sie die Gesamtzahl der Pod-IP-Adressen durch die Anzahl der auf jedem Knoten bereitgestellten Pod-IP-Adressen dividieren, erhalten Sie die Gesamtzahl der Knoten, die in Ihrem Cluster vorhanden sein können.

Wenn Ihr Pod-CIDR beispielsweise 192.168.0.0/17 ist, haben Sie insgesamt 32.768 IP-Adressen (2(32 - 17) = 215 = 32.768). Wenn Sie die maximale Anzahl von Pods pro Knoten auf 250 festlegen, stellt Google Distributed Cloud einen Bereich von etwa 500 IP-Adressen bereit, die in etwa einem CIDR-Block vom Typ /23 (2(32–23) = 29 = 512) entsprechen. Die maximale Anzahl von Knoten ist in diesem Fall also 64 (215 Adressen/Cluster geteilt durch 29 Adressen/Knoten = 2(15 - 9) Knoten/Cluster = 26 = 64 Knoten/Cluster).

Sowohl clusterNetwork.pods.cidrBlocks als auch nodeConfig.podDensity.maxPodsPerNode sind unveränderlich. Planen Sie also sorgfältig das zukünftige Wachstum Ihres Clusters, damit Ihnen keine Knotenkapazität zur Verfügung steht. Die empfohlenen Höchstwerte für Pods pro Cluster, Pods pro Knoten und Knoten pro Cluster basierend auf Tests finden Sie unter Limits.

Dienst-CIDR

Ihr Dienst-CIDR kann aktualisiert werden, um beim Hochskalieren des Clusters weitere Dienste hinzuzufügen. Sie können den Dienst-CIDR-Bereich jedoch nicht reduzieren. Weitere Informationen finden Sie unter Dienstnetzwerkbereich erhöhen.

Für System-Daemons reservierte Ressourcen

Standardmäßig reserviert Google Distributed Cloud 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 diese Daemons die erforderlichen Ressourcen haben. Ohne dieses Feature können Pods möglicherweise die meisten Ressourcen auf einem Knoten nutzen, was System-Daemons unmöglich macht, ihre Aufgaben auszuführen.

Google Distributed Cloud reserviert 80 Millicore CPU (80 mCPU) und 280 Mebibyte (280 MiB) Arbeitsspeicher auf jedem Knoten für System-Daemons. Beachten Sie, dass die CPU-Einheit mCPU für ein Tausendstel eines Kerns steht. Daher sind 80/1.000 oder 8 % eines Kerns auf jedem Knoten für System-Daemons reserviert. Die Anzahl 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 die CPU- oder Arbeitsspeichernutzung die ihm zugewiesenen Beträge überschreitet.

Netzwerk mit MetalLB

Sie können die Anzahl der MetalLB-Lautsprecher erhöhen, um die folgenden Aspekte zu berücksichtigen:

  • Bandbreite: Die gesamte Clusterbandbreite für Load-Balancing-Dienste hängt von der Anzahl der Lautsprecher und der Bandbreite der einzelnen Lautsprecherknoten ab. Bei einem erhöhten Netzwerkverkehr sind mehr Lautsprecher erforderlich.

  • Fehlertoleranz: Eine größere Anzahl von Lautsprechern reduziert die Gesamtauswirkung eines Ausfalls eines einzelnen Lautsprechers.

MetalLB benötigt Layer-2-Verbindungen zwischen den Load-Balancing-Knoten. In diesem Fall könnten Sie durch die Anzahl der Knoten mit Ebene-2-Verbindungen eingeschränkt sein, auf denen Sie MetalLB-Lautsprecher platzieren können.

Planen Sie sorgfältig, wie viele MetalLB-Lautsprecher Sie in Ihrem Cluster haben möchten, und bestimmen Sie, wie viele Layer-2-Knoten Sie benötigen. Weitere Informationen finden Sie unter Probleme mit der MetalLB-Skalierbarkeit.

Wenn Sie den gebündelten Load-Balancing-Modus verwenden, müssen sich auch die Knoten der Steuerungsebene im selben Layer-2-Netzwerk befinden. Beim manuellen Load-Balancing gilt diese Einschränkung nicht. Weitere Informationen finden Sie unter Manueller Load-Balancer-Modus.

Viele Knoten, Pods und Dienste ausführen

Durch das Hinzufügen von Knoten, Pods und Diensten lässt sich ein Cluster hochskalieren. In den folgenden Abschnitten werden einige zusätzliche Einstellungen und Konfigurationen beschrieben, die Sie berücksichtigen sollten, wenn Sie die Anzahl der Knoten, Pods und Dienste im Cluster erhöhen. Informationen zu den Limits für diese Dimensionen und deren Beziehung zueinander finden Sie unter Limits.

Cluster ohne kube-proxy erstellen

Zum Erstellen eines Hochleistungsclusters, der hochskaliert werden kann, um eine große Anzahl von Diensten und Endpunkten zu verwenden, empfehlen wir, den Cluster ohne kube-proxy zu erstellen. Ohne kube-proxy verwendet der Cluster GKE Dataplane V2 im Modus kube-proxy-replacement. In diesem Modus wird der Ressourcenverbrauch vermieden, der für die Verwaltung einer großen Reihe von iptables-Regeln erforderlich ist.

Sie können die Verwendung von kube-proxy für einen vorhandenen Cluster nicht deaktivieren. Diese Konfiguration muss beim Erstellen des Clusters eingerichtet werden. Eine Anleitung und weitere Informationen finden Sie unter Cluster ohne kube-proxy erstellen.

CoreDNS-Konfiguration

In diesem Abschnitt werden Aspekte von CoreDNS beschrieben, die sich auf die Skalierbarkeit Ihrer Cluster auswirken.

Pod-DNS

Standardmäßig fügen Google Distributed Cloud-Cluster Pods mit einem resolv.conf ein, der in etwa so aussieht:

nameserver KUBEDNS_CLUSTER_IP
search <NAMESPACE>.svc.cluster.local svc.cluster.local cluster.local c.PROJECT_ID.internal google.internal
options ndots:5

Die Option ndots:5 bedeutet, dass Hostnamen mit weniger als 5 Punkten nicht als voll qualifizierter Domainname (FQDN) gelten. Der DNS-Server hängt alle angegebenen Suchdomains an, bevor er den ursprünglich angeforderten Hostnamen sucht. Damit wird bei der Auflösung von google.com die folgende Suche angeordnet:

  1. google.com.NAMESPACE.svc.cluster.local
  2. google.com.svc.cluster.local
  3. google.com.cluster.local
  4. google.com.c.PROJECT_ID.internal
  5. google.com.google.internal
  6. google.com

Jede der Suchvorgänge wird für IPv4 (A-Eintrag) und IPv6 (AAAA-Eintrag) ausgeführt. Das führt zu 12 DNS-Anfragen für jede Nicht-FQDN-Abfrage, was den DNS-Traffic erheblich verstärkt. Zur Behebung dieses Problems empfehlen wir, den zu suchenden Hostnamen als FQDN zu deklarieren. Fügen Sie dazu einen nachgestellten Punkt (google.com.) hinzu. Diese Deklaration muss auf Ebene der Anwendungsarbeitslast erfolgen. Weitere Informationen finden Sie auf der resolv.conf-Manpage.

IPv6

Wenn der Cluster nicht IPv6 verwendet, können Sie die DNS-Anfragen um die Hälfte reduzieren, indem Sie den AAAA-Eintrag-Lookup auf den vorgelagerten DNS-Server eliminieren. Wenn Sie Hilfe beim Deaktivieren von AAAA-Lookups benötigen, wenden Sie sich an Cloud Customer Care.

Dedizierter Knotenpool

Da DNS-Abfragen im Anwendungslebenszyklus kritisch sind, empfehlen wir die Verwendung spezieller Knoten für das coredns-Deployment. Dieses Deployment fällt in eine andere Fehlerdomain als normale Anwendungen. Wenn Sie Hilfe beim Einrichten dedizierter Knoten für die coredns-Bereitstellung benötigen, wenden Sie sich an Cloud Customer Care.

Probleme mit der MetalLB-Skalierbarkeit

MetalLB wird im Aktiv-Passiv-Modus ausgeführt. Das bedeutet, dass zu jeder Zeit nur ein einzelner MetalLB-Lautsprecher eine bestimmte LoadBalancer-VIP bedient.

Failover

Vor der Veröffentlichung von Google Distributed Cloud 1.28.0 konnte der Failover von MetalLB im großen Maßstab lange dauern und ein Zuverlässigkeitsrisiko für den Cluster darstellen.

Verbindungseinschränkungen

Wenn eine bestimmte LoadBalancer-VIP (z. B. ein Ingress-Dienst) nahe an oder mehr als 30.000 gleichzeitige Verbindungen erwartet, ist es wahrscheinlich, dass der Lautsprecherknoten, der die VIP verwaltet, verfügbare Ports erschöpft. Aufgrund einer Einschränkung der Architektur kann dieses Problem durch MetalLB nicht entschärft werden. Wechseln Sie vor dem Erstellen des Clusters gegebenenfalls zu gebündeltem Load-Balancing mit BGP oder verwenden Sie eine andere Ingress-Klasse. Weitere Informationen finden Sie unter Ingress-Konfiguration.

Load-Balancer-Lautsprecher

Standardmäßig verwendet Google Distributed Cloud denselben Load-Balancer-Knotenpool für die Steuerungsebene und die Datenebene. Wenn Sie keinen Load-Balancer-Knotenpool (loadBalancer.nodePoolSpec) angeben, wird der Knotenpool der Steuerungsebene (controlPlane.nodePoolSpec) verwendet.

Wenn Sie die Anzahl der Lautsprecher erhöhen möchten, wenn Sie den Knotenpool der Steuerungsebene für das Load-Balancing verwenden, müssen Sie die Anzahl der Maschinen der Steuerungsebene erhöhen. Für Produktionsbereitstellungen empfehlen wir, für eine Hochverfügbarkeit drei Knoten der Steuerungsebene zu verwenden. Die Ressourcen werden möglicherweise nicht sinnvoll genutzt, wenn Sie die Anzahl der Knoten der Steuerungsebene auf mehr als drei erhöhen, um zusätzliche Lautsprecher unterzubringen.

Konfiguration für eingehenden Traffic

Wenn Sie davon ausgehen, dass fast 30.000 gleichzeitige Verbindungen bei einer einzelnen LoadBalancer-Dienst-VIP eingehen, kann MetalLB dies möglicherweise nicht unterstützen.

Sie können die VIP auch über andere Mechanismen verfügbar machen, z. B. über F5 BIG-IP. Alternativ können Sie einen neuen Cluster mit gebündeltem Load-Balancing mit BGP erstellen, für das nicht dieselben Einschränkungen gelten.

Cloud Logging- und Cloud Monitoring-Komponenten optimieren

In großen Clustern reichen die Standardressourcenkonfigurationen für die Cloud Logging- und Cloud Monitoring-Komponenten je nach Anwendungsprofil und Trafficmuster möglicherweise nicht aus. Eine Anleitung zum Optimieren der Ressourcenanfragen und -limits für die Komponenten der Beobachtbarkeit finden Sie unter Ressourcen von Stackdriver-Komponenten konfigurieren.

Insbesondere kube-state-metrics in Clustern mit einer großen Anzahl von Diensten und Endpunkten können zu einer übermäßigen Arbeitsspeichernutzung in kube-state-metrics und gke-metrics-agent auf demselben Knoten führen. Die Ressourcennutzung von Metrics-Server kann auch in Bezug auf Knoten, Pods und Dienste skaliert werden. Wenn in diesen Komponenten Ressourcenprobleme auftreten, wenden Sie sich an Cloud Customer Care.

Betriebssystem mit „sysctl“ konfigurieren

Wir empfehlen Ihnen, die Betriebssystemkonfiguration für Ihre Knoten an den Anwendungsfall Ihrer Arbeitslast anzupassen. Die Parameter fs.inotify.max_user_watches und fs.inotify.max_user_instances, die die Anzahl der inotify-Ressourcen steuern, müssen häufig optimiert werden. Wenn beispielsweise Fehlermeldungen wie die folgende angezeigt werden, sollten Sie prüfen, ob diese Parameter angepasst werden müssen:

The configured user limit (128) on the number of inotify instances has been reached

ENOSPC: System limit for number of file watchers reached...

Die Feinabstimmung variiert in der Regel je nach Arbeitslasttyp und Hardwarekonfiguration. Sie können sich mit Ihrem Betriebssystemanbieter über die spezifischen Best Practices für Betriebssysteme konsultieren.

Best Practices

In diesem Abschnitt werden Best Practices zum Skalieren eines Clusters beschrieben.

Dimensionen für einzelne Dimensionen skalieren

Passen Sie nicht mehr als eine Dimension auf einmal an, um Probleme zu minimieren und Rollbacks für Änderungen einfacher zu machen. Das gleichzeitige Skalieren mehrerer Dimensionen kann auch in kleineren Clustern Probleme verursachen. Beispielsweise wird es wahrscheinlich nicht erfolgreich sein, die Anzahl der geplanten Pods pro Knoten auf 110 zu erhöhen, während die Anzahl der Knoten im Cluster auf 250 erhöht werden kann, da die Anzahl der Pods, die Anzahl der Pods pro Knoten und die Anzahl der Knoten zu stark erweitert werden.

Cluster schrittweise skalieren

Das Hochskalieren eines Clusters kann ressourcenintensiv sein. Um das Risiko von fehlgeschlagenen Clustervorgängen oder Unterbrechungen von Clusterarbeitslasten zu verringern, raten wir davon ab, große Cluster mit vielen Knoten in einem einzigen Vorgang zu erstellen.

Hybrid- oder eigenständige Cluster ohne Worker-Knoten erstellen

Wenn Sie einen großen Hybrid- oder eigenständigen Cluster mit mehr als 50 Worker-Knoten erstellen, ist es besser, zuerst einen Hochverfügbarkeitscluster mit Knoten der Steuerungsebene zu erstellen und dann schrittweise hochzuskalieren. Beim Erstellen des Clusters wird ein Bootstrap-Cluster verwendet, der keine Hochverfügbarkeit bietet und daher weniger zuverlässig ist. Nachdem der Hochverfügbarkeits-Hybrid- oder eigenständige Cluster erstellt wurde, können Sie ihn verwenden, um auf weitere Knoten hochzuskalieren.

Anzahl der Worker-Knoten in Batches erhöhen

Wenn Sie einen Cluster auf mehr Worker-Knoten erweitern, ist es besser, ihn schrittweise zu erweitern. Wir empfehlen, nicht mehr als 20 Knoten auf einmal hinzuzufügen. Dies gilt insbesondere für Cluster, auf denen kritische Arbeitslasten ausgeführt werden.

Parallele Image-Abrufe aktivieren

Standardmäßig ruft Kubelet Images nacheinander ab, also nacheinander. Wenn eine schlechte Upstream-Verbindung zu Ihrem Image-Registry-Server besteht, kann ein fehlerhafter Image-Abruf die gesamte Warteschlange für einen bestimmten Knotenpool zum Stillstand bringen.

Um dies zu umgehen, sollten Sie serializeImagePulls in der benutzerdefinierten Kubelet-Konfiguration auf false setzen. Eine Anleitung und weitere Informationen finden Sie unter Einstellungen zum Abrufen von kubelet-Images konfigurieren. Das Aktivieren paralleler Image-Abrufe kann zu Spitzen im Verbrauch der Netzwerkbandbreite oder der Laufwerks-E/A führen.

Anfragen und Limits für Anwendungsressourcen optimieren

In dicht gepackten Umgebungen können Anwendungsarbeitslasten entfernt werden. Kubernetes verwendet den referenzierten Mechanismus, um Pods bei einer Bereinigung einzustufen.

Eine gute Vorgehensweise zum Festlegen Ihrer Containerressourcen besteht darin, die gleiche Menge an Arbeitsspeicher für Anfragen und Limits sowie ein größeres oder unbegrenztes CPU-Limit zu verwenden. Weitere Informationen finden Sie im Cloud Architecture Center unter Cloudbasierte Kubernetes-Anwendungen vorbereiten.

Speicherpartner verwenden

Wir empfehlen, für umfangreiche Bereitstellungen einen GDCV-fähigen Speicherpartner zu verwenden. Es ist wichtig, dass Sie sich an den jeweiligen Storage-Partner wenden, um die folgenden Informationen abzuklären:

  • Die Speicherbereitstellungen folgen den Best Practices für Speicheraspekte wie Hochverfügbarkeit, Prioritätseinstellung, Knotenaffinitäten sowie Ressourcenanfragen und -limits.
  • Die Speicherversion wird mit der jeweiligen Version von Google Distributed Cloud qualifiziert.
  • Der Speicheranbieter kann die hohe Skalierung, die Sie bereitstellen möchten, unterstützen.

Cluster für Hochverfügbarkeit konfigurieren

Es ist wichtig, Ihre umfangreiche Bereitstellung zu prüfen und dafür zu sorgen, dass die kritischen Komponenten nach Möglichkeit für Hochverfügbarkeit konfiguriert sind. Google Distributed Cloud unterstützt Hochverfügbarkeitsoptionen für alle Clustertypen. Weitere Informationen finden Sie unter Bereitstellungsmodell auswählen. Clusterkonfigurationsdateien für Hochverfügbarkeitsbereitstellungen finden Sie unter Beispiele für Clusterkonfiguration.

Es ist auch wichtig, andere Komponenten zu prüfen, darunter:

  • Speicheranbieter
  • Cluster-Webhooks

Ressourcennutzung überwachen

Dieser Abschnitt enthält einige grundlegende Monitoringempfehlungen für große Cluster.

Auslastungsmesswerte genau überwachen

Es ist wichtig, die Auslastung sowohl von Knoten als auch von einzelnen Systemkomponenten zu überwachen und sicherzustellen, dass sie einen akzeptablen sicheren Bereich haben. Informationen zu den standardmäßigen Monitoringfunktionen finden Sie unter Vordefinierte Dashboards verwenden.

Bandbreitenverbrauch überwachen

Überwachen Sie die Bandbreitennutzung genau, um sicherzustellen, dass das Netzwerk nicht gesättigt wird, was zu Leistungseinbußen für den Cluster führt.

etcd-Leistung verbessern

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 Google Distributed Cloud 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 „Anwendung von Einträgen dauerte zu lange“? und Was bedeutet die etcd-Warnung „Fehler, den Heartbeat rechtzeitig zu senden“?.

Wenn Sie weitere Unterstützung benötigen, wenden Sie sich an den Cloud Customer Care.

Nächste Schritte