© Andriy Popov, 123RF

Diverse Lösungen treten an, um Admins perfektes Container-Management zu liefern. Das Linux-Magazin fühlt Kubernetes, Docker Swarm, Mesos und Diego auf den Zahn.

Der Trend in der IT- und der Transportbranche war derselbe: Container, Container und noch mehr Container. Anfangs standen grundlegende Containertechniken wie Docker und LXC im Mittelpunkt, inzwischen aber rückt die Containerverwaltung an diese Stelle. Die Technik des Containers selbst gilt als ausgereift. Docker oder LXC bieten alle Funktionen, die Admins sich im Alltag wünschen.

Das aber reicht nicht mehr aus. Zusätzlich ist heute eine zentrale Intelligenz notwendig, die die unzähligen physischen Knoten einer Plattform verwaltet und den anfallenden Workload sinnvoll auf sie verteilt. Gefragt ist ein Setup aus vielen Containern, die automatisch über diverse Hosts hinweg so verteilt werden, dass sie die verfügbaren Ressourcen bestmöglich nutzen.

Im Zuge dieser Diskussion begegnen dem Admin immer wieder die gleichen Anwendungen: Kubernetes, Docker Swarm, Cloud Foundry Diego sowie Mesos. Worum geht es bei diesen Lösungen überhaupt? Zwar beschäftigen sich alle vier mit Containern, doch deckungsgleich sind weder ihre Ansprüche noch ihr Funktionsumfang.

Dieser Artikel gibt einen Überblick, er beschreibt ihre Basisfunktionen und geht auch auf die Frage ein, welche Software sich für welche Art von Setup eignet. Zuvor steht jedoch die Frage auf dem Plan, was Container-Management eigentlich auf technischer Ebene leisten muss.

Was Container-Management tun muss

Viele Admins sehen in Containern eine logische Evolutionsstufe klassischer virtueller Maschinen. Die Vorteile liegen scheinbar auf der Hand: Einerseits kommen Container mit einem deutlich geringeren Overhead daher als typische VMs, weil sie kein komplettes Betriebssystem emulieren. Und andererseits sind Container für typische Devops-Workflows deutlich besser geeignet: Echte VMs mit eigenem Betriebssystem brauchen fast zwangsläufig ein Hilfsmittel wie Ansible oder Chef, um aus einem nackten System ein funktionierendes zu machen. Container hingegen lassen sich jederzeit von Grund auf neu bauen und automatisch ausrollen.

Was Container-Umgebungen mit ihren klassischen Kollegen aus dem VM-Lager gemein haben, ist die Komplexität des Setups: Hüben wie drüben sind Anforderungen an die Redundanz ebenso gegeben wie die Notwendigkeit, VMs oder Container in großen Umgebungen auf Zielrechner zu verteilen. De facto stehen Container also vor dem gleichen Problem, vor dem auch VMs stehen – mit dem Unterschied, dass für typische VMs das Problem bereits gelöst ist: Clouds liefern ja als eines ihrer zentralen Versprechen gerade den Teil, der die vorhandene Hardware verwaltet und die gewünschten VMs darauf verteilt.

Und nicht nur das Platzieren von Containern auf physischen Hosts spielt eine große Rolle. Auch die Anbindung von Containern an virtuelle Netze (also an bestehende SDN-Umgebungen) und das Durchreichen von physischem Speicher an die Container sind wichtige Aufgaben der Containerverwaltung. Mit kleinen Abstrichen muss Verwaltung für Container genau das bieten, was Clouds für virtuelle Maschinen leisten.

Genau darum geht es im folgenden Test: Liefern Kubernetes, Docker Swarm, Diego und Mesos alle nötigen Funktionen, um Container in massiv skalierbaren Plattformen zu betreiben?

Größter Aufsteiger: Kubernetes

Den Anfang macht Kubernetes http://1. Die Software hat sich jüngst zu so etwas wie einem Shootingstar in Sachen Container-Management gemausert: Wer hip sein will, baut seine Container-Umgebung auf Kubernetes auf. Das dürfte zum großen Teil auch an der Herkunft der Lösung liegen, denn niemand Geringeres als Google zeichnete für Kubernetes am Anfang von dessen Entwicklung verantwortlich. Mittlerweile hat Google die Software in die Obhut der Cloud Native Computing Foundation übergeben, bleibt selber aber nach wie vor an der Weiterentwicklung der Lösung beteiligt.

In Sachen Architektur folgt Kubernetes in vielerlei Hinsicht dem Design klassischer Clouds: Alle Arbeiten, die Admins in einer Kubernetes-Umgebung durchführen, erledigen sie durch ein zentrales API, das auf dem Kubernetes Master läuft. Neben dem API beheimatet dieser Master auch alle Controllerkomponenten von Kubernetes, etwa den Controller Manager oder den Scheduler. Letzterer ist dafür verantwortlich, die per API-Request vom Admin angeforderten Container auf die Kubernetes-Nodes zu verteilen (Abbildung 1).

Abbildung 1: Kubernetes ist ein Werkzeug zur Container-Orchestrierung, das auf Docker setzt, aber viel eigene Funktionalität zusätzlich anbietet.

Wer sich mit Kubernetes beschäftigt, sieht sich einer Flut neuer Begriffe ausgesetzt: Pods, Labels, Selektoren, Controller oder Services sind nur einige davon. Zentrale Bedeutung kommt dem Pod zu: Darunter versteht ein Kubernetes-Cluster eine Anzahl von Containern, die grundsätzlich auf derselben Hardware laufen und die auf dieselben Ressourcen direkt zugreifen. Legt der Admin in Kubernetes also Container an, fordert er sie nicht direkt an, sondern beauftragt per API das Anlegen eines Pod.

Der Scheduler kümmert sich letztlich darum, dass die Container eines Pod allesamt auf demselben physischen Knoten laufen. Gleichzeitig sorgt sich ein Controller um das Thema Hochverfügbarkeit: Der Admin definiert für den jeweilige Pod, wie hoch die Ausfallsicherheit sein soll. Fällt ein Pod aus, startet ein eigens für diesen Zweck laufender Replication Controller automatisch einen neuen Pod auf einem anderen Host.

Netzwerk und Storage

Wer mit Docker-Containern bereits gearbeitet hat, kennt den dort typischen Workflow für virtuelle Netze: Jeder Container bekommt eine lokale NIC und ist in ein eigenes, privates Subnetz eingebunden. Selbst Container, die auf genau demselben Host laufen, können deshalb nicht direkt miteinander kommunizieren. Wenn das möglich sein soll, kommen stattdessen Port-Forwardings oder Proxys zum Einsatz.

Radikal anders geht Kubernetes das Thema Netzwerk an: Einerseits setzt es nämlich voraus, dass die Container eines Pod dieselbe IP nutzen – weil jeder Dienst eines Pod in einem eigenen Container laufen soll, sind etwaige Port-Kollisionen verschiedener Dienste kein Thema. Deutlich radikaler ist der Kubernetes-Ansatz, dass das gesamte Netzwerk innerhalb einer Kubernetes-Umgebung flach sein soll: Auch verschiedene Pods auf verschiedenen Servern sollen nämlich ohne NAT oder andere Hacks direkt Daten austauschen können.

Das lässt einerseits komplizierte SDN-Lösungen wie Open Vswitch aus dem Spiel, schränkt andererseits aber auch die Flexibilität ein, die eine Kubernetes-Umgebung bietet. Denn weil echtes SDN ab Werk gar nicht vorgesehen ist, lassen sich in einer Kubernetes-Umgebung die Setups verschiedener Kunden nur schwer voneinander trennen.

Wer Container in einer Kubernetes-Umgebung mit Speicher ausstatten möchte, hat dazu zwei Möglichkeiten: Einerseits offeriert das Kubernetes-API die Anbindung verschiedener Storage-Backends, darunter NFS oder Ceph. Alternativ bietet eine Abstraktionsschicht generische Anfragen nach Storage an: Sendet ein Container in einem Pod einen solchen Storage-Request an des Kubernetes-API, sorgt dies im Hintergrund dafür, dass der Container automatisch die angefragte Menge Speicher bekommt. In diesem Fall erfährt der Container aber nicht, woher jener Speicher tatsächlich kommt oder auf welcher Technik er basiert.

Im Alltag

Das Kubernetes-Konzept funktioniert im Alltag sehr gut. Auch das schmückende Beiwerk ist – Google-typisch – auf der Höhe der Zeit: Neben der bereits erwähnten impliziten HA-Fähigkeit liegt Kubernetes ab Werk auch ein eigener DNS-Server bei, der Teil von »etcd« ist und das Announcement verschiedener Dienste in Pods Cluster-weit ermöglicht. So erschlägt Kubernetes das Thema Service-Discovery: Ein Dienst in einem Pod für einen Webserver kann sich zum Beispiel darauf verlassen, dass er unter einer eigens für diesen Zweck definierten IP-Adresse stets eine MySQL-Datenbank erreicht.

Weitere schlaue Ansätze finden sich auf der Kubernetes-Dienstebene: Nahtloses Zentrallogging via Logstash beziehungsweise ELK sowie Monitoring, Alerting und Trending über Lösungen wie Heapster oder Grafana lassen sich über vorhandene APIs problemlos anbinden.

Zu einer runden Sache macht Kubernetes schließlich, dass die Hürden bis zum ersten lauffähigen Kubernetes-Cluster niedrig sind: In wenigen Minuten lässt sich eine funktionierende Kubernetes-Umgebung in virtuellen Maschinen aus dem Boden stampfen.

Das gibt zwar nicht adäquat die Lern-Aufwand wieder, der nötig ist, um Kubernetes tatsächlich zu durchdringen. Es hebt sich aber sehr wohltuend von typischen Cloudumgebungen wie Open Stack ab, wo der gleiche Vorgang etliche Stunden in Anspruch nimmt und fundamentales Verständnis der Technik voraussetzt. Wer sich erstmals mit Container-Orchestrierung näher beschäftigt, schafft mit Kubernetes dagegen einen schnellen und unkomplizierten Einstieg.

Docker Swarm

Um den zweiten Kandidaten im Test, Docker Swarm http://2, ranken sich viele Mythen. Böse Zungen behaupten, Docker wäre auf die Idee mit Swarm alleine gar nicht gekommen. Vielmehr sei das Produkt eine Antwort auf Kubernetes, um sich nicht von Google die Butter vom Brot nehmen zu lassen. Das ist gar nicht ganz so weit hergeholt: Kubernetes baut im Kern zwar auf Docker-Container, fügt um sie herum aber so viele eigene Komponenten hinzu, dass von den eigentlichen Docker-Containern kaum noch etwas zu merken ist.

Die typischen Kommandozeilenwerkzeuge, mit denen Admins Docker-Container steuern, sind bei Kubernetes praktisch nutzlos. Die bereits beschriebenen Veränderungen bei typischen Docker-Workflows – Stichwort Netzwerk – tun ein Übriges. Da Kubernetes im Gegensatz zu Docker gerade auf der Spitze seines Hype angekommen zu sein scheint, ist die Theorie von Swarm als Mittel gegen Kubernetes durchaus plausibel.

Trotzdem liefert Docker bei Swarm aber auch sehr handfeste Technik. Das Unternehmen selbst beschreibt Swarm als Clustertool für Docker-Container, also als eine Art Docker-Aufsatz. Das bringt Vorteile in der alltäglichen Arbeit gegenüber dem Kubernetes-Ansatz: Auch beim Einsatz von Swarm gelten alle API-Garantien von Docker, und normale Container lassen sich auf der Kommandozeile mit exakt denselben Tools nutzen, die auch ohne Swarm zur Verfügung stehen. Zusätzliche Lösungen wie Compose funktionieren mit Swarm ebenfalls. Swarm klinkt sich jeweils dort ein, wo Cluster-Funktionalität auf mehreren Hosts eines Setups gefragt ist.

Die Architektur von Swarm ist simpel und übersichtlich: Ein Swarm-Agent läuft auf jedem Host der Installation, der potenziell Docker-Container starten und betreiben kann. Cluster-weit gesellt sich der Swarm-Manager hinzu: Er dockt im Hintergrund an einen Konfigurationsdienst an – zur Auswahl stehen Etcd, Consul und Zookeeper – und nutzt diese Informationsquelle, um sich über den Zustand der einzelnen Hosts zu informieren. Aus ihr bezieht er alle Informationen, die er für das Platzieren von Containern auf allen Servern des Setups benötigt.

Der Kontext der Docker-App

Wie Kubernetes hantiert Docker Swarm mit Cloud Native Applications. Dahinter verbirgt sich ein komplexer Standard, der festlegt, wann eine Applikation als für die Cloud geeignet gilt. Bei Kubernetes spielen Pods dabei eine große Rolle, denn Pods und die auf ihnen installierten Applikationen sind zusammen mit Replication-Controllern, Replica-Sets und Diensten die Ursuppe, aus der Applikationen werden. Docker hingegen bringt mit Compose ein eigenes Werkzeug mit, um Cloud Native Applications auf Basis von Docker-Containern zu erstellen. Weil Swarm API-kompatibel mit normalem Docker ist, lassen sich in Compose gebaute Docker-Apps direkt per Swarm auf einen Cluster ausrollen.

Wer von Compose bisher noch nichts gehört hat, stellt sich das Tool am besten wie eine Art Orchestrierungslösung für Docker-Container vor: Eine einzelne Datei – das Compose-File (Abbildung 2) – enthält die exakte Definition der Applikation, also etwa eine Liste der verwendeten Container, und beschreibt auch deren individuelle Eigenschaften. Compose legt im nächsten Schritt alle benötigten Container an. Swarm kümmert sich darum, dass die Container auf viele Hosts verteilt werden.

Abbildung 2: Compose ist eine Docker-Template-Sprache, über die sich Apps aus mehreren Containern definieren lassen. Im Bild: Ein Beispiel für WordPress.

Die Architekturen von Kubernetes und Swarm unterscheiden sich also deutlich, denn Swarm alleine hilft dem Admin nicht – er braucht Compose, um die Grundlagen für Docker-Cluster zu schaffen. Kubernetes hingegen versteht sich als All-in-one-Lösung und bringt alle nötigen Komponenten mit.

Daneben enthält Swarm die Intelligenz, um Containern auf unterschiedlichen Hosts Storage-Volumes unterzujubeln. Swarm kann auch Overlay-Netzwerke definieren, die über mehrere Knoten hinweg Docker-Containern die Kommunikation untereinander erlauben. Unter der Haube setzt Swarm dabei auf die in Docker für diesen Zweck vorgesehen Standardfunktionen. Last but not least gehört die obligatorische Service-Erkennung auch bei Swarm zum Lieferumfang: Per DNS und Load-Balancer-Diensten lässt sich jeder Container in einem Schwarm separat und auf Basis eines festen Hostnamens ansprechen.

Swarm ist das Gegenangebot zu Kubernetes für alle Admins, die gut mit den Docker-Konventionen leben können und den Umgang mit den Standard-Docker-APIs gewöhnt sind. Sie haben bei Swarm weniger zu lernen als bei Kubernetes.

Cloud Foundry Diego

Wer die Ankündigungen von Cloud Foundry zu Diego [3] liest, bekommt vielleicht den Eindruck, dass auch Diego ein allgemeines Framework zur Verwaltung von Containern im Stile von Kubernetes oder Swarm sei. Doch das ist nur ein Teil der Wahrheit. Um zu verstehen, worum es bei Diego geht, ist ein kleiner Ausflug in die Cloud- Foundry-Geschichte hilfreich.

Vor mehreren Jahren etablierte das amerikanische Projekt Cloud Foundry (CF) eine Plattform für PaaS-Anwendungen erfolgreich am Markt. Bei PaaS (Platform as a Service) geht es bekanntlich darum, spezifische Umgebungen, etwa einen LAMP-Stack, so vorzubereiten, dass Kunden sich per Maus eine Umgebung für ihre Website oder ihr Projekt zusammenklicken können, die in kürzester Zeit zur Verfügung steht.

Cloud Foundry ist seither zum Inbegriff des PaaS-Konzepts geworden, das Unternehmen hat es verstanden, seine Marke in eben diese Richtung auszubauen. Das eigentliche Produkt von Cloud Foundry, eben jene PaaS-Umgebung, besteht aus einer Vielzahl unterschiedlicher Dienste.

Seit jeher gehören auch Container dazu: Frühere Versionen von Cloud Foundry brachten Warden mit, ein ursprünglich proprietäres Containerformat, das Cloud Foundry aber vor einigen Jahren für die Allgemeinheit freigegeben hat. In Form von Diego stellte Cloud Foundry vor einigen Wochen den offiziellen Warden-Nachfolger vor, der das Docker-Containerformat beherrscht und Warden in Cloud Foundry ersetzt.

Die Konkurrenz auf dem Kieker

Sein bisheriges Container-Management, das auf der Droplet-Execution-Agents-Architektur basierte, verwirft Cloud Foundry vollständig. Das ist ein großer Schritt, der auch deutlich macht, was der Firma vorschwebt: Offenbar will man sowohl Docker mit Swarm als auch Kubernetes angreifen und im Zirkus der Container-Orchestrierung zur Attraktion werden.

Letztlich ist die Arbeit mit Diego aber nicht so dynamisch wie mit Docker oder Kubernetes. Der Grund dafür ist, dass Diego noch immer zu Cloud Foundry gehört und an verschiedenen Stellen darin tief integriert ist. Beispiel: neue Container. Der übliche Workflow in Cloud Foundry sieht vor, dass ein vom Nutzer angefragter Container nicht als fertiges Docker-Abbild irgendwo liegt, sondern auf Basis der Garden-Distribution [4] direkt aus Cloud Foundry heraus für Docker entsteht. CF folgt an dieser Stelle dem Mantra der immer wieder zu reproduzierenden Container gnadenlos.

Das wirkt sich auch an vielen anderen Stellen auf die Arbeit mit Diego aus: Eine Applikation, die innerhalb einer Cloud-Foundry-Umgebung laufen will, muss sich an die dort geltenden Konventionen in Sachen Netzwerk und Architektur halten. Zumindest aktuell ist die Nutzung von Diego nur im Kontext von Cloud Foundry sinnvoll.

Technisch liefert Diego durchaus fundierte Bausteine: Im Hintergrund werkelt ein Cloudcontroller, der über die Cloud Controller Bridge mit verschiedenen Diensten im Hintergrund kommuniziert. Dazu gehört das Bulletin Board System (BBS) ebenso wie das Diego Brain. Netzwerktraffic regelt Cloud Foundry über einen eigenen Routing-Mechanismus, auch der Dateizugriff lässt sich per eigener Ressource steuern.

Die Server, auf denen letztlich Container in Form von Gardens laufen, heißen in Diego Cells. Streng genommen ist nur die Kombination aus Access-Manager, Datenbank, Brain und den Cells der CF-Teil, der Diego heißt. Die Cloudcontroller etwa gehören zum Cloud-API, im CF-Sprech auch Capi genannt.

Ein großes Plus: Alle CF-Komponenten lassen sich ab Werk redundant betreiben, in Sachen HA ist die Lösung also auf dem Stand der Zeit. Das große Minus: Diego besteht aus diversen Komponenten, deren Funktionalität der Admin im ersten Schritt verstehen muss – sonst kann er mit CF und Diego kaum arbeiten (Abbildung 3). Am Anfang der Diego-Arbeit steht für den Admin also viel Lernaufwand. Offensichtliche Vorteile gegenüber Docker oder Kubernetes ergeben sich vorerst nicht. Noch ist Diego aber auch ganz am Anfang seiner Karriere.

Abbildung 3: Diego ist eng mit Cloud Foundry verbandelt und aktuell nur in diesem Kontext sinnvoll einzusetzen. Wer nur Container-Orchestrierung braucht, ist bei Kubernetes oder Docker besser aufgehoben.

Mesos

Eigentlich hat Mesos [5] in diesem Artikel nur bedingt etwas zu suchen. Denn anders als bei den drei bereits vorgestellten Kandidaten handelt es sich bei Mesos nämlich nicht ausdrücklich um ein Werkzeug für Container-Orchestrierung. Kubernetes, Docker und auch Diego sind jeweils um Container herumgestrickte Werkzeuge, die den Betrieb von Containerflotten auf großen physischen Plattformen erst möglich machen. Mesos hingegen ist ein Clustermanager, der zwar auch riesige Mengen Hosts verwalten kann. Doch geht es dabei nicht bevorzugt um Container.

Salopp formuliert siedelt Mesos eine Ebene höher an als Kubernetes & Co. Die Lösung besteht aus drei Komponenten: Der Mesos-Master ist die zentrale Verwaltungseinheit, also der Dienst, der den Überblick über alle bestehenden Knoten und Aufgaben hat. Im Hintergrund nutzt Mesos das ebenfalls von der Apache Foundation betriebene Zookeeper als State-Datenbank, um sich die Zustände von Hosts und Aufgaben im Cluster zu merken. Auf allen Knoten, die Workloads (Tasks) ausführen, lauscht ein Mesos-Agent auf etwaige Befehle des Mesos-Masters.

Hinzu kommen die Frameworks: Davon kann es in Mesos mehrere gleichzeitig geben; sie bestehen aus einem Scheduler einerseits und aus einer Erweiterung für den jeweiligen Mesos-Agenten, um auf den spezifischen Hosts die gewünschten Aufgaben zu erledigen. Frameworks sind der Punkt, an dem Lösungen wie Kubernetes und Docker Swarm ansetzen. Ohne wenigstens ein aktives Framework ist Mesos allerdings nutzlos. Kubernetes (Abbildung 4) oder Swarm lassen sich also ohne Mesos betreiben, doch Mesos ohne zumindest ein Framework für Container ergibt keinen Sinn.

Abbildung 4: Auf Wunsch lässt sich Kubernetes auch mit Mesos kombinieren; für Docker Swarm gilt dasselbe.

Die große Stärke von Mesos ist seine nachgewiesene Erprobung in großen und sehr großen Setups. Ganze Rechenzentren verwaltet Mesos schon, und Setups mit Hunderttausenden Knoten kann Mesos nachweislich nutzen. Auch Swarm und Kubernetes beanspruchen solche Zahlen für sich, doch sind tatsächliche Implementationen aktuell eher rar.

Marathon als Teil von Mesos

Mesos lässt sich auch mit Marathon ausrollen: Das ist ein aus Mesosphere stammendes Framework für Mesos, das Container verwalten kann – im Grunde also ein direktes Konkurrenzprodukt zu Kubernetes oder Swarm. Ähnlich wie jene bietet Marathon eine Vielzahl von Möglichkeiten, um Container auf die Hosts eines Setups zu verteilen und Abhängigkeiten zwischen den Containern abzubilden, die zu einer logischen Cloudapplikation gehören. Natürlich bietet Marathon auch ein eigenes REST-API.

Interessant ist Mesos also vorrangig für riesige Installationen. Wer eine große Container-Plattform bauen möchte, sollte sich die Scheduling-Fähigkeiten von Mesos in Kombination mit dessen Frameworks genauer anschauen. Wer hingegen ein kleines Setup im Sinn hat, ist mit Kubernetes oder Swarm besser bedient. Denn klar ist: Mesos ist äußerst komplex und erfordert viel Lernaufwand.

Fazit

Kubernetes und Swarm eignen sich besonders für Nutzer, die Container in ihrem Setup unkompliziert orchestrieren wollen. Es ist eine Frage der persönlichen Präferenz, ob man sich für den Kubernetes-Ansatz oder für die deutlich näher an Docker angelehnte Swarm-Methode entscheidet. Praktisch funktionieren beide Lösungen ähnlich gut. Wer aus der Cloud-Foundry-Ecke kommt, ist mit Diego auf der sicheren Seite.

Mesos ist eine Ergänzung zu Kubernetes oder Swarm und bringt in Form von Marathon zudem ein eigenes Framework für Container-Orchestrierung mit. Mit Mesos sollten sich Admins aber nur beschäftigen, wenn sie tatsächlich riesige Container-Setups im Rechenzentrum betreiben wollen. Denn für kleinere Setups ist Mesos schlicht zu viel des Guten und verursacht lediglich einen gehörigen Overhead.