Battle of the Cloud Platforms

Kubernetes und Cloud Foundry: Freunde oder Feinde?

Michael Frembs, Michael Heiß

© Shutterstock / KUCO

Die beiden Open-Source-Lösungen Kubernetes und Cloud Foundry haben sich als gängige Cloud-Plattformen durchgesetzt. Oftmals werden diese beiden miteinander verglichen, um eine Entscheidung für einen der beiden Ansätze zu treffen. In diesem Artikel werden die jeweiligen Stärken und Einsatzszenarien der beiden Plattformen beschrieben und es wird aufgezeigt, dass es kein „Entweder-oder“ sein muss.

Immer mehr Unternehmen verwenden nicht nur Clouddienste (Software as a Service), sondern modernisieren ihre eigenen IT- und Bestandsapplikationen (Container as a Service bzw. Platform as a Service). Das ist kaum verwunderlich, bringt doch die Cloud viele Vorteile mit sich. Die Anwendungen laufen in einer Cloud stabiler (Self Healing), skalieren besser (automatisierte horizontale Skalierung) und bringen durch den neuen Dev(Sec)Ops-Gedanken eine schnellere Time-to-Market mit sich. Durch Open-Source-de-facto-Standards wie Docker, Kubernetes oder Cloud Foundry sind die Anwendungen auch portierbar. Das ist besonders bei Hybrid- bzw. Multi-Cloud-Infrastrukturen wichtig. Dafür werden Cloud-native Apps nach der 12-Factor-Methode entwickelt. Die Bandbreite an Architekturansätzen (Monolith, Microservices, 12-Factor-Apps) sorgt für eine Vielzahl an Anforderungen an eine Cloudplattform.

Einer Bitkom-Umfrage zur Folge nutzten bereits 2017 51 Prozent der Unternehmen eine private Cloud, wohingegen nur 31 Prozent der Unternehmen eine Public Cloud verwenden. Nach der Verabschiedung der DSGVO war das zu erwarten.

Grund genug, Kubernetes und Cloud Foundry einander gegenüberzustellen und zu vergleichen. Wie geht es mit den beiden in der Zukunft weiter? Dieser Artikel legt den Fokus auf eine Private Cloud, die im eigenen Rechenzentrum betrieben wird. Müssen sich Unternehmen zwischen diesen beiden entscheiden, oder ist es empfehlenswert beide einzusetzen? Wie könnte ein Zusammenspiel von beiden Lösungen aussehen?

DevOpsCon Istio Cheat Sheet

Free: BRAND NEW DevOps Istio Cheat Sheet

Ever felt like service mesh chaos is taking over? As a follow-up to our previous cheat sheet featuring the most important commands and functions, DevOpsCon speaker Michael Hofmann has put together the 8 best practices you should keep in mind when using Istio.

Kubernetes

In Kubernetes gibt es eine Vielzahl an Konfigurationsoptionen (über Kubernetes-Ressourcen). Die OpenAPI-Spezifikation der aktuellen IBM Cloud Private Kubernetes Installation (ICP v3.1.2, K8s v1.12.4) ist über 75 000 Zeilen lang. Um dieses Universum beherrschen zu können, ist ein hoher Einarbeitungsaufwand notwendig. Dafür wird der Anwender mit einer Plattform belohnt, die auf die eigenen Bedürfnisse feingranular abgestimmt werden kann.

Kubernetes bietet komplexe Clustertopologien. Worker Nodes (auf diesen werden die Container deployt) können auf unterschiedlichen VMs mit unterschiedlicher Hardware, Software und Dimensionierung laufen. Es ist zum Beispiel möglich, neben Linux Worker Nodes auch Windows Worker Nodes oder unterschiedliche Architekturen (z. B. x86_64 und power64le oder auch System z) innerhalb eines Kubernetes-Clusters zu verwenden. Beim Deployment kann darauf Einfluss genommen werden, welcher Pod auf welchen Worker Nodes laufen soll. Auch bei den Deployment-Strategien (Rolling Update, Canary, Blue-Green, …) bietet Kubernetes mit Hilfe von Service Meshes wie Istio oder Linkerd eine Vielzahl an Möglichkeiten an.

Kubernetes besteht aus einem Master Node (unter anderem API-Server), Proxy Nodes und Worker Nodes. Für eine minimale Installation mit wenigen Worker Nodes werden circa sechs VMs benötigt, für eine HA-Installation circa neun. Dabei bleibt es dem Betreiber überlassen, ob die Nodes innerhalb einer VM oder auf Bare Metal installiert werden. Die Betriebssysteme der Nodes müssen aktiv auf dem neuesten Stand gehalten werden. Dafür kann der Betrieb die bisher genutzten Managementtools auch bei den Kubernetes-VMs anwenden. Es ist empfehlenswert, das Anlegen der VMs zu automatisieren. Hierbei kann unter anderem Terraform helfen.

Das Deployment in Kubernetes ist vergleichsweise komplex. Für eine einfache Anwendung werden mindestens vier Konfigurationen (Pod, Deployment, Service und ReplicaSet) benötigt. Die in Abbildung 1 grün gekennzeichneten Pods starten (Docker-)Images. Der Entwickler muss also bei seinem Build-Prozess beachten, dass das Docker Image erstellt wird, und sich auch mit dem komplexeren Deployment-Prozess und den benötigten Kubernetes-Ressourcen auseinandersetzen. Dafür kümmert sich Kubernetes automatisch darum, dass die Instanzen – wenn möglich – auf mehrere Worker Nodes verteilt werden. Während das Deployment über das ReplicaSet unter anderem die Anzahl der Instanzen definiert, bestimmt der Service die Sichtbarkeit der Anwendung.

Abb. 1: Deployment in Kubernetes

Abb. 1: Deployment in Kubernetes

Kubernetes bietet den Organisationen zum Unterteilen der Projekte Namespaces an. Die meisten Kubernetes-Ressourcen sind Namespaces zugeordnet. Über Role-based Access Control (RBAC) können feingranular Rechte auf Namespace-Ebene oder auch clusterweit vergeben werden. Eine weitere Gruppierungsmöglichkeit sind Label, über die gefiltert werden kann. Ein Service beinhaltet beispielsweise alle Deployments mit einem bestimmten Label. So können auch mehrere Deployments hinter einem Service verwaltet werden, wenn beispielsweise eine neue Version ausgerollt werden soll. Auch der clusterinterne Zugriff auf Pods kann über Labels konfiguriert werden.

Durch die Vielzahl an Konfigurationsoptionen ist es auch möglich, komplexere, zustandsbehaftete Anwendungen zu installieren. Dabei behilflich sind Operators, die den Zustand der Pods beobachten und – sobald notwendig – regulierend eingreifen. Neben dem Operator helfen auch StatefulSets (das Gegenstück zum Deployment), zustandsbehaftete Anwendungen zu betreiben. Eine weitere Besonderheit sind die DaemonSets, bei denen Hintergrundprozesse auf jeden einzelnen Node einmal deployt werden. Kubernetes bietet also zahlreiche weitere Möglichkeiten, Anwendungen zu installieren. Eine Limitierung auf 12-Factor-Apps besteht nicht. In Kombination mit Helm Charts – einer Möglichkeit, alle notwendigen Kubernetes-Ressourcen einer Software in ein konfigurierbares „Paket“ auszuliefern – macht das Kubernetes zur kommenden Betriebsplattform, auf der auch Fremdanwendungen installiert werden können. Kubernetes ist der De-facto-Standard für den Containerbetrieb.

Dieser Abschnitt bietet natürlich nur einen kleinen Einblick in Kubernetes. Dennoch zeigt er auf, welche Möglichkeiten Kubernetes bietet und wie es so konfiguriert werden kann, dass es für das eigene Rechenzentrum und die eigenen Organisationsstrukturen passend ist.

Cloud Foundry

Cloud Foundry verfolgt einen anderen Ansatz. Onsi Fakhouri (Senior Vice President, R&D for Cloud bei Pivotal) sagte auf dem Cloud Foundry Summit 2015: „Here is my code. Run it on the cloud for me. I do not care how“. Cloud Foundry zielt auf die Developer Experience ab. Der Entwickler soll sich auf das Entwickeln konzentrieren und von der Middleware/Infrastruktur verschont bleiben. Es wird so viel wie möglich in einer Blackbox versteckt bzw. in der Plattform automatisiert. Das bringt eine schnelle Time-to-Market mit sich, da die Entwickler nicht viel Neues lernen müssen. Bei einem Cloud-Foundry-Workshop bestätigten das vor nicht allzu langer Zeit die Teilnehmer, indem sie nicht mehr mit Cloud Foundry üben, sondern lieber über Transformation und DevOps-Kultur sprechen wollten. Grund: Eine kurze Demo der übersichtlichen Menge an Befehlen war für das Verständnis bereits ausreichend.
Bei einem Deployment muss der Entwickler kein Docker Image erstellen. Über Buildpacks werden aus den Anwendungen automatisch sogenannte Droplets erstellt. Der Entwickler bekommt von diesem intern im System versteckten Vorgang nichts mit. Falls es ein für die Applikation passendes Buildpack in der Umgebung gibt, reicht ein einfaches cf push, und die Anwendung ist in Cloud Foundry deployt. Gibt es kein Buildpack, kann man entweder selbst eines entwickeln oder ebenfalls auf Docker-Container zurückgreifen.

Auch bezüglich organisatorischer Zuordnung von Applikationen auf Organisationen und DevOps-Teams bietet CF ein intuitives Konzept. Eine Organisation besteht aus Spaces. In Spaces werden Anwendungen deployt und mit (Infrastruktur-)Services verbunden. DevOps-Teams können passende Rechte für die Administration der Organisation/Spaces/Quotas und Deployments zugewiesen werden.

Ein ähnlich intuitives und automatisiertes Erlebnis möchte Cloud Foundry auch für den Betrieb ermöglichen. Dafür gibt es BOSH. BOSH sorgt dafür, dass die Mehrzahl der circa 30 VMs installiert und ausgeführt wird. Läuft eine VM nicht mehr wie erwartet, wird sie neu gestartet oder ersetzt. Das erleichtert auf der einen Seite die Arbeit für den Betrieb, erschwert ihn andererseits aber auch, da das Monitoring so nicht einfacher wird. Es gibt aber auch Herausforderungen für den Betrieb. Beispielsweise können Betriebssystemupdates nicht ohne eine neue Cloud-Foundry-Version eingespielt werden. Außerdem kann beispielsweise BOSH Probleme mit volllaufenden Festplatten nicht eigenständig lösen. Der Blackboxansatz bietet hier wie so häufig nicht nur Vorteile, sondern bringt auch neue Herausforderungen mit sich.

Cloud Foundry eignet sich gut, solange man sich an die Konventionen hält. Die Apps müssen Cloud-native (zum Beispiel nach dem 12-Factor-Ansatz) entwickelt worden sein. Ist ein Eingriff in die VMs erforderlich, muss man sich in BOSH einarbeiten. Spätestens hier gibt es einen größeren Einarbeitungsaufwand.

Zwischenfazit

Sowohl Kubernetes als auch Cloud Foundry haben ihre Stärken. Während Kubernetes als Betriebsplattform glänzen kann, begeistert Cloud Foundry die Entwickler mit der einfachen Bedienbarkeit. Möchte man neue, Cloud-native Anwendungen mit möglichst wenig Plattformwissen in die Cloud bringen, hat Cloud Foundry sicherlich seine Stärken. Möchte man bestehende, zustandsbehaftete Anwendungen als Erstes in die Cloud bringen und anschließend Cloud-native modernisieren, führt kein Weg an Kubernetes vorbei. Grundsätzlich ist es also auch eine Frage der Zielsetzung und wie stark die bereits eingeschliffenen Prozesse geändert werden können bzw. inwieweit die Rahmenbedingungen dies zulassen. In Tabelle 1 werden beide Plattformen miteinander verglichen.

Kubernetes Cloud Foundry
Fokus Betriebsplattform Developer Experience
Anwendungen alle Cloud-native Apps
Deployment-Artefakt (Docker-)Image Anwendung (z. B. Jar)
Betrieb VMs oder Bare Metal Von BOSH verwaltete VMs. Virtualisierung notwendig
Ressourcenverbrauch Geringerer RAM-Verbrauch als CF

ca. 10 VMs (minimal) (HA)

Geringerer CPU-Verbrauch als K8s

ca. 30 VMs (minimal) (HA)

Tabelle 1: Vergleich Kubernetes und Cloud Foundry

Was ist mit zustandsbehaftet/zustandslos gemeint?

Bei zustandslosen (stateless) Anwendungen wird der Zustand in einem Backing-Service (Datenbank, Volumes, …) hinterlegt. Die Anwendung selbst hält den Zustand nicht. In der Folge teilen sich alle Anwendungsinstanzen denselben Zustand und sind austauschbar. Für den Client ist es also egal, welche Instanz seine Anfrage ausführt, da der Zustand aller Instanzen derselbe ist. Somit können leicht neue Instanzen hinzugefügt oder (bei sinkender Last) weggenommen werden.

Abb. 2: Beispiel für eine zustandslose (stateless) Anwendung

Abb. 2: Beispiel für eine zustandslose (stateless) Anwendung

Zustandsbehaftete (stateful) Anwendungen besitzen hingegen einen eigenen, separaten Zustand pro Instanz. Als Beispiel können hier Datenbanken angeführt werden, die über mehrere Instanzen repliziert werden und somit ausfallsicher sind. Dabei ist es gewollt, dass jede Instanz eine Kopie des Zustands hat. Diese Art von Anwendungen unterstützt nur Kubernetes, nicht aber Cloud Foundry. Außerdem garantiert Kubernetes über StatefulSets noch eine Startreihenfolge und ermöglicht es, einzelne Instanzen gezielt anzusprechen.

Abb. 3: Beispiel für eine zustandsbehaftete (stateful) Anwendung

Abb. 3: Beispiel für eine zustandsbehaftete (stateful) Anwendung

Open Service Broker

Durch die DevOps-Prozesse und -Kultur wird es den Softwareentwicklern ermöglicht, schnell und häufig neue Versionen zu veröffentlichen. Das trifft bei einer CI/CD Pipeline vor allem auf das Paketieren der Anwendungen, die Konfiguration und das Deployment zu. Nicht inbegriffen sind oftmals Infrastrukturdienste, wie beispielsweise Datenbanken. In vielen Unternehmen gibt es dieselbe Ausgangslage: Es gibt eine große Datenbank auf dem Host, die von allen Anwendungen verwendet wird. Ein Datenbank-Admin-Team kümmert sich um den Betrieb. Änderungen werden an die DBAs geschickt, die diese dann einspielen. Dieser Vorgang kann je nach Organisation und Verfügbarkeit Wochen dauern. Das ist ein Bottleneck, an dem angesetzt werden kann.

Cloud Foundry hat den Service Broker eingeführt. Die Anwendung kann nach dem Self-Service-Ansatz aus einem Markplatz wählen, welchen Service sie benötigt. Zur Erinnerung: Die Entwicklungsgeschwindigkeit in Cloud-Umgebungen entsteht vor allem aufgrund der „as a Service“-Ansätze und der damit möglichen Automatisierung.

Service Broker können relativ leicht selbst in Form eines einfachen REST-API erstellt werden. Für den Großteil der üblichen Subsysteme gibt es bereits fertige Open Source Service Broker. Beispiele für Services gehen von Persistenzdiensten (Datenbanken, Messaging, Volumes) über Konfigurationsdienste (Anwendungseinstellungen, Secret-Management, Zertifikate) bis hin zu anderen Aktionen, die automatisiert werden können (OCR-Dienste, Virenprüfung etc.). Allerdings ist dabei zu beachten, dass die Services gegebenenfalls ebenfalls mit Back-ups, Hochverfügbarkeit, Support und Monitoring ausgestattet werden, vor allem bei Daten, die über mehrere Jahrzehnte aufbewahrt werden müssen.

Ein Service wird über einen einfachen Befehl erstellt. Notwendige Informationen, wie zum Beispiel URL, Nutzername und Passwort bei einer Datenbank, werden der Anwendung über ein Binding mitgeteilt. Dadurch wird der As-a-Service-Gedanke gelebt. Die Kultur, Dinge zur Automatisierung anzubieten, wird vorangetrieben. Formulare, Anträge und lange Wartezeiten (bis die Anforderungen umgesetzt werden) gehören der Vergangenheit an.

Das Konzept hat sich in Cloud Foundry durchgesetzt. Open Service Broker wird mittlerweile als Spezifikation innerhalb der Cloud Native Computing Foundation gepflegt. Daher ist es auch nicht verwunderlich, dass diese Spezifikation ebenfalls in die Kubernetes-Welt eingezogen ist. Jetzt können die Stärken von beiden Plattformen ausgespielt werden. In Kubernetes können zustandsbehaftete Services zur Verfügung gestellt werden, die anschließend im Cloud-Foundry-Marktplatz angeboten werden. Cloud Foundry Apps können über den Service Broker Services in Kubernetes provisionieren und verwenden. In Abbildung 4 erstellt eine Cloud-Foundry-Applikation über den Service Broker eine PostgreSQL-Datenbank auf Kubernetes und erhält anschließend über das Binding die notwendigen Informationen, um auf diese zuzugreifen.

Abb. 4: Beispiel Zusammenspiel Cloud Foundry mit Kubernetes über einen Open Service Broker

Abb. 4: Beispiel Zusammenspiel Cloud Foundry mit Kubernetes über einen Open Service Broker

Eirini und Quarks

Neben dem Open Service Broker gibt es zwei weitere Projekte, die zeigen, dass Kubernetes und Cloud Foundry gut harmonieren. Durch das Projekt Eirini kann der Cloud Foundry Orchestrator Diego/Garden durch Kubernetes ausgetauscht werden. Das wird durch das Orchestrator Provider Interface (OPI) möglich gemacht. Es wird eine Abstraktionsschicht vor die Diego Engine gestellt, sodass der Orchestrator beliebig ausgetauscht werden kann. Der Entwickler deployt weiterhin die Anwendungen über Cloud Foundry. Die Anwendung wird aber nicht in einem Cloud Foundry Droplet betrieben, sondern als Docker-Container in Kubernetes. Das erleichtert das Monitoring, da dies einheitlich in Kubernetes betrieben werden kann. Außerdem können so Lösungen, die es bisher nur für Kubernetes gibt, auch für Cloud-Foundry-Anwendungen verwendet werden. Das Service Mesh Istio ist beispielsweise in Cloud Foundry zum Entstehungszeitpunkt dieses Artikels noch nicht reif für den Produktivbetrieb.

Das Projekt Quarks (früher CF Containerization) ermöglicht es, Cloud Foundry komplett in Kubernetes zu betreiben. Aus den BOSH-Releases werden Docker Images erstellt, die über Helm Charts installiert werden können. Kubernetes kümmert sich anschließend um die Skalierung. Das spart auch Speicher, da die VMs durch Container ersetzt werden. Quarks funktioniert über Operator, die den Zustand überwachen. Die Anwendungen selbst werden allerdings weiterhin als Cloud Foundry Droplets deployt. Cloud Foundry bleibt bestehen wie es ist, nur eben nicht mehr auf Basis von VMs, sondern in Kubernetes-betriebenen Containern.

Während Eirini also die Applikationen in Kubernetes ausführt, ermöglicht Quarks, Cloud Foundry auf Kubernetes zu betreiben. Werden beide Projekte kombiniert, bleibt die Developer Experience von Cloud Foundry erhalten, und der Betrieb kann dieselben Tools beispielsweise für Monitoring verwenden und muss sich nicht in BOSH einarbeiten. Beide Projekte sind Cloud-Foundry-Incubator-Projekte. Beide Projekte befinden sich kurz vor der Finalisierung. Das Ziel, das Beste aus beiden Welten zu ermöglichen und diese zu kombinieren, ist aber klar erkenntlich.

Fazit

Was ergibt nun der Vergleich von Kubernetes und Cloud Foundry? Es wurde herausgearbeitet, dass Kubernetes als Betriebsplattform überzeugen kann. Für die Zukunft kann davon ausgegangen werden, dass Third-Party-Software zunehmend als Helm Chart für den Kubernetes-Betrieb bereitgestellt wird, da sich Kubernetes zum De-facto-Standard hierfür entwickelt hat. Das liegt vor allem an der Möglichkeit, zustandsbehaftete Anwendungen auf Kubernetes zu deployen, und der Option, Kubernetes nach den eigenen Vorstellungen und Anforderungen zu konfigurieren. Des Weiteren ist es für Softwarehersteller einfacher möglich, Kubernetes zu erweitern, was unter anderem die Operatoren zeigen.

Cloud Foundry hingegen hat den Fokus auf die Developer Experience und DevOps-Transformationen gelegt. Cloud Foundry ermöglicht, dass sich DevOps-Teams vorrangig mit Entwicklungstätigkeiten beschäftigen und betriebsnahe Themen wie Deployments und die Verknüpfung mit umgebungsspezifischen Services möglichst ohne lange Lernkurve vonstattengehen können. Beide Ansätze bringen Lernkurven (Dev, DevOps, Plattformbetrieb) mit sich, die sich aber bezüglich der Komplexität unterscheiden. Nicht zu unterschätzen sind auch die Unternehmensprozesse und -strukturen, die durch Cloud Computing, schnellere Releasezyklen und neue Zuständigkeiten überdacht werden müssen, um das Potenzial der neuen Technologien ausschöpfen zu können.

Es wurde gezeigt, dass der Open Service Broker sozusagen als Kleber zwischen beiden Plattformen fungieren kann. Das Zusammenspiel von Kubernetes und Cloud Foundry wird hier sehr deutlich, indem in Cloud Foundry installierte Cloud-native Apps auf Backing Services zugreifen können, die in Kubernetes deployt sind. Das geschieht ganz im DevOps- und Automatisierungsgedanken. So wie Service Broker den DevOps-Teams Erleichterung verschaffen, bringen die Projekte Eirini und Quarks dem Betrieb Vorteile. Mit beiden Projekten wird anschaulich demonstriert, dass beide Plattformen gut mit- bzw. sogar aufeinander betrieben werden können. Beide Projekte erlangen demnächst Produktionsreife. Es kristallisiert sich heraus, dass die Wahl der richtigen Cloud-Plattform kein Entweder-oder mehr sein muss und bedarfsgerecht gewählt werden kann. Wir haben bereits mit beiden Plattformen Erfahrungen gesammelt und sind uns sicher: „Kubernetes and Cloud Foundry are friends, not foes!“

Geschrieben von
Michael Frembs
Michael Frembs
Michael Frembs ist Teil des Softwarearchitektenteams und Senior Consultant bei der ARS Computer und Consulting GmbH. Seit mehreren Monaten liegt sein Fokus auf Cloud-native-Entwicklung, Kubernetes und Cloud-Services.
Michael Heiß
Michael Heiß
Michael Heiß ist als Senior Consultant für moderne Softwarearchitekturen (Cloud, Microservices, API) bei der ARS Computer und Consulting GmbH für die Beratung von Kunden zuständig, die sich auf die Reise in das neue Technologiezeitalter begeben. Neben seinen technologischen Steckenpferden (Cloud-native-Plattformen, Microservices, APIs, Java EE/Spring) hat er einen sehr starken Fokus auf die Bewertung organisatorischer Auswirkungen durch Technologieentscheidungen.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
4000
  Subscribe  
Benachrichtige mich zu: