Kannibalismus und Implosion Kubernetes killt OpenStack

Anbieter zum Thema

Dell GmbH

DataCore Software GmbH

Schwarz IT KG

Der anhaltende Auftrieb, den Kubernetes seit Jahren erfährt, nimmt anderen Technologien Wind aus den Segeln. So stellt sich die Frage, ob Kubernetes auch die Existenz von OpenStack bedroht. Dazu: Julian Fischer, CEO der Berliner Anynines GmbH, mit einer Insider-Sicht.

Ohne Frage hat OpenStack eigene Probleme. Nicht wenige haben unterschätzt, wie schwer die Transformation eines bestehenden Rechenzentrums in eine moderne virtualisierte Infrastruktur ist. Viele sind dabei an technischen oder finanziellen Barrieren gescheitert. Von mangelnder Stabilität bis zur fehlenden Wirtschaftlichkeit reichen die Gründe für die vorzeitige Beendigung solcher Vorhaben.

Zudem ist der Umgang mit virtuellen Infrastrukturen alles andere als einfach, sofern sie einmal stabil sind. Ihr Betrieb ist ebenso herausfordernd wie ihre Benutzung.

Die Orchestrierung virtueller Maschinen hat einen enormen Fortschritt beim Betrieb komplexer, verteilter Anwendungen gebracht. Die initiale Einrichtung vielteiliger Anwendungssysteme kann seither mit Automatisierung beschrieben werden. Ephemeral Virtual Machine (VM) und persistent Disk wurde zu einem zentralen Automatisierungsparadigma.

Die Optimierungsschwelle

In diesem Paradigma aber verzichtet man darauf, die Verfügbarkeit einer einzelnen VM weiter zu steigern. Man bewegt sich an den Punkt, bei dem der Nutzen je zusätzlich eingesetztem Euro beginnt rapide abzunehmen. An diesem optimalen Preis-Leistungsverhältnis sollte sich eine Infrastruktur bewegen und mit der resultierenden Verfügbarkeit hat der Softwarebetrieb auszukommen.

Eine höhere Verfügbarkeit wird dabei für persistente Daten gefordert, so für die Daten einer Datenbank. Diese liegen auf einem hochverfügbaren Storage-Server, der seine Kapazität in virtuellen Netzlaufwerken anbietet. Eine VM mounted diese Netzlaufwerke zur Speicherung von Daten, die das Ableben der VM überdauern sollen. Aus diesem Vorgehen ist die Idee selbstheilender Systeme erwachsen:

Eine gescheiterte VM, sei es aufgrund eines Fehlers oder aber einer geplanten Wartung des Host-Systems, wird schlichtweg auf einem anderen Infrastruktur-Host neu erstellt und das zugehörige Netzlaufwerk wieder eingehängt. Diese Methode führt zu Reparaturzeiten im Bereich weniger Minuten.

Overhead

Der Nachteil dieser Methode liegt einerseits im enormen Overhead der vielen beteiligten VMs. Um eine klare Trennung der Verantwortlichkeiten herbei zu führen, sind für ein mittleres Anwendungssystem schnell mehrere Dutzend in Verwendung. Dazu kommt: Jede VM betreibt ein eigenes Betriebssystem oder zumindest einen eigenen Kernel. So sind für jede VM schnell mehrere Hundert Megabyte Arbeitsspeicher verbraucht.

Es dauerte nicht lange, bis die Technologiegemeinschaft diese Verschwendung erkannte und mit dem Aufkommen von containerbasierten Anwendungsplattformen wie „Heroku“ und später Cloud Foundry reagierte. Anwendungsplattformen zielen dabei direkt auf Anwendungsentwickler ab.

Die Rolle der Systemadministratoren gliedert sich dann in zwei DevOps Rollen auf. Den Anwendungsentwickler mit Betriebswissen sowie den Plattformbetreiber einem groben Verständnis für Anwendungsentwicklung. Durch die Containerisierung der Anwendungen wird der Speicher und CPU-Overhead von VMs auf den von Containern reduziert. Je mehr Anwendungen betrieben werden, umso stärker macht sich dieser Effekt bemerkbar.

Die Buildpacks

Das Container-Movement, das von vielen mit dem Containerdienst Docker assoziiert wird, hat die Technologiegemeinde auf ein Neues begeistert. Ein standardisiertes Format für Bau, Speicherung und Verteilung von Container-Images sind wichtige Merkmale dieser Bewegung. Anwendungsentwickler erhalten die Möglichkeit, Anwendungen lokal zu verpacken, um diese dann in entfernten Umgebungen zu betreiben.

Diese Vorgehensweise stellt eine Alternative zur Verwendung so genannter Buildpacks dar, wie sie von Anwendungsplattformen wie Heroku und Cloud Foundry bekannt sind. Unter der Verwendung solcher Buildpacks verantwortet der Anwendungsentwickler lediglich den Code seiner Anwendung und überlässt die Transformation dieses Codes zu einer ausführbaren Web-Anwendung dem Buildpack.

Im Gegensatz hierzu ist der Anwendungsentwickler selbst in der Pflicht, wenn er seine eigenen Container Images erstellen möchte. Inzwischen gibt es jedoch auch die Möglichkeit Buildpacks zur Erstellung von Container Images zu verwenden.

Das unabdingbare Orchestrieren

Das Aufkommen des Container-Trends hat, analog zum früheren Aufkommen virtueller Maschine, die Aufgabe der Orchestrierung auf den Plan gesetzt. Ebenso wie virtuelle Infrastrukturen das Scheduling von virtuellen Maschinen orchestrieren muss, muss eine Container-Plattform Container orchestrieren. Heute lässt sich klar sagen, dass dieser Wettbewerb, manchmal auch als „Container Orchestration War“ bezeichnet, klar von Kubernetes gewonnen wurde. Dies hat weitreichende Konsequenzen für viele angrenzende Technologien.

Keine Liebe auf den ersten Blick

Es ist kompliziert - Cloud Foundry und Kubernetes

Anwendungsplattformen, beispielsweise Cloud Foundry, passen sich an, in dem sie unter anderem ihren Container-Orchestrierer, das „Diego“-Subsystem, durch Kubernetes ersetzen. Darüber hinaus haben diese Anwendungsplattformen oft einen recht schwergewichtigen Infrastruktur-Fußabdruck.

Um sie zu betreiben, müssen Dutzende virtuelle Maschinen existieren und verwaltet werden, Benutzer-Anwendungen nicht mitgezählt. Dadurch werden viele Hundert Gigabyte an Arbeitsspeicher sowie eine hohe Anzahl an virtuellen CPUs durch die Anwendungsplattform selbst beansprucht.

In der Konsequenz haben Anwendungsplattformen eine hohe Anforderung an ihre Economy of Scale. Es müssen viele Anwendungen auf ihnen betrieben werden, damit eine solche Plattform Skaleneffekte entfaltet, die ihre Wirtschaftlichkeit sichert. Dann aber sind diese Plattformen mit zunehmendem Wachstum enorm effizient. Ein überschaubares Betriebsteam kann so leicht viele Tausend Anwendungsinstanzen verantworten.

Erneuter Optimierungsbedarf

Es zeichnet sich der Bedarf ab, Anwendungsbetrieb effizienter und benutzerfreundlicher zu gestalten. Beispiele sind in allen vorgenannten Technologien zu finden. Auch an diesem Bedürfnis scheint Kubernetes an Schwung zu gewinnen.

Kubernetes stellt eine dekorative Sprache zur Verfügung, um verteilte Arbeitslasten zu beschreiben. Anders als bei reinen Anwendungsplattformen wie Cloud Foundry können hier nicht nur zustandslose Anwendungen betrieben werden, während zustandsbehaftete Dienste wie Datenbanken extern zur Verfügung stellt werden müssen. Auch Datenbanken können mit Hilfe von so genannten Stateful Sets betrieben werden, wenngleich hier die schwächere Isolation von Input/Output-Lasten Herausforderungen mit sich bringt.

Es verwundert also nicht, dass diese Kubernetes innewohnende Flexibilität dazu führt, dass Kubernetes nicht nur im Lager der Anwendungsplattformen, sondern auch im Lager der virtuellen Infrastrukturen wildert. Sofern man die Annahme trifft, dass sich Kubernetes durch seine schnelle Verbreitung bald in jedem Rechenzentrum, auf die ein oder andere Weise, vorfinden lässt, ergeben sich interessante Implikationen für die Automatisierung von Lasten, die typischerweise in virtuellen Maschinen verpackt werden würden.

Infrastrukturneutralität

Jeder, der einmal die Aufgabe hatte, große, komplexe Anwendungssysteme global und deswegen infrastrukturübergreifend, zu automatisieren, kennt den damit verbundenen Schmerz. Es gibt inzwischen eine Vielzahl öffentlicher sowie on-premises fähiger Infrastrukturanbieter und jeder dieser Anbieter bringt eine eigene, meist imperative, Application Programming Interfaces (APIs) zur Fernsteuerung mit.

Dies führt den Automatisierungsentwickler vor die Aufgabe eine Infrastrukturabstraktion vorzunehmen, für die es zwar viele Ansätze und Werkzeuge gibt, sich aber dennoch ein beträchtlicher Mehraufwand ergibt, vergleicht man mit der Automatisierung auf einer einzelnen Infrastruktur. Hieraus ergibt sich wiederum eine große Verschwendung.

Genau aus diesem Grund hängt das Wohl und Wehe von Anwendungsplattformen wie Cloud Foundry auch davon ab, diese Infrastrukturunabhängigkeit zu gewährleisten, während gleichzeitig die Betriebsaufwände zu minimieren sind. Cloud Foundry hat diese Aufgabe in einem eigenen Infrastrukturautomatisierungswerkzeug mit der Bezeichnung „BOSH“ gelöst.

Pods auf der Virtualisierungsebene und Virtualisierung in Pods

Sofern aber auf jeder Infrastruktur eine Kubernetes zu Verfügung steht und Kubernetes sich zumindest fast genauso gut dazu eignet, schwergewichtige, zustandsbehaftete Anwendungssysteme zu betreiben, könnte man der Idee folgen, Anwendungssysteme grundsätzlich auf Kubernetes zu betreiben. So erklärt es sich, dass Entwickler in Organisationen heute zuerst nach Kubernetes fragen und mit der darunter liegenden Infrastruktur nur noch das Notwendigste zu tun haben wollen.

Es ist eben bequem eine Sprache zu sprechen, um Anwendungslasten zu beschreiben und die heißt: Kubernetes. So verwundert es kaum, dass Cloud Foundry zuerst den Container-Orchestrator gegen Kubernetes austauscht, um im zweiten Schritt alle anderen Cloud Foundry Komponenten auf Kubernetes umzuziehen.

Betrachtet man an dieser Stelle nun den durchschnittlichen on-premises Cloud-Stack, so gibt es einen Hardware-Layer auf dem sich das physikalische Netzwerk, die VM-Hosts, Storage Server und dergleichen befinden. Darüber gibt es eine Virtualisierungsebene, die aus Infrastrukturen wie „VMware vSphere“ oder OpenStack bestehen kann. Auf dieser virtuellen Infrastruktur wird dann ein oder werden mehrere Kubernetes-Cluster betrieben, die wiederum durch VMs realisiert sind. So laufen Anwendungs-Pods dann in Kubernetes Node VMs.

Eroberungszüge

An diesem Punkt hat Kubernetes bereits einen großen Teil der virtuellen Infrastruktur kannibalisiert: nämliche die Interaktion mit den Benutzern. Die Infrastruktur dient somit nur noch als Erfüllungsgehilfe und hat die Dominanz der APIs eingebüßt.

Die Eroberung des Infrastrukturterritoriums ist jedoch noch nicht abgeschlossen. Wieder erblickt das geschulte Auge Optimierungspotential. Denn die Orchestrierung von virtuellen Maschinen sowie die von Containern sind einander sehr ähnlich. In beiden Fällen gibt es eine Ressourcen-Anfrage, die aus dem Pool vorhandener Hosts oder Nodes bedient werden muss, um entweder eine VM oder einen Pod zu platzieren.

Sicherheitsaspekte

Bei der Beschreibung von Anwendungslasten in Kubernetes tritt in manchen Situationen zudem ein Problem zutage, das weniger in der Struktur von Kubernetes, als mehr in der Implementierung gängiger Container Dienste zu finden ist, nämlich das der schwachen Container-Isolation. Ein Container ist meist ein vom Betriebssystem abgetrennter Speicherbereich mit einer zugewiesenen Anzahl an CPU-Shares.

Während es zusätzlich Beschränkungen zur Nutzung von Festplattenkapazität gibt, fehlt indes meist jede Beschränkung hinsichtlich Ein- und Ausgabe-Operationen auf Festplatte und Netzwerk. Somit wäre ein Container in der Lage andere Container auf dem gleichen Host oder gar dem gleichen Netzwerk in ihrer Leistungsfähigkeit zu beeinflussen. Die Performance von Containern wäre zunehmend unvorhersehbar.

Nun wäre es möglich I/O-kritische Lasten auf dedizierten Kubernetes Nodes zu isolieren, indem affinity oder anti-affinity Regeln verwendet werden. Dieser Eingriff in den Platzierungsalgorithmus von Kubernetes stellt jedoch eine Verantwortung für den betreffenden Entwickler dar. Sie ließe sich vermeiden, wären die Container stärker isoliert.

Mehr noch: Die Platzierung von automatisch provisionierten kritischen Workloads im Kubernetes-Cluster setzt weiterhin voraus, dass freie Kubernetes-Knoten zur Verfügung stehen, um die kritische Last zu isolieren. Man verwendet die Eigenschaft eines Kubernetes-Knoten als Mittel, um an die Vorzüge einer virtuelle Maschine zu gelangen. Es handelt sich hierbei bestenfalls um einen Workaround.

Isolation gewünscht

Die deutlich elegantere Lösung bestünde darin Kubernetes beizubringen, stark isolierte Container zu erzeugen. Da stark isolierte Container, zum Beispiel repräsentiert durch klassische virtuelle Maschinen, jedoch länger brauchen, um zu starten und gleichzeitig mit deutlich mehr Overhead einhergehen, wäre diese Lösung nur für kritische Arbeitslasten sinnvoll.

So erwächst der Bedarf nach mehreren Container-Klassen in Kubernetes, bei dem eine Klasse den leichtgewichtigen Container und eine weitere Klasse die stark isolierte Variante zur Verfügung stellt. So bietet VMware seit dem „Projekt Pacific“ die Möglichkeit, VMs unter Verwendung der Kubernetes-API zu erzeugen, die die Rolle stark isolierter Container erfüllen.

Dieses Problem der sprungfixen Kosten von Container zur klassischen virtuellen Maschine ist Gegenstand aktueller Entwicklungen. Gesucht ist eine Technologie, die einerseits stärker Isoliert aber andererseits wenig Speicher-Overhead mitbringt und zudem noch schnell startet.

Bare Metal

Solche Technologien gibt es bereits, unter anderem mit „Amazon Firecracker“, einer Software zu Erstellung leichtgewichtiger VMs. Folgerichtig gibt es auch bereits erste Kubernetes-Distributionen, die Amazon Firecracker einsetzen, um wohl isolierte Container zur Verfügung zu stellen.

Ein weiterer Zweig aktueller Kubernetes-Distributionen ist die Installation von Kubernetes auf Hardware (Bare Metal). Hier übernimmt Kubernetes ungeniert die Rolle der virtuellen Infrastruktur. Gerade in diesen Szenarien ist eine stärkere Container-Isolation wichtig, um die vorgenannten Isolationsprobleme (Noisy Neighbours) zur verhindern. Skepsis ist also angesagt, wenn eine Kubernetes-Distribution direkt auf der Hardware installiert wird, aber Standard-Container einsetzt.

Abschließend lässt sich zusammenfassen, dass Kubernetes zweifelsfrei einen starken Einfluss auf die Hersteller von Infrastruktur ausübt. OpenStack ist hierfür ein Beispiel aber auch VMware sowie öffentliche Infrastrukturen sind betroffen. Hierbei ist zu betrachten, dass verschiedene Hypothesen erprobt werden.

Aufsatteln, Einsinken, Ersetzen

Vom `Aufsatteln´ der Kubernetes-Cluster unter Verwendung von VMs auf, über das `Einsinken´ der Kubernetes-API in Virtualisierungsprodukte, bis zum vollständigen Ersetzen klassischer Virtualisierung reicht die Plätte aktueller Versuche auf den schwungvollen Kubernetes-Trend zu reagieren. Sofern sich auf jedem dieser Varianten zahlende Kunden einschwören, ist auch eine bestimmte Mindestlebensdauer dieser Ansätze zu erwarten.

So werden vermutlich noch über Jahre Kubernetes-Cluster in VMs verpackt werden und die Investitionen in bestehende Infrastrukturen ordnungsgemäß abgeschrieben werden. Es wird sich mit der Zeit aber die Spreu vom Weizen trennen. Manche Ansätze werden nach und nach verschwinden und andere an Popularität gewinnen.

Wer spekulieren mag, könnte postulieren, dass zu viele aufeinander geschichtete Technologie-Ebenen mit der Zeit unter ihrem eigenen Gewicht kollabieren werden. Dies würde den Ansatz begünstigen, die Kubernetes API beizubehalten und nach und nach mit verschiedenen Varianten von Virtualisierungstechniken zu verschmelzen bis die ein nahtloser Übergang zwischen VMs und Containern angenähert ist.

Was passieren wird ...

Entwickler sehen dann Kubernetes, sei es auf kleinen Edge-Devices, im on-premises Rechenzentrum oder auf der öffentlichen Infrastruktur. Die Verwendung von Begriffen der Kategorien Betriebssystem, Serverarchitektur und Hypervisor werden im Sprachgebrauch der Entwickler abnehmen.

Letztendlich wird hierdurch der Fokus auf das Wesentliche gestärkt, die Beschreibung der Arbeitslasten mit Hinblick auf ihren geschäftlichen Nutzen. Technik tritt in den Hintergrund.

Dies wird vermutlich nicht den Tod von OpenStack oder vergleichbaren Technologien bedingen, wohl aber deren Entwicklung zur Commodity vorantreiben, die nur durch eine stärkere Integration von Kubernetes abgefedert werden kann.

* Julian Fischer, CEO des 2008 gegründeten Unternehmens Anynines GmbH, das in Berlin und Saarbrücken angesiedelt ist, hat als Experte für Digitale Transformation bereits an hunderten IT-Konferenzen teilgenommen - und dabei auch dutzende Male Vorträge gehalten. Er hat mehrere Anwendungsplattformen mit diversen Automatisierungslösungen aufgebaut. Sein aktuelles Interesse gilt Cloud Foundry, BOSH und Kubernetes. Die Automatisierung von Data Services ist zu seiner Leidenschaft geworden.

(ID:46974795)