OpenStack als Helm-Paket für Kubernetes
Schichtarbeit
OpenStack ist komplex. Wer sich das Setup der Software möglichst einfach machen möchte, verpackt seine OpenStack-Dienste in Docker-Container. OpenStack-Helm stellt dafür Helm-Pakete zur Verfügung.
OpenStack hat sich in den vergangenen Jahren zur naheliegenden Option für alle gemausert, die private oder öffentliche Cloud-Dienste erbringen möchten. Denn kaum ein anderes Softwareprojekt am Markt bietet einen vergleichbaren Funktionsumfang oder eine vergleichbar große Community, die sich um die Pflege des Produkts kümmert. Was Segen ist, ist bei OpenStack aber Fluch zugleich: OpenStack ist ein komplexes Gebilde, das aus über dreißig Einzelkomponenten besteht. Damit die Plattform funktioniert, muss der Administrator zumindest die sechs Kernkomponenten Nova, Neutron, Swift, Glance, Keystone und Cinder unter einen Hut bringen. Hinzu gesellen sich Zusatzdienste, die zwar nicht unmittelbar zu OpenStack gehören, aber doch notwendig für eine OpenStack-Cloud sind – allen voran RabbitMQ und als Datenbank für Metadaten MariaDB.
Seit den ersten OpenStack-Versionen beschäftigen sich Entwickler und Administratoren mit der Frage, wie sich OpenStack möglichst effizient in großen Setups ausrollen lässt. Denn genau dafür ist OpenStack ja eigentlich gemacht: Clouds, die bei Bedarf beliebig in die Breite skalieren und eher an physische Grenzen stoßen als an Softwaregrenzen, weil etwa der im Rechenzentrum verfügbare Platz zur Neige geht. Und klar ist: Wer ein Setup mit Hunderten oder Tausenden Knoten betreibt, kommt mit einer manuellen Wartung nicht weiter. Automation ist hier zwingende Grundvoraussetzung. Und darüber, wie sich das OpenStack-Deployment sinnvoll automatisieren lässt, streiten bis heute die Gelehrten.
Klassische Automatisierer?
Logischerweise als Erste stiegen die klassischen Automatisierer in den Ring, allen voran Puppet, später gefolgt von Ansible. Auch für Chef und Salt existieren OpenStack-Module, die am Ende zur fertigen Cloud verhelfen. Jedoch ist die Community mit keinem der verfügbaren Automatisierer langfristig ganz glücklich geworden. Denn OpenStack ist komplex und verschiedene Befehle sind auf diversen Servern parallel auszuführen. Dafür eignet sich Puppet nicht gut. Außerdem sind die Puppet-Module und die Playbooks für Ansible für einzelne Komponenten riesig und schwierig zu pflegen. Eine andere Idee verfolgt deshalb das OpenStack-Subprojekt Kolla: Es stellt die zu OpenStack gehörenden Dienste als Docker-Container bereit [1]. Statt die OpenStack-Komponenten direkt auf den Zielsystemen auszurollen, startet der Administrator die einzelnen OpenStack-Komponenten mit Ansible als Container. Damit bleibt als einzige Voraussetzung, die ein System erfüllen muss, ein funktionierendes Docker. Und auch im operativen Alltag hat dieser Ansatz seinen Nutzen: OpenStack-Updates lassen sich viel einfacher durchführen, weil die Komponenten kontrolliert und nacheinander aktualisierbar sind. Geht das Update einer Komponente schief, so zieht das nicht gleich den gesamten Knoten und andere darauf laufende Dienste in den Abgrund. Im schlimmsten Falle löscht der Administrator den Container und rollt den jeweiligen Dienst samt Datenbank-Backup neu aus.
Einen elementaren Nachteil hat der Kolla-Ansatz allerdings, denn dem Administrator kommt weiterhin die Aufgabe zu, die Container zu betreiben und auf seine physischen Knoten sinnvoll zu verteilen. Im Kolla-Beispiel stehen ihm für diese Aufgabe jedoch nur klassische Werkzeuge zur Verfügung, denn die Vorteile eines Flottenmanagers für Container fehlen. Eine passende Lösung ist allerdings längst erfunden und verfügbar – Kubernetes mischt seit Jahren die Containerwelt ordentlich auf. Dass die Kombination aus Kolla und Kubernetes eine gute Idee wäre, ist auch den Kubernetes-Entwicklern längst aufgefallen – ein entsprechendes Unterprojekt von Kolla namens Kolla-Kubernetes machte sich im vergangenen Jahr an die Arbeit. Zwischenzeitlich ist Kolla-Kubernetes allerdings verwaist – nicht weil man die Idee nicht mehr gut findet, sondern weil man sich lieber auf OpenStack-Helm konzentriert, das dasselbe Ziel hat.
Native Kubernetes-Technik
Wer mit dem Begriff Helm nichts anfangen kann: Helm ist der Name des Paketmanagers für Kubernetes. Denn die Idee, dass man bestimmte Applikationen als Container viel sinnvoller unter das Volk bringen kann als mit den klassischen Werkzeugen RPM oder dpkg ist keinesfalls neu. Auch die großen Distributoren sind bereits auf diesen Trichter gekommen, bei Canonical ist es Snap. Helm geht das Thema von der anderen Seite an und benötigt lediglich ein lauffähiges Kubernetes, um Container zentral gesteuert auszurollen.