Drei unterschiedliche Engpässe begrenzen die Skalierung der Kubernetes-Control-Plane

Skalierungsprobleme bei Kubernetes werden oft fälschlicherweise als einfache Limits der Node-Anzahl diagnostiziert. Jüngste Analysen zeigen jedoch drei unterschiedliche Fehlermodi: Churn (Wechsel), State (Zustand) und Node-Kapazität. Wenn Cluster über fünftausend Nodes hinauswachsen oder intensive Agent-Workloads verarbeiten, kann das standardmäßige horizontale Skalieren der API-Server den Speicherdruck sogar verschärfen, statt ihn zu lindern. Das Verständnis dieser spezifischen Engpässe ermöglicht es Infrastrukturteams, gezielte architektonische Korrekturen unter Verwendung von Standard-Upstream-Komponenten vorzunehmen.

Was passiert ist

Viele Engineering-Teams gehen davon aus, dass die Skalierung einer Kubernetes-Control-Plane ein lineares Problem ist, das durch Hinzufügen weiterer API-Server gelöst wird. In produktiven Umgebungen zeigt sich jedoch, dass dieser Ansatz häufig scheitert, wenn der zugrunde liegende Engpass nicht das Anfragevolumen, sondern die Speicherresidenz oder die Schreibintensität ist. Beispielsweise könnte eine Trainingsflotte stabil bei einigen tausend Nodes laufen, bevor sie auf fünfzehntausend springt, was zu etcd-Beschwerden und zur Erschöpfung des API-Server-Speichers führt. Im Gegensatz dazu kann eine Agent-Plattform mit nur wenigen tausend Nodes unter Tausenden von Objektübergängen pro Minute leiden, was einen „Schreibsturm“ erzeugt, der die Control-Plane unabhängig von der Node-Anzahl überwältigt.

Ein drittes Szenario betrifft Plattform-Cluster mit Hunderten von Operatoren und Zehntausenden statischer Objekte. Hier liegt das Problem nicht in der Aktivität, sondern im Zustand: Jeder API-Server hält eine Kopie aller Objekte in seinem Watch-Cache. Das Hinzufügen weiterer API-Server repliziert in diesem Kontext den gesamten Cache, erhöht die Speichernutzung, ohne die Leistung zu verbessern. Diese drei Szenarien – node-bound (knotenbegrenzt), churn-bound (wechselbegrenzt) und state-bound (zustandsbegrenzt) – erfordern unterschiedliche Lösungen, doch die meisten öffentlichen Richtlinien konzentrieren sich ausschließlich auf Node-Anzahlen bis zu fünftausend.

Der Mangel an dokumentierten Strategien für größere oder komplexere Cluster führt dazu, dass Teams kontraproduktive Änderungen vornehmen. Das Hinzufügen von API-Servern zu einem zustandsbegrenzten Cluster erhöht den Speicherdruck, da jede neue Instanz den vollständigen Watch-Cache repliziert. Die Lösung liegt nicht in benutzerdefinierten Forks, sondern im Verständnis der „Nahtstellen“ der Kubernetes-Architektur, an denen Komponenten entkoppelt und unabhängig voneinander konfiguriert werden können, um spezifische Lasttypen zu bewältigen.

Wie es funktioniert

Die Skalierbarkeit von Kubernetes wird durch vier architektonische „Nahtstellen“ eingeschränkt, die Substitutionspunkte zwischen Komponenten darstellen. Die erste Nahtstelle ist der Speicher, der bestimmt, welches Backend welche Ressourcentypen hält. Nicht alle Daten erfordern dieselbe Haltbarkeit; ephemere Elemente wie Node-Leases und Events können vom primären etcd-Cluster wegroutiert werden, um die Schreiblast zu reduzieren. Die zweite Nahtstelle ist die Node-Liveness, die regelt, wie Heartbeat-Daten die Control-Plane erreichen. Indem Lease-Erneuerungen in einer Node-zugewandten Ebene absorbiert oder In-Memory-Lease-Auffrischungen in etcd verwendet werden, können Cluster die durch Tausende von Kubelets erzeugte Schreib-QPS drastisch reduzieren.

Die dritte Nahtstelle ist das Sharding, das definiert, wie Objekte über Controller und Caches verteilt werden. Wenn die Ebenen sich nicht auf die Sharding-Achse einigen, verschwenden Controller Ressourcen beim Zugriff auf Objekte außerhalb ihres Geltungsbereichs. Die vierte Nahtstelle ist die Cache-Residenz, die steuert, was ein API-Server im Speicher behält. Ein zustandsbegrenzter Cluster leidet darunter, dass jeder API-Server jedes Objekt cacht. Durch die Beschränkung des Cache-Inhalts auf nur die Objekte, die für einen bestimmten Shard oder eine bestimmte Rolle relevant sind, kann die Speichernutzung erheblich gesenkt werden, obwohl ein Grundrauschen für RBAC-Objekte unvermeidlich bleibt.

Wichtige Details

• Node-bound Cluster werden durch Kubelet-Heartbeats begrenzt, wobei Lease-Erneuerungen im großen Maßstab etwa 70 % der Schreib-QPS ausmachen.
• Churn-bound Cluster stehen vor hohen Schreibraten durch kurzlebige Custom Resources, wie Agent-Sessions, unabhängig von der Node-Anzahl.
• State-bound Cluster werden durch die Speichernutzung eingeschränkt, da jeder API-Server den gesamten Watch-Cache von Zehntausenden Objekten repliziert.
• KEP-4743 definiert die Grenze der Speicher-Schnittstelle und ermöglicht es, Ressourcentypen über --etcd-servers-overrides an verschiedene Backends zu routen.
• KEP-5866 führt Hash-Range-Filtering für den API-Traffic ein und legt damit den Grundstein für konsistentes Sharding über Controller und Caches hinweg.
• Role-Split-Konfigurationen trennen Maschinen-Pools für API-Bereitstellung, Scheduling und etcd und ermöglichen so eine Skalierung auf bis zu 20.000 Nodes.

Warum das wichtig ist

Für Software-Ingenieure und Infrastruktur-Leads ist es entscheidend, den spezifischen Typ der Skalierungsbeschränkung zu erkennen, um kostspielige Fehlkonfigurationen zu vermeiden. Wird eine wechselbegrenzte Agent-Plattform als knotenbegrenztes Problem behandelt, führt dies zur Überbereitstellung von Compute-Ressourcen, während der Schreibengpass in etcd ignoriert wird. Ebenso erhöht das Hinzufügen von API-Servern zu einem zustandsbegrenzten Plattform-Cluster die Speicherkosten, ohne die Latenz zu verbessern. Indem Teams identifizieren, ob der Cluster durch Node-Heartbeats, Objekt-Churn oder Zustandsresidenz begrenzt ist, können sie präzise Korrekturen anwenden, anstatt auf brutale Skalierung zurückzugreifen.

Diese Erkenntnisse unterstreichen auch die Bedeutung der Verwendung von Standard-Upstream-Komponenten mit bewusster Konfiguration, anstatt sich auf undokumentierte Forks zu verlassen. Die vorgeschlagene „Rezept-Leiter“ bietet einen Weg von klassischen Hochverfügbarkeits-Setups hin zu partitionierten Stores und geshardeten Slices, die alle durch Continuous Integration getestet wurden. Dieser Ansatz stellt sicher, dass Skalierungsstrategien über Kubernetes-Releases hinweg gültig bleiben, da Konfigurationsfehler frühzeitig in der CI-Pipeline und nicht erst in der Produktion erkannt werden.

Was Sie tun können

• Identifizieren Sie den primären Engpass Ihres Clusters, indem Sie die Quellen der Schreib-QPS analysieren und zwischen Node-Leases, Custom-Resource-Churn und statischem Objektzustand unterscheiden.
• Implementieren Sie Role-Split-Konfigurationen, um API-Bereitstellung, Scheduling und etcd auf dedizierte Maschinen-Pools für Cluster mit bis zu 20.000 Nodes zu verteilen.
• Verwenden Sie --etcd-servers-overrides, um ephemere Ressourcen wie Events und Leases an separate Backends zu routen und so die Last auf dem primären etcd-Cluster zu reduzieren.
• Evaluieren Sie Node-zugewandte Ebenen, um Lease-Erneuerungen zu absorbieren und nur echte Zustandsübergänge weiterzugeben, wodurch die Schreiblast auf der Control-Plane sinkt.
• Stellen Sie reale Daten zu Schreibraten aus wechselbegrenzten Clusters bereit, um SIG API Machinery bei der Gestaltung zukünftiger Unterstützung für per-CRD-Speicherkonfigurationen zu helfen.
• Prüfen Sie Prototyp-Zweige für KEP-5866 und Erweiterungen zur Cache-Residenz, um sich auf kommende Sharding- und Speicheroptimierungsfunktionen vorzubereiten.