Keine Liebe auf den ersten Blick Es ist kompliziert - Cloud Foundry und Kubernetes

Die Cloud Foundry und Kubernetes stehen für mehr als nur für zwei Technologien. Sie bezeichnen zwei Ökosysteme, umfassen viele Subsysteme, Paradigmen und natürlich Menschen. Während Kubernetes sich als Grundbaustein bei der Container-Orchestrierung durchgesetzt hat, hat sich Cloud Foundry in vielen Großunternehmen durch Umfang und Verlässlichkeit etabliert.

Anbieter zum Thema

Dell GmbH

Fujitsu Technology Solutions GmbH

Schwarz IT KG

Cloud Foundry Foundation

Folgendes ist zu beobachten: Das Kubernetes-Ökosystem konvergiert in Richtung Cloud Foundry und das Cloud Foundry Ökosystem umgekehrt auch in Richtung Kubernetes.

Es wird dabei wohl keine Kollision beider Ökosysteme geben, die zur Auslöschung von Cloud Foundry führen wird. Wohl aber umkreisen sich diese beiden schwergewichtigen Himmelskörper und bewegen sich spiralförmig aufeinander zu. Am Ende zählt eben nicht die Implementierung, sondern die User Experience. Es zählt der Nutzen. Für den Anwendungsentwickler ebenso wie für den Plattformbetreiber.

Versus

Was bleibt sind viele Fragen. Setzt sich etwa „Knative“ mit „KF“ gegen „ERINI“ durch? Noch ist es zu früh, um hierzu eine klare Aussage zu machen. Zu beobachten ist aber zweifelsfrei, dass Cloud Foundry und Kubernetes einander beeinflussen und dabei etwas Neues entsteht.

Für den Anwendungsentwickler und Plattformbetreiber wird dabei gar nicht so wichtig sein, wie das Ergebnis später genannt wird. Mag es später auch in der Kubernetes-Schublade landen, so ist nur wichtig, dass die resultierende Plattform einfach und mit einem möglichst hohen Automatisierungsgrad betrieben werden kann und die Anwendungs-Deployments einfach vonstattengehen. Produktivität zählt.

Cloud Foundry

Cloud Foundry ist eine ausgewachsene Technologie zur Steigerung der Produktivitiät von Anwendungsentwicklern. Sie entstand um das Jahr 2009 im Hause VMware, bevor später - über Umwege - die Übertragung des zugrundeliegenden geistigen Eigentums als Open-Source-Projekt in die Cloud Foundry Foundation erfolgte.

Die Qualität und Robustheit von Cloud Foundry ist kontinuierlich gestiegen und hat früh Produktionsreife erlangt. Getrieben durch die Mitglieder der Cloud Foundry Foundation ergab sich eine starke Verbreitung der Technologie in Großunternehmen. Cloud Foundry wurde dort zu einem Eckpfeiler der digitalen Transformation.

Dies ist unter anderem Qualitäten wie der Infrastrukturagnostik sowie der soliden Skalierbarkeit und Verlässlichkeit von Cloud Foundry zu verdanken. Es mag dem Einzelnen schwergewichtig erscheinen, ein Werkzeug wie BOSH erlernen zu müssen; für den langfristigen Betrieb großer Plattformen, die mehrere tausend virtuelle Maschinen umfassen, hat diese Basis-Technologie jedoch Alleinstellungsmerkmale.

Der Umgang mit Cloud-Foundry-Techniken

Die Möglichkeit, Anwendungen über die Verwendung von sog. Buildpacks in Betrieb zu nehmen, ist für den Anwendungsentwickler bequem und lässt dem Plattformbetreiber Kontrollmöglichkeiten. Gerade Großunternehmen können so die Verwendung auf bestimmte, von der internen IT-Security geprüfte Buildpacks freigeben und damit den Entwicklern Wahlmöglichkeiten einräumen, während gleichzeitig die Einhaltung etwaiger Sicherheitsanforderungen gewährleistet werden kann.

Die Verwendung von Container-Images ist in Cloud Foundry als Alternative möglich und kann - je nach Bedarf - aktiviert oder deaktiviert werden.

Entwicklern die Erstellung und Wartung von Container-Images zu überlassen, gewährt diesen einerseits bislang ungekannte Freiheiten, schränkt andererseits allerdings auch die oben genannten Kontrollmöglichkeiten ein. Dadurch entsteht die Notwendigkeit, vorgelagerte Sicherheitsvorschriften für die Erstellung und Ausbringung von Anwendungen zu verwenden, die sonst vom Plattformbetrieb hätten behandelt werden können. Ein Cloud Foundry Buildpack beispielsweise lässt sich leichter zentral auf Sicherheit prüfen, als eine Hierarchie von Container-Images.

Die Voraussetzungen

Es lässt sich zusammenfassen, dass Cloud Foundry im Rahmen der digitalen Transformation großer Organisation einen Katalysator für Produktivität darstellt. Es profitieren alle beteiligten Parteien davon - vom Anwendungsentwickler bis hin zum Plattformbetreiber.

Um diese Produktivitätssteigerung zu erfahren, sind jedoch auch einige Voraussetzungen zu erfüllen. Anwendungen müssen cloud-native oder, in anderen Worten ausgedrückt, 12-factor-compliant sein. Die damit verbundenen Anforderungen an die Anwendungsarchitektur beinhalten Forderungen wie die nach Zustandslosigkeit oder die nach einer Widerstandsfähigkeit gegen die unangekündigte Beendigung von Prozessen.

Damit werden Entwickler zur Einhaltung von Best Practices ermutigt, von denen auch ein `klassischer´ Softwarebetrieb profitieren würde. Die Kehrseite dieser Medaille wird klar. Es bleiben viele Bestandsanwendungen zurück, die sich im Zustand der Wartung und nicht mehr der aktiven Weiterentwicklung befinden. Diese Anwendungen qualifizieren sich nicht für den Betrieb in einer Cloud Foundry Runtime.

Kubernetes

Im Gegensatz zu Cloud Foundry gibt es in Kubernetes keine strikte Forderung nach Zustandslosigkeit. Im Aufwind der Docker-Bewegung hat Kubernetes Momentum aufgenommen. Damit verbunden ist auch die Unterstützung von zustandsbehafteten Containern unter Verwendung von persistenten Laufwerken.

Die Trennung von kurzlebigen (ephemeral disk) und persistenten Laufwerken (persistent disk) ist ein fundamentales Paradigma des modernen Cloud-Betriebs, das auf jeder modernen Infrastruktur Berücksichtigung und auch im Cloud Foundry Ökosystem seine Manifestation bei den persistent disks von BOSH findet.

Der Unterschied in Kubernetes besteht darin, dass es keine künstliche Trennung von zustandslosen (stateless) und zustandsbehafteten (stateful) Anwendungen gibt. Während in Cloud Foundry stateless Apps betrieben werden, ist für stateful Apps, zum Beispiel Datenbanken, das BOSH-Tooling zu verwenden.

Zweimal Know-how

BOSH zu nutzen, impliziert die Verwendung von virtuellen Maschinen anstatt von Containern bei Cloud Foundry. Es müssen also zwei Technologien beherrscht werden. Es scheint dabei nicht wirklich zu interessieren, dass die Container-Isolation einer Isolation mittels einer Virtuellen Maschine (VM) unterlegen ist und sich für einen Datenbankbetrieb eigentlich nur in eingeschränktem Umfang eignet.

Was zählt, ist vor allem die Möglichkeit, die unzähligen Legacy Apps, welche in einer größeren Organisation betrieben werden wollen, mit Kubernetes nun auch in die Cloud zu bringen. Jeder IT-Leiter kann künftig seinem Management stolz vermelden: „Wir sind nun in der Cloud.”

Kubernetes, das neue OpenStack?

Kubernetes wildert somit nicht nur im Gehege von Cloud Foundry. Auch im Segment der Infrastruktur pflanzt Kubernetes neue Triebe. Insbesondere wird hier das Vakuum gefüllt, das durch enttäuschte Erwartungen an OpenStack, gerade in On-Premise-Szenarien, verursacht wurde. Unzählige, mit großem Optimismus und teils sogar mit Euphorie begonnene OpenStack-Installationen in den Rechenzentren blieben hinter den Erwartungen eines Instant-AWS im eigenen Rechenzentrum zurück und sorgten damit bei ihren einst so hoffnungsvollen Betreibern letztlich zu einer großen Ernüchterung.

Während die einen entmutigt aufgeben und in die Fänge öffentlicher Infrastrukturanbieter geraten, wenden sich andere trotzig alternativen Lösungen für das eigene Rechenzentrum zu. Auch hier tankt Kubernetes kinetische Energie aus einem vorhandenen Industrietrend: der teilweisen Abkehr von OpenStack.

Mit dem Aufkommen von Kubernetes-dominierten Platform-Distributionen - wie beispielsweise von IBM und Suse - ergibt sich eine Trendwende. Wer braucht schon OpenStack, wenn es Kubernetes gibt? Wer braucht VMs, wenn er Container haben kann?

Wer braucht schon virtuelle Maschinen?

Wir werden es sehen. Denn einige Hersteller verfechten nun einen Cloud-Stack mit einem Hyperfokus auf Kubernetes. Bei der Umsetzung eines solchen Konzepts wird Kubernetes direkt auf die Hardware installiert. Somit fällt eine virtuelle Infrastruktur wie VMware oder OpenStack weg.

Es ist auch zu erwähnen, dass es Kubernetes durch die Verschmelzung von sämtlichen Arbeitslasten innerhalb eines Kubernetes-Clusters selbst an einem Pendant zu BOSH fehlt. Kubernetes selbst muss ja auch betrieben werden - und diese Aufgabe ist nicht trivial.

Es gibt zwar Tools wie „Kops“, diese sind aber nicht im gleichen Maße infrastrukturunabhängig ausgeführt. Es ist ein bedeutender Unterschied, ob eine Automatisierungstechnologie lediglich mehrere Plattformen unterstützt oder aber durch eine geeignete Abstraktion eine weitreichende Plattformunabhängigkeit erreicht wird.

Während der Aufwand zur Integration weiterer Infrastrukturen im ersten Fall hoch ist, ist er im Falle einer Abstraktion deutlich geringer. Es ist mit BOSH leichter, eine vorhandene Automatisierung über Infrastrukturen hinweg zu betreiben - sei es in On-premise- oder Public-Cloud-Szenarien. Ein Wildwuchs an Lösungen könnte die Folge sein, sofern sich kein allgemein akzeptiertes Werkzeug für den Betrieb von Kubernetes etablieren sollte.

Installation, Konfiguration und Wartung - was wie zun?

Das volle Commitment eines Plattformherstellers zu Kubernetes führt zu weiteren Kosten. So fehlt im Kubernetes Ökosystem noch ein ausgereiftes, mit BOSH - dem De-Facto-Standard zum Betrieb von Cloud Foundry - vergleichbares Hilfsmittel. BOSH kann zwar so ziemlich jede Virtualisierungslösung mit Rang und Namen ansprechen, bislang jedoch keine Kubernetes-Pods befehligen. Aus diesem Grund muss eine reine Kubernetes -Plattform eine alternative Art der Ausbringung - d. h. der Installation, Konfiguration und Wartung - von Cloud Foundry finden.

Das Projekt EIRINI ist in dieser Idee entsprungen. EIRINI verpackt eine Cloud Foundry Runtime in native Kubernetes-Ressourcen und benutzt Kubernetes anstelle von „Diego“ als Lösung zur Container-Orchestrierung.

Die Kehrseite der Abkehr von mit BOSH orchestrierten virtuellen Maschinen hin zu Containern mit Kubernetes besteht in starken Einbußen bei der Isolation von Arbeitslasten. Ein Container ist mit limitierten Mitteln der Betriebssystemvirtualisierung nicht gleichauf mit den Isolationsfähigkeiten von Para- oder Vollvirtualisierern.

Folgen der Abkehr von BOSH

Während CPU und RAM noch getrennt werden, sieht es bei Disk- und Network-I/O schon schlechter aus. Denn ohne eine solide Isolation dieser I/O-Lasten sind zustandsbehaftete Anwendungen, wie Datenbanken, nicht verlässlich zu betreiben.

Zu groß ist die Wahrscheinlichkeit, dass zwei Co-lokierte Container auf einem Container-Host sich gegenseitig die dringend benötigte I/O-Bandbreite abgraben, sei dies nun für eine lokale oder entfernte Disk. Das Ergebnis sind unvorhersehbare Performance-Schwankungen der Datenbanken, die den verlässlichen Betrieb angebundener Anwendungen gefährden.

Nun könnte man durch Host-Affinity- und Anti-Affinity-Tags in den Verteilungsalgorithmus von Kubernetes eingreifen, es stellt sich dabei jedoch die Sinnfrage. Eine solche Komplexität war bei der Verwendung von BOSH im Zusammenhang mit virtuellen Maschinen nicht notwendig.

Wozu sollte also jetzt ein prinzipieller Mangel der gewählten Virtualisierungsart durch eine höhere Komplexität in der Automatisierung kompensiert werden? Abhilfe könnten Kubernetes-Erweiterungen schaffen, die bei Containern zusätzliche Isolationsgrade ermöglichen.

Diego und Kubernetes

Die Container-Orchestrierung innerhalb von Cloud Foundry unterliegt einer anhaltenden Evolution. So wurde dieses Subsystem bereits mehrmals vollständig neu implementiert. Die Einführung der so genannten Droplet Execution Agents (DEA) löste eine ältere Implementierung ab und wurde ihrerseits durch das deutlich besser skalierbare Diego-System abgelöst (siehe: „Differences Between DEA and Diego Architectures“.

Daher ist nicht zu erwarten, dass die alteingesessenen Mitglieder der Cloud-Foundry-Gemeinschaft bei einer weiteren Transformation mit der Wimper zucken. Auch nicht, wenn dabei Kubernetes eingeführt wird. Ganz im Gegenteil, da die Ausrichtung von Kubernetes darin besteht, eine Plattform zur Erstellung von Plattformen zu sein. Infolgedessen ist Kubernetes seiner eigentlichen Bestimmung im Kontext einer Cloud-Foundry-Implementierung deutlich näher als in der oft zu beobachtenden `Kellerinstallation´ im eigenen Rechenzentrum.

Die Implementierung einer Lösung zur Container-Orchestrierung ist eine nicht-triviale Aufgabe, die enorme Kosten erzeugt und für die Erstellung einer Plattform eine zwar notwendige, aber für die Herausbildung von Alleinstellungsmerkmalen leider unzureichende Komponente darstellt. Somit handelt es sich in der Regel um eine wirtschaftlich weise Entscheidung eines Plattformherstellers, die Aufgabe der Aufteilung von Compute-Ressourcen an Kubernetes zu übertragen, anstatt in einen eigenen Container-Orchestrierer zu investieren.

Cloud Foundry lebt unter anderem von der cf push User Experience. Dabei interessiert es den Anwendungsentwickler nur, dass seine Anwendung läuft, aber nicht, wie diese zum Laufen gebracht wurde.

EIRINI

Das Projekt EIRINI setzt den Fokus auf den Nutzen, den eine Cloud-Foundry-Umgebung entfaltet und ersetzt das Diego-Subsystem durch Kubernetes. Indem Kubernetes-Cluster als Infrastruktur-Basis für Cloud-Foundry-App-Container genutzt werden, wird Kubernetes zum Cloud-Foundry-Backend oder umgekehrt Cloud Foundry zum Kubernetes-Frontend.

Diego startet infolge eines cf push Befehls einen Staging-Prozess, bei dem die Ausführung eines Buildpack ein ausführbares Archiv der jeweiligen Anwendung erstellt. Im Unterschied hierzu erzeugt EIRINI im Staging-Prozess ein zu Kubernetes kompatibles Ausführungsformat, nämlich das OCI Image Format. So werden mit EIRINI laufende Cloud Foundry Anwendungen zu Stateful Sets in einem Kubernetes-Cluster.

EIRINI ist somit das Cloud Foundry für Kubernetes-Enthusiasten. Es stellt eine Cloud Foundry Runtime in einer reinen Kubernetes-Umgebung zur Verfügung, indem Anwendungen nun als App-Container in Kubernetes-Clustern betrieben werden. Ja mehr noch, indem die Cloud Foundry Runtime auch selbst in Kubernetes betrieben wird.

Interessant ist auch der Orchestration Provider Interface (OPI) Ansatz, der - analog zum Cloud Provider Interface (CPI) von BOSH - eine Abstraktionsschicht hinzufügt. Während BOSH-CPIs von Infrastruktur-APIs abstrahieren, stellt das OPI eine Abstraktion zur Verfügung, durch die mehrere Container-Orchestrierer angesprochen werden können. Damit wäre EIRINI, entsprechende Adapter vorausgesetzt, in der Lage, auch mit Diego oder „Docker-Swarm“ zu sprechen.

Knative

Es soll nicht unerwähnt bleiben, dass sich das Kubernetes-Ökosystem auch ausgehend von einer anderen Seite an den Betrieb von Web-Anwendungen herantastet. So nähert sich das Projekt Knative aus der Serverless-Ecke. Der Serverless-Ansatz verfolgt hier die Idee extrem leichtgewichtiger Anwendungen, die oft sogar nur aus einzelnen Funktionen bestehen.

Gerade für „Glue“-Code in ereignisgesteuerten Architekturen eignet sich der Serverless-Ansatz recht gut. Möchte man beispielsweise eine Video-Konvertierung anstoßen, wenn ein neues Video hochgeladen wird, genügt es, ein mit dem erfolgreichen Hochladen ausgelöstes Ereignis mit der darauffolgend auszuführenden Funktion zu versehen. Die Funktion kann leicht ausgebracht und in Betrieb genommen werden.

Knative ist eine Erweiterung, die auf einer Kubernetes-Installation aufsetzt und diese um die Funktionalitäten „Build”, „Serving” und „Eventing” erweitert. Dies bedeutet, dass Knative dem Anwendungsentwickler Werkzeuge zur Verfügung stellt, um von Quellcode leichter zu laufenden Containern zu gelangen.

Die Events

Im Vergleich zu Cloud Foundry handelt es sich also um eine zum Buildpacks-Konzept alternative Herangehensweise. Über dieses Konzept hinausgehend stellt Knative aber auch eine Eventing-Funktionalität zur Verfügung. Wie bereits angedeutet, geht es dabei um die Verarbeitung von Ereignissen. Hierfür werden entsprechende Event Broker, Subscriber und Trigger-Mechanismen benötigt, die eine möglichst lose Kopplung zwischen Ereignisquelle und verarbeitenden Senken herstellen.

Vereinfacht ausgedrückt ist Cloud Foundry dafür gedacht, langlaufende, zustandslose Web-Anwendungen auszuführen. Eine Skalierung auf 0 Instanzen ist für eine Anwendung nicht vorgesehen.

Knative hingegen begrüßt es, Anwendungen mit 0 laufenden Instanzen in eine Art Schlummermodus zu versetzen, da dies wertvolle Cluster-Ressourcen spart. Im Hinblick auf die Cloud-Computing-Kategorie Function as a Service (FaaS) zahlt es sich umso mehr aus, Container zu stoppen, die nur gelegentlich angefragt werden. Wermutstropfen bei Knative sind die noch sehr langen Container-Startzeiten von teilweise mehreren Sekunden. Dies mag sich bei wiederholten Aufrufen durch Caching relativieren, ist aber im Falle eines Kaltstarts eine eher inakzeptable Verzögerung.

KF

Eine weitere Zwiebelschale ergibt sich durch die Verwendung von KF [7], einem Aufsatz auf Knative aus dem Hause Google. Man könnte meinen, es genüge Google nicht, die Container-Orchestrierung zu dominieren, sondern Google wolle jetzt auch nach der letzten Meile zum Anwendungsentwickler greifen.

Die Idee, Knative um eine kf push-Schnittstelle zu erweitern, die den cf push Workflow von Cloud Foundry nachahmt, legt diese Vermutung nahe. Das Ziel ist die Kompatibilität mit der Cloud Foundry API auf der Basis einer ganz eigenen Implementierung. In dieser Hinsicht grenzt sich KF auch von EIRINI ab, denn dort werden noch einige Cloud Foundry Komponenten verwendet.