Gegen Kubernetes-Wildwuchs hilft nur Kubernetes selbst 

In der Geschichte der IT findet sich ein Muster, das sich schon oft wiederholt hat: Irgendwann setzen sich bestimmte Technologien durch und werden zu allgegenwärtigen Standards.

Zwei Beispiele dafür sind TCP/IP+Ethernet und Linux. In jüngerer Zeit zeigt sich zudem, dass Kubernetes zum De-facto-Standard für die Verwaltung und Bereitstellung von Anwendungen geworden ist.

Kubernetes wird für die Bereitstellung nativer Cloud-Anwendungen, für monolithische Legacy-Applikationen, Virtualisierung und so ziemlich (fast) alles andere irgendwie Erdenkliche verwendet. Dazu kam es, weil Kubernetes, wie zuvor TCP/IP+Ethernet und Linux, quasi die Lösung ist, die in 80-90 % der Fälle für die Bereitstellung und Verwaltung von Anwendungen einfach funktioniert. Jetzt, da Kubernetes sowohl innerhalb als auch außerhalb der Enterprise-Nutzung dominiert, erleben wir eine zunehmende Ausbreitung von Kubernetes-Clustern – man könnte auch von „Wildwuchs“ sprechen. Und ähnlich wie zuvor bei Routern/Switches, Servern und virtuellen Maschinen (VM) muss etwas getan werden, damit Unternehmen Kubernetes erfolgreich in großem Maßstab verwalten können. Die Lösung? Kubernetes selbst!

Zunächst einige Hintergrundinformationen

Es mag auf den ersten Blick überraschen, aber TCP/IP+Ethernet war ursprünglich nicht der allgegenwärtige Standard wie heute. Mitte der 1980er Jahre war Cisco Systems das erste Unternehmen, das einen Multiprotokoll-Router auf den Markt brachte. Damals wurde das Internet-Backbone noch von der US-Regierung betrieben, genau genommen von der National Science Foundation (NSF). An vielen Unternehmensstandorten kamen unterschiedliche L2/L3-Protokolle zum Einsatz, darunter AppleTalk, SNA, DECnet, Banyan Vines, Token Ring, IPX/SPX (Novell) und andere. Später kamen viele andere L1/L2-Protokolle auf den Markt, darunter etwa Fiber Distributed Data Interface (FDDI) und Asynchronous Transfer Mode (ATM) in den 1990er Jahren.

Heute jedoch hat sich die Kombination aus TCP/IP und Ethernet klar durchgesetzt. Denn es handelt sich um offene Standards, die leicht verfügbar sind, in der Regel keinen Vendor-Lock-in erzeugen und 80-90 % aller Netzwerkprobleme lösen. Jeder, der sich mit dieser Kombination gut auskennt, kann dadurch problemlos von einem Szenario (zum Beispiel Campus-Netzwerk) zu einer anderen Lösung (zum Beispiel Internet-Backbone-Netzwerk) wechseln.

Die Geschichte von Linux verlief im Grunde durchaus ähnlich. Es war nicht die erste UNIX-Variante, die auf der x86-Plattform lief: diese Ehre gebührt SCO/Microsoft Xenix. Viele Jahre lang war Linux früheren UNIX SVR4-Varianten wie Solaris und AIX unterlegen, welche besseren Support, symmetrisches Multiprocessing und noch einige weitere Vorzüge zu bieten hatten. Doch wie TCP/IP+Ethernet hat sich Linux im Laufe der Zeit immer weiter durchgesetzt, da es ein offener Standard ist, der leicht zugänglich ist und der es ermöglicht, einen Vendor-Lock-in zu vermeiden. Linux ist in rund 80 – 90 % der Fälle die Antwort auf die Frage nach dem Betriebssystem für fast jede Lösung, vom Raspberry Pi bis hin zu riesigen HPC-Clustern (High Performance Computing). Heute laufen die meisten Rechenzentren der Welt unter Linux.

Dies führt uns zu Kubernetes

Schon seit einiger Zeit ist absehbar, dass Kubernetes den Kampf um die Bereitstellung von Anwendungen gewinnt. Es begann zunächst als Cloud-native Lösung für Scale-Out-Anwendungen. Im Laufe der Zeit hat es sich aber in die Breite weiterentwickelt, so dass es jetzt für Legacy-Anwendungen, Virtualisierung und so gut wie jedes andere entsprechende Szenario verwendet wird. Dabei kann es sich um einen Raspberry Pi, Microsoft Windows, große HPC-Cluster oder eine sonstige Infrastruktur handeln. Entscheidende Faktoren sind, dass die Architektur sauber und erweiterbar aufgebaut ist und eine API existiert, die sowohl Betreibern als auch Entwicklern entgegenkommt. Sie bietet eine Abstraktionsschicht, die bei der Softwareentwicklung auf einem Laptop ebenso funktioniert wie in einer Produktionsumgebung.

Kubernetes ist nicht der erste Versuch einer Anwendungsplattform. Vorher gab es WebLogic und WebSphere, die zwar ausschließlich Java-Anwendungen unterstützten, aber eine ähnliche Absicht verfolgten: die Paketierung und Bereitstellung von Anwendungen zu vereinfachen. Auch bei der Virtualisierung könnte man von vergleichbaren Intentionen sprechen. In den letzten zehn Jahren hat sich Kubernetes jedoch immer mehr durchgesetzt, bis hin zu dem Punkt, an dem sich jetzt VMs, WebLogic oder WebSphere auf Kubernetes ausführen lassen.

Kubernetes hat sich zum De-facto-Standard für die Bereitstellung von Anwendungen entwickelt. Wie TCP/IP+Ethernet und Linux vor ihm löst es 80-90 % der Probleme bei der Paketierung, Bereitstellung und dem Betrieb von Anwendungen. Es handelt sich um einen offenen Standard, der leicht verfügbar ist und mit dem ein Vendor-Lock-in vermieden wird. Am wichtigsten ist vielleicht, dass es über eine integrierte Architektur verfügt, die den Betrieb unterstützt und kontinuierliche Upgrades, eine klare Aufteilung von Pods, eine erweiterbare API und vieles mehr ermöglicht. Diesen Sachverhalt kennen wir sehr gut. Wir waren die ersten, die die Kontrollebene von OpenStack mit Mirantis OpenStack on Kubernetes (MOSK) auf Kubernetes gesetzt haben. Uns war früh klar, dass sich Kubernetes letztendlich durchsetzen würde – es kann zwar komplex sein, aber die Vorteile, die sich aus der Verwendung ergeben, waren einfach von Anfang an zu groß, um sie zu ignorieren.

Kubernetes „All the Way“

Und damit kommen wir zum eigentlichen Kern: Wie lässt sich jetzt, da Kubernetes sozusagen „gewonnen“ hat, die schier nicht enden wollende Flut von Kubernetes-Clustern verwalten? Die meisten großen Unternehmen setzen es überall ein: AWS EKS, Google GKE, Microsoft AKS, Mirantis MKE, generisches Kubernetes und so weiter und so fort. Ob On-Premises oder in einer öffentlichen Cloud: K8s ist quasi überall, und es wächst geradezu wie Unkraut. Was ist die Lösung dafür? Nun, natürlich Kubernetes selbst! 

Denn es hat sich herausgestellt, dass der beste Weg, dem Kubernetes-Wildwuchs Herr zu werden, darin besteht, Kubernetes als Steuerungsebene zu verwenden, um andere Kubernetes-Cluster zu verwalten. Kubernetes kann sozusagen zum natürlichen „Kontrollpunkt“ für das Management von Kubernetes werden, der eine breite Palette von Containern und virtualisierten Workloads unterstützt und die Abstraktion der Infrastruktur ermöglicht.

Beispielsweise separiert k0smotron die Kontrollebene (verwaltete Cluster oder Control Nodes) und die Datenebene (verwaltete Cluster oder Worker Nodes) voneinander. Dadurch entsteht ein einheitlicher Kontrollpunkt für Kubernetes-Cluster. Dies erhöht die Skalierbarkeit, erlaubt es, einzelne Bereiche zu trennen (zum Beispiel Upgrades der Steuerebene getrennt von den Datenebenen) und Cluster über verschiedene Anbieter hinweg zu verwalten (unabhängig von den Infrastrukturoptionen). Durch die Verwendung von Kubernetes-Clustern lässt sich auf diese Weise der „Heilige Gral“ der hybriden Multi-Cloud erreichen. Anders ausgedrückt: Es spielt letztlich gar keine Rolle mehr, wo sich Cluster befinden, da sie sich alle von einem einzigen Kontrollpunkt aus verwalten lassen.

Kubernetes ist die Lösung für Kubernetes

„Kontrollpunkt“ bedeutet in diesem Fall, dass es in jedem IT-System normalerweise einen natürlichen Kontrollpunkt gibt, um mit diesem System zu interagieren und es zu verwalten. Bei Amazon Web Services ist beispielsweise die AWS-API/UI der natürliche Kontrollpunkt für das Management des Systems. Bei Java-Anwendungen ist es JVM. Die meisten Systeme haben einen solchen „Kontrollpunkt“, auch wenn ihre Kontroll- und Datenebenen zusammengelegt sind. Das Besondere an modernen Kontrollpunkten ist, dass sie fast immer über eine API verfügen. Bei älteren Kontrollpunkten war dies hingegen weit weniger wahrscheinlich. In der heutigen Zeit der allgegenwärtigen Automatisierung müssen alle Kontrollpunkte über eine API verfügen.

Kubernetes ist daher hervorragend aufgestellt, um sich selbst zu verwalten. Über die Cluster-API (CAPI) lässt sich Kubernetes nutzen, um Kubernetes zu managen, denn als Kontrollpunkt kann es andere Kontrollpunkte verwalten. Cluster API umfasst zum Beispiel „Provider“ für Amazon (CAP-A), Azure (CAP-Z), VMware (CAP-V), Bare Metal und vieles mehr.

Das bedeutet, dass alle erforderlichen Tools zur Verfügung stehen, um Kubernetes dafür einzusetzen, die „Herausforderung Kubernetes“ gewissermaßen selbst zu bewältigen. Die Antwort auf den Kubernetes-Wildwuchs ist Kubernetes selbst. Als offener Standard ist Kubernetes die naheliegende Lösung für die Verwaltung von Clustern sowohl On-Premises als auch in der Cloud. Erste Umsetzungen auf der Steuerungsebene – wie zum Beispiel k0smotron – haben die grundsätzliche Richtung aufgezeigt. Mit dem Open-Source-Projekt k0rdent steht zudem eine Distributed-Container-Management-Environment-Lösung (DCME) zur Verfügung. Sie ermöglicht es, Kubernetes-Cluster auf jeder Infrastruktur zu managen. Jetzt ist es an der Zeit, den nächsten Schritt zu gehen.

Autor: Randy Bias, Vice President Open Source Strategy & Technology bei Mirantis