Kubernetes 1.31 hat die größte Migration in der Geschichte von Kubernetes abgeschlossen und dabei den In-Tree-Cloud-Anbieter entfernt. Obwohl die Migration der Komponenten nun abgeschlossen ist, bringt dies zusätzliche Komplexität für Benutzer und Installationsprojekte wie kOps oder Cluster API mit sich. In diesem Artikel gehen wir auf die zusätzlichen Schritte und mögliche Fehlerquellen ein und geben Empfehlungen für Cluster-Besitzer. Diese Migration war komplex und erforderte die Extraktion einiger Logik aus den Kernkomponenten, was zur Bildung von vier neuen Subsystemen führte.

  1. Cloud Controller Manager ([KEP-2392][kep2392])
  2. API-Server-Netzwerkproxy ([KEP-1281][kep1281])
  3. Kubelet-Anmeldeinformationen-Anbieter-Plugins ([KEP-2133][kep2133])
  4. Speichermigration zur Nutzung von [CSI][csi] ([KEP-625][kep625])

Der [Cloud Controller Manager ist Teil des Control Plane][ccm]. Er ist eine kritische Komponente, die einige Funktionen ersetzt, die zuvor im kube-controller-manager und im kubelet existierten.

Eine der wichtigsten Funktionen des Cloud Controller Managers ist der Node Controller, der für die Initialisierung der Nodes verantwortlich ist.

Wie im folgenden Diagramm zu sehen ist, registriert der kubelet das Node-Objekt beim API-Server und versieht den Node mit einem Taint, damit er zuerst vom Cloud Controller Manager verarbeitet werden kann. Das ursprüngliche Node-Objekt fehlt jedoch spezifische Informationen des Cloud-Anbieters, wie die Node-Adressen und die Labels mit cloud-spezifischen Informationen wie Node, Region und Instanztyp.

Dieser neue Initialisierungsprozess fügt eine gewisse Verzögerung bei der Node-Bereitschaft hinzu. Zuvor konnte der kubelet den Node gleichzeitig mit seiner Erstellung initialisieren. Da die Logik nun zum Cloud Controller Manager verschoben wurde, kann dies während des Cluster-Bootstrappings zu einem [Henne-Ei-Problem][chicken-and-egg] führen, insbesondere bei Kubernetes-Architekturen, die den Controller Manager nicht zusammen mit den anderen Komponenten des Control Plane bereitstellen, häufig als statische Pods, eigenständige Binärdateien oder DaemonSets/Deployments mit Tolerierungen für die Taints und der Nutzung von hostNetwork (mehr dazu weiter unten).

Beispiele für das Abhängigkeitsproblem

Wie oben erwähnt, kann es während des Bootstrappings vorkommen, dass der Cloud Controller Manager nicht geplant werden kann, was dazu führt, dass der Cluster nicht ordnungsgemäß initialisiert wird. Im Folgenden finden Sie einige konkrete Beispiele dafür, wie dieses Problem ausgedrückt werden kann und die zugrunde liegenden Ursachen, warum dies geschehen könnte.

Diese Beispiele setzen voraus, dass Sie Ihren Cloud Controller Manager über eine Kubernetes-Ressource (z. B. Deployment, DaemonSet oder Ähnliches) betreiben, um dessen Lebenszyklus zu steuern. Da diese Methoden darauf angewiesen sind, dass Kubernetes den Cloud Controller Manager plant, muss darauf geachtet werden, dass er ordnungsgemäß geplant wird.

Mit ayedo als Partner für Kubernetes können Sie sicherstellen, dass Ihr Cluster effizient und optimal konfiguriert ist, um solche Herausforderungen zu meistern.


Quelle: Kubernetes Blog

ayedo Alien Kubernetes Hat

Hosten Sie Ihre Apps bei ayedo

Profitieren Sie von skalierbarem App Hosting in Kubernetes, hochverfügbarem Ingress Loadbalancing und erstklassigem Support durch unser Plattform Team. Mit der ayedo Cloud können Sie sich wieder auf das konzentrieren, was Sie am besten können: Software entwickeln.

Jetzt ausprobieren →

Ähnliche Inhalte

Alle Blogs →



ayedo Redaktion · 08.06.2025 · ⏳ 3 Minuten

Neue Wege im KI-Management: Die Gateway API Inference Extension

Moderne generative KI- und große Sprachmodelle (LLMs) stellen Kubernetes vor einzigartige Herausforderungen im Datenverkehrsmanagement. Im Gegensatz zu typischen kurzlebigen, zustandslosen Webanfragen …

Lesen →

Neue Wege im KI-Management: Die Gateway API Inference Extension
ayedo Redaktion · 06.06.2025 · ⏳ 2 Minuten

Wie Sie sicherstellen, dass Ihr Sidecar-Container zuerst startet

Einführung in die Verwaltung von Sidecar-Containern in Kubernetes In der Welt von Kubernetes sind Sidecar-Container nützliche Helfer, die Funktionen erweitern oder zusätzliche Aufgaben für die …

Lesen →

Wie Sie sicherstellen, dass Ihr Sidecar-Container zuerst startet
ayedo Redaktion · 05.06.2025 · ⏳ 2 Minuten

Gateway API v1.3.0: Neue Funktionen für flexibles Request Mirroring und mehr!

Wir freuen uns, die allgemeine Verfügbarkeit der Gateway API v1.3.0 bekanntzugeben! Diese Version wurde am 24. April 2025 veröffentlicht und bringt spannende neue Funktionen mit sich. Was ändert sich …

Lesen →

Gateway API v1.3.0: Neue Funktionen für flexibles Request Mirroring und mehr!
Katrin Peter · 03.06.2025 · ⏳ 2 Minuten

Application Performance sollte messbar sein — jederzeit, in Echtzeit

Wer Anwendungen produktiv betreibt, braucht keine schönen Dashboards, sondern harte Daten. Performance-Probleme entstehen nie dann, wenn Zeit für Debugging ist. Sie kommen genau dann, wenn Systeme …

Lesen →

Application Performance sollte messbar sein — jederzeit, in Echtzeit
Katrin Peter · 03.06.2025 · ⏳ 2 Minuten

Warum betreibt ihr eure App eigentlich noch selbst?

Die Frage stellt sich immer wieder. Entwicklerteams liefern Features, optimieren Releases, bauen saubere Architekturen — und dann hängen sie trotzdem noch in der Infrastruktur. Kubernetes-Cluster …

Lesen →

Warum betreibt ihr eure App eigentlich noch selbst?

Interessiert an weiteren Inhalten? Hier gehts zu allen Blogs →


Noch Fragen? Melden Sie sich!

Unsere DevOps-Experten antworten in der Regel innerhalb einer Stunde.

Zu Gen-Z für E-Mail? Einfach mal Discord versuchen. Unter +49 800 000 3706 können Sie unter Angabe Ihrer Kontaktdaten auch einen Rückruf vereinbaren. Bitte beachten Sie, dass es keine Möglichkeit gibt, uns telefonisch direkt zu erreichen. Bitte gar nicht erst versuchen. Sollten Sie dennoch Interesse an synchroner Verfügbarkeit via Telefon haben, empfehlen wir Ihnen unseren Priority Support.