© KUCO/Shutterstock.com
Kubernetes und Cloud Foundry

Friends or Foes?


Die beiden Open-Source-Lösungen Kubernetes und Cloud Foundry haben sich als gängige Cloudplattformen 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 [1] zur Folge nutzten bereits 2017 51 Prozent der Unternehmen eine private Cloud, wohingegen nur 31 Prozent der Unternehmen eine Pub­lic 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?

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.

frembs_heiss_kubernetes_1.tif_fmt1.jpgAbb. 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 ...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang