© Vaclav Volrab, 123RF

Beim Management von Containern gilt vielen Admins Kubernetes als gesetzt. Es wäre aber unklug, die Alternativen mit hohem Wirkungsgrad außer Acht zu lassen, nur weil sie ein kleineres Rad drehen.

Einheitsbesetzung im Orchestrierungs-Graben: Kubernetes [1], das Google erfunden hat und das mittlerweile unter den Fittichen der Linux Foundation steht, hat sich nicht nur schnell gemausert, sondern zu einer Art Open-Source-untypischer Monokultur geführt. Dass viele Beobachter Kubernetes (Abbildung 1) als legitimen Open-Stack-Nachfolger sehen – obwohl beide Lösungen eigentlich verschiedene Zielgruppen haben – verstärkt den Eindruck.

Abbildung 1: Zwar nimmt Kubernetes die Platzhirsch-Position auf der Lichtung der Container-Orchestrierung ein, technisch betrachtet sind die Alternativen aber fit für den Revierkampf.

Vor diesem Hintergrund ist es wenig überraschend, dass Kubernetes durch seine Präsenz den Blick auf andere Lösungen zuweilen verdeckt, die zum eigenen Usecase womöglich viel besser passen. Dieser Artikel will den beklagten Zustand beenden, stellt einige der Alternativen zu Kubernetes vor und geht auf deren wichtigste Eigenschaften ein.

Docker Swarm

An erster Stelle in der Liste der Alternativen zu Kubernetes muss Docker Swarm ([2], Abbildung 2) stehen. Swarm darf als eine Art Panikreaktion von Docker gelten, als die Container-Bauer merkten, dass mehr und mehr Nutzer Docker mit Kubernetes kombinieren.

Abbildung 2: Docker Swarm versteht sich als Eins-zu-eins-Alternative zu Kubernetes und deckt folglich einen direkt vergleichbaren Funktionsumfang ab.

Docker wird so zum reinen Containerformat degradiert, das sich Kubernetes zunutze macht. Und längst nicht jeder Nutzer ist mit dem Docker-Format zufrieden. Das zeigt sich etwa daran, dass Red Hat seit Jahren an einer Docker-Alternative namens Rocket werkelt.

Im Docker-Hauptquartier musste man also auf der Hut sein: Würden immer mehr Leute ihre Container mit Kubernetes ausrollen, wäre es denkbar, dass ein neues und besseres Containerformat Docker ersetzt und die Firma am Ende mit leeren Händen dasteht. Docker Swarm ist insofern also auch der Versuch, die Kundschaft fester an die eigene Technik zu binden.

Da wundert es dann auch nicht, dass sich der Lieferumfang von Kubernetes und Docker Swarm in vieler Hinsicht ähnelt – auch wenn das Kind natürlich jeweils einen eigenen Namen hat. Kubernetes setzt beim Deployment von Apps zum Beispiel auf ein Pod-Konzept, wobei ein Pod eine Gruppe von Containern darstellt, die auf demselben Host laufen (co-located). Von Deployments lassen sich über den Cluster verteilt Replicas anlegen. Docker Swarm bietet ebenfalls diverse Möglichkeiten, um Applikationen als Multi-Container-Gesamtkunstwerk über den gesamten Cluster verteilt auszurollen; hier schwingt Docker Compose oft den Taktstock.

Virtuelle Containerumgebungen gut skalieren zu können ist für Kubernetes wie für Swarm immanent: Pods lassen sich ebenso horizontal skalieren wie Services in Docker. Ab Werk bietet Kubernetes wie Docker Swarm einen HA-Modus, um sowohl die Infrastruktur der Lösung als auch die Container selbst hochverfügbar zu gestalten. Load Balancer bieten dafür zusätzliche Funktionalität in Kubernetes, Swarm setzt hier stattdessen auf einen DNS-basierten Mechanismus. Trotz aller technischen Unterschiede: Am Ende erreichen beide Lösungen Vergleichbares.

Differenzen bei Storage und Netzwerk

Signifikante Unterschiede zwischen Kubernetes und Swarm zeigen sich hingegen in Sachen Storage und Netzwerk. Kubernetes bringt gleich zwei Storage-APIs mit, eins, um existierende Storage-Backends (wie Ceph) anzubinden, und eins, das eine Art Abstraktionsschicht für Storage-Anfragen bereitstellt, über die Container Storage-Ressourcen anfordern dürfen. Swarm hält es hier etwas simpler und nutzt das ohnehin in Docker vorhandene Volume-API, das beispielsweise über Plugins auch zusätzliche Speichertechniken einzubinden erlaubt.

Genau umgekehrt ist es beim Netzwerk: Kubernetes geht davon aus, dass das ganze Netzwerk flach ist, dass also alle Pods innerhalb desselben logischen Netzwerksegments liegen und entsprechend ungehindert kommunizieren.

Swarm hingegen sorgt dafür, dass jeder Knoten in einem Swarm-Cluster Teil eines Overlay-Netzwerks wird, der Docker-Traffic läuft also vom übrigen getrennt. Anders als Kubernetes bietet Swarm für dieses Netzwerk auch Verschlüsselung an. Und wer die Swarm-Plugin-Schnittstelle nutzt, kann mit externen SDN-Plugins sogar komplette Container-Netzwerk-Lösungen anbinden – ein gleichwertiges Feature fehlt Kubernetes.

Performance und Stabilität

Sowohl Kubernetes als auch Docker Swarm nehmen für sich in Anspruch, dass sie weit über die Grenzen des üblicherweise nötigen Umfangs skalieren. Im Falle von Kubernetes 1.6 bedeutet das, dass die Lösung bis zu 5000 physische Knoten unterstützt. Swarm kann pro Swarm Manager 1000 Knoten steuern und kommt auf bis zu 30000 Container pro Swarm-Manager-Instanz.

Für die meisten Setups dürfte das ausreichen – schon allein deshalb, weil viele Unternehmen ihre Kubernetes- oder Swarm-Cluster nicht im Mandantenbetrieb nutzen, sondern pro Kunde lieber eine eigene Infrastruktur bauen.

Technisch tun sich die Lösungen also wenig, auch wenn manche Funktion auf der einen oder anderen Seite abweichend implementiert oder benannt ist. Ob man auf Kubernetes oder Swarm setzt, hängt somit von der eigenen Präferenz ab.

Nomad

Einen fundamental anderen Ansatz als Docker Swarm und Kubernetes verfolgt das von Hashicorp entwickelte Nomad [3], auch wenn die Zielsetzung des Produkts vertraut klingt. Denn ganz am Anfang auf seiner Website stellt Nomad (Abbildung 3) fest, dass es ein Werkzeug sein will, das “Cluster physischer Maschinen sowie die darauf laufenden Applikationen” effektiv verwalten will. Wie üblich hilft es im Containerkontext an dieser Stelle, den Begriff “Applikation” zu übersetzen: Gemeint ist hier eine wie auch immer geartete Anwendung, die aus mehreren Mikrokomponenten besteht, die in einer vorgegebenen Art und Weise sowie in bestimmter Konfiguration zusammen auszurollen sind.

Abbildung 3: Nomad von Hashicorp versteht sich (auch) als Jobmanager für Virtualisierungsfunktionen.

Kubernetes und Swarm sehen als Format für dieses Ausrollen Container vor, also Docker oder Rocket – und schon hier setzt sich Nomad von seinen Konkurrenten ab: Neben Containern beherrscht es auch den Umgang mit virtualisierter Hardware, also klassischen VMs, sowie mit Stand-alone-Anwendungen, also solchen, die ohne Zusatzkomponenten unmittelbar verwendbar sind.

Kaum zu glauben, aber wahr: Nomad verspricht dem Admin auf der einen Seite einen Funktionsumfang, der mit dem von Kubernetes und Docker Swarm durchaus mithalten kann, kommt andererseits jedoch als einzelnes Binary daher, das sich ohne auffällige Probleme auf beliebig vielen Hosts ausrollen lässt. Externe Tools benötigt Nomad auch nicht. Hashicorp macht sich hier offenbar die Tatsache zu Nutze, dass die Firma in Form von Serf und Consul bereits Werkzeuge für Cluster gebaut hat, etwa Consul-spezifisch als Konsens-Algorithmus. Die Erfahrung, die das Unternehmen dabei gesammelt hat, ist in Nomad eingeflossen.

Tatsächlich gestaltet sich ein Nomad-Setup ausgesprochen simpel. Zwar besitzen auch Kubernetes und Swarm Werkzeuge, die einen kompletten Cluster in kurzer Zeit ausrollen, aber der Admin muss sich trotzdem mit vielen Komponenten herumschlagen. Nomad dagegen ist tatsächlich ein einzelnes Binary, das alle relevanten Funktionen bündelt.

Microservices verwalten

Laut eigener Aussage hat Hashicorp bei Nomad vor allem ein Ziel: Dem Admin ein Werkzeug an die Hand zu geben, mit dem er den Workload Tausender kleiner Applikationen über die Knotengrenzen innerhalb eines Clusters gut und effizient verwalten kann.

Dabei ist den Entwicklern ganz wichtig, dass Nomad an die zugrunde liegende Infrastruktur keine besonderen Anforderungen stellt: Ob Nomad auf eigenem Blech oder im eigenen Rechenzentrum startet, ist für das Programm unerheblich. Auch hybride Setups sind kein Problem, wenn der Admin dafür sorgt, dass die Netzwerkverbindung zwischen den Nomad-Knoten funktioniert.

Möchte der Admin eine Applikation starten, handelt es sich bei dieser im Nomad-Sprech um einen Job: Im »nomad«-Aufruf legt er alle relevanten Details fest, etwa den zu nutzenden Treiber – beispielsweise Docker – oder applikationsspezifische Daten. Hier hat der Admin die Wahl zwischen dem Hashicorp-eigenen HCL-Format oder Json, das allerdings deutlich weniger leicht zu lesen und zu schreiben ist.

Am Ende übergibt er die Job-Beschreibung direkt an Nomad, das sich nun darum kümmert, die entsprechenden Jobs im Cluster abzuarbeiten, indem es etwa benötigte Container startet.

Dass die Sache mit dem einzelnen Binärprogramm vielleicht doch etwas zu optimistisch ist, merkt der Admin, wenn er verschiedene Dienste innerhalb des Clusters ausrollen möchte, die aufeinander zugreifen sollen. Das Problem ist an sich nicht neu: Will man etwa eine Datenbank und viele Webserver-Setups in seinem Cluster betreiben, die auf eben jene Datenbank zugreifen, müssen die Webserver wissen, wie sie die Datenbank erreichen. Statisch konfigurieren kann der Admin das aber nicht, denn es entscheidet sich ja erst zum Zeitpunkt des Abarbeitens eines Jobs durch Nomad, wo die Datenbank am Ende läuft.

Nomad bietet für diesen Fall allerdings die Möglichkeit, sich mit Consul – ebenfalls von Hashicorp – zu verbünden: Der fertige Job legt in Consul dann eine entsprechende Service-Definition an, auf die der Admin in der Webserver-Applikation anschließend verweist.

Treiber und Web-UI

Als Treiber bezeichnet Nomad eine beliebige Schnittstelle, über die es seine Jobs startet. Es gibt einen Treiber für Docker, ein anderer bindet LXC an, ein dritter beherrscht den Umgang mit Qemu und KVM. Schnell fällt auf: Nomad versteht sich selbst – anders als Kubernetes und Docker – wirklich nur als Scheduling-Werkzeug. Für seine Applikationen verlässt es sich hundertprozentig auf die angebotenen Funktionen der Treiber. Eigene Netzwerk- oder Storage-Funktionen offeriert Nomad nicht, die kommen samt und sonders vom angedockten Partner, also von Docker beispielsweise.

Wie es sich gehört, bietet Nomad ein standesgemäßes Restful-API, über das sich Aufträge direkt einkippen lassen. Das API bildet obendrein das Backend für eine grafische Oberfläche, die bei Nomad zum Lieferumfang der Open-Source-Variante dazugehört. Zudem versteht sich Nomad ab Werk auf den Umgang mit Regionen, sodass Multi-Site-Lösungen nichts entgegensteht.

In Sachen Skalierbarkeit braucht sich Nomad vor der großen Konkurrenz auch nicht zu verstecken: Laut Aussagen der Entwickler existieren Nomad-Setups mit mehr als 10000 Knoten im Live-Betrieb, die zuverlässig funktionieren. Vor dem Hintergrund, dass Nomad einen deutlich geringeren Overhead impliziert als Kubernetes und Docker Swarm, ist diese Aussage glaubwürdig, auch ohne es selbst getestet zu haben.

Nomad gibt es nicht nur als Open Source. Hashicorp hat von der Software auch eine “Pro”- und eine “Premium”-Version im Programm, die sich ausdrücklich an Kunden im Enterprise-Umfeld richten. Die Variante “Pro” bietet neben den Funktionen der Open-Source-Variante auch Namespaces an, die es erlauben, einen Nomad-Cluster logisch aufzuteilen. Der Autopilot, der sich in der Open-Source-Variante um Rolling Upgrades kümmert, kommt bei Pro in einer Advanced-Version daher, die alle Server im laufenden Betrieb unterbrechungsfrei aktualisiert. Hinzu gesellt sich Silber-Support (9/5 mit entsprechendem SLA).

Wer zur Premium-Variante greift, erhält zusätzlich Ressourcen-Quotas sowie ein Policy-Framework auf Basis von Sentinal und Gold-Support (24/7 mit SLA).Mit Preisen geht die Hashicorp-Website jedoch nicht hausieren. Nur wer eine Pro- oder Premium-Demo anfordert, um nicht die Katze im Sack zu kaufen, bekommt eine Preisauskunft geliefert.

In Summe gilt: Nomad ist eine leichtfüßige Kubernetes-Alternative, die für die Usecases vieler Unternehmen völlig ausreicht. Wer also Mikro-Applikationen in Containern betreiben möchte, sollte sich Nomad im Vorfeld gut ansehen.

Kontena

Wo Nomad auf Kleckern setzt, klotzt Kontena (Abbildung 4) ungeniert. Die Firma aus New York und Helsinki geriert sich als vollständige Alternative zu Kubernetes, die diesem im Hinblick auf sein Feature-Set in nichts nachstehen möchte. Architektonisch ist Kontena [4] Kubernetes in vielerlei Hinsicht ähnlich: Auf den Kontena-Knoten, die echtes Blech oder virtuelle Maschinen in einer Cloudumgebung sein können, läuft der Kontena-Agent, den eine zentrale Kontena-Master-Instanz steuert.

Abbildung 4: Kontena ähnelt im Hinblick auf seinen Funktionsumfang Kubernetes und Docker Swarm und ist sehr mächtig.

Über die Zielknoten stülpt Kontena diverse Schichten: Zunächst erzeugt es ein Overlay-Netzwerk auf Basis der Technologie Weave [5], was es allen Teilen des Setups erlaubt, über die Grenzen von Hosts, Rechenzentren und Netzwerken miteinander zu kommunizieren.

Zusätzlich enthält Kontena eine Service-Discovery-Lösung auf Basis von DNS: Die gehört bei Containerlösungen zum Standardprogramm und erledigt die Aufgabe, die für Nomad weiter oben im Hinblick auf Node Discovery bereits ausführlich beschrieben ist.

Eine Kernkomponente der Software ist der Kontena-Orchestrator: Er kümmert sich darum, verschiedene Container in Single-Konfiguration oder als Gespann auf die Knoten zu verteilen und entsprechend miteinander zu verbinden. Das Workload-Modell von Kontena unterscheidet sich so kaum von dem in Kubernetes, Docker Swarm oder den meisten anderen Containerlösungen.

Beeindruckend ist bei Kontena besonders die Anzahl von Treibern, über die sich externe Produkte ansteuern lassen. So verfügt Kontena über eine Anbindung für externe Speicher, die sowohl physische Speicher im eigenen Rechenzentrum wie auch Cloud-Speicherdienste bei den großen Cloudanbietern unterstützt.

Die Weave-Lösung, die für das virtuelle Netz zwischen den Containern zum Einsatz kommt, bietet Funktionen wie Multicast-Support und die Möglichkeit, per Peer-to-Peer-Funktion auch VMs in Clouds direkt anzubinden. So versteht Kontena sich als Lösung für hybride Umgebungen bestehend aus On-Premise-Diensten und Cloudangeboten.

Viel Liebe zum Detail

Spaß machen bei Kontena besonders die vielen kleinen Funktionen und die diversen Gimmicks, welche die Entwickler eingebaut haben. Wer für seine Container etwa Zertifikate benötigt, freut sich über die eingebaute Anbindung an Lets Encrypt, die das Ausstellen von Zertifikaten per Mausklick zum Kinderspiel macht. Ein komplettes System für die Rollen-basierte Zugriffskontrolle (RBAC) ermöglicht es, den Zugriff auf Kontena feingliedrig zu steuern.

Open VPN ist mit an Bord, um eine sichere Verbindung über ein internes Netzwerk für Kunden zu ermöglichen. Load Balancer, die bei fast allen Containerverwaltern zum Lieferumfang gehören, lassen sich bei Kontena flexibel konfigurieren, etwa als SSL-Terminator nutzen, und sie ermöglichen im Gespann mit verschiedenen anderen Diensten auch Rolling Updates.

Ebenfalls umfangreich sind die Möglichkeiten für Admins, ihre Applikationen in Form von Containern in Kontena zu integrieren. Wer Docker Compose nutzt, hat in Kontena eine Schnittstelle, an die Compose unmittelbar andocken kann. Auch manuell lassen sich Application-Definitionen einspielen. Ist eine Applikation in Kontena einmal vorhanden, skaliert die Umgebung sie nach Wunsch auf Basis verschiedener Parameter automatisch in die Breite.

Zudem ist es möglich, auf Basis laufender Applikationen Stacks zu definieren: Das sind fertige, vorpaketierte und wiederverwendbare Sammlungen von Diensten, also eine Art Template. Wer etwa ein Webserver-Setup in Kontena erfolgreich aus Einzelteilen zusammengesetzt hat, darf einen Stack daraus machen und das Setup so oft er will reproduzieren.

Anbindung nach außen: Sehr gut

Vorbildlich ist auch die Anbindung an externe Dienste: Neben den natürlich vorhandenen APIs bindet Kontena auf Wunsch verschiedene Monitoring-Werkzeuge ebenso ein wie klassische Logging-Lösungen, etwa Fluentd oder Statsd. Wer aus Compliance-Gründen einen Audit-Trail braucht, bekommt diesen in Kontena ebenso frei Haus geliefert. Eine eigene Image-Registry in Kombination mit einem sehr umfangreichen Web-UI runden das Angebot ab.

Kontena selbst ist kostenlos, beim Hersteller kann man auf Wunsch jedoch verschiedene Supportpakete erwerben, die zum Teil auch das Deployment auf eigener Infrastruktur sowie Training und Business-Support enthalten. Details dazu finden sich auf der Website [4].

Rancher

Keine unmittelbare Alternative zu Kubernetes ist Rancher [6], denn es enthält eine komplette Kubernetes-Distribution. Laut Hersteller erweitert das Produkt (Abbildung 5) aber Kubernetes an drei wichtigen Punkten: Es soll das effiziente und einfache Steuern verschiedener Kubernetes-Installationen auf verschiedenen Plattformen ermöglichen, es fügt eine Management-Komponente für das Steuern des Workloads von Applikationen hinzu und es bietet für Kubernetes Enterprise-Support an.

Abbildung 5: Rancher ist ein Aufbau für Kubernetes, der verschiedene Features bietet, zum Beispiel eine umfassende Management-Schicht.

Den Management-Teil sieht so aus: Rancher enthält eine zentrale Control-Plane, aus der heraus sich mehrere Kubernetes-Cluster managen lassen, nachdem der Admin diese direkt aus Rancher heraus ausgerollt hat. Per Mausklick startet Rancher also komplette Kubernetes-Instanzen wahlweise in verschiedenen Public-Clouds wie AWS, Azure oder der Google Cloud Platform.

Weil Rancher zudem eine eigene Rechteverwaltung mitbringt, lässt sich das Thema Benutzerverwaltung über alle Kubernetes-Instanzen hinweg konsistent und konsequent umsetzen. Hinzu kommen diverse Managementfunktionen wie Monitoring, Alerting und Trending (MAT) der diversen Kubernetes-Cluster.

Das Application Management ermöglicht es Nutzern, ihre in Mikroarchitektur gebauten Applikationen zentral aus Rancher heraus auf verschiedenen Clustern auszurollen. Dabei darf der Admin auch User-Projekte anlegen, die verschiedene Namespaces innerhalb der Kubernetes-Cluster umfassen. Ebenso Teil des Pakets sind umfassende CI/CD-Pipelines, was das Entwickeln von Applikationen auf Basis von Rancher ermöglicht.

Das Thema Support erklärt sich schließlich fast von selbst: Rancher selbst ist Open Source, der Hersteller bietet jedoch kommerziellen Support für die Lösung an. Konkrete Preise finden sich auf der Rancher-Website allerdings nicht, wie mittlerweile fast schon üblich muss man hierfür Kontakt mit dem Hersteller der Software aufnehmen.

Über den Umfang des Supports gibt der Rancher mehr Details bekannt: 24/7-Unterstützung ist verfügbar, und wer Hilfe bereits beim Setup des Clusters braucht, bekommt sie auf Anfrage. Firmen, die also mit dem Gedanken spielen, sich Kubernetes ins Haus zu holen, sollten mit dem Rancher zumindest Bekanntschaft schließen – gerade dann, wenn das Ziel aus vielen kleinen Setups auf Kubernetes-Basis besteht, die auf mehrere Standorte oder Plattformen zu verteilen sind.

Azk

Der letzte Proband in dieser Übersicht ist Azk – anders als die bis hierhin vorgestellten Werkzeuge richtet es sich ausschließlich an die Zielgruppe der Entwickler. Denn Azk will nicht das ganz große Container-Rad drehen; es will stattdessen Entwicklern die Möglichkeit geben, sich mit lokalen Mitteln in möglichst kurzer Zeit eine funktionierende Entwicklungsumgebung auf Basis von Containern zu erschaffen. So seltsam es klingt: In vielen Unternehmen betreiben die Admins riesige Kubernetes-Plattformen nur, damit Entwickler im Haus eine funktionierende Entwicklungsplattform haben. Azk ist dazu eine sehr willkommene Alternative [7].

Azk funktioniert denkbar einfach: In einer Template-Datei definiert ein Entwickler seine gewünschte Umgebung, und zwar auf Basis der Javascript-Syntax. Unter der Haube setzt das Programm zwar auf Docker, unter [8] bieten seine Entwickler jedoch eine Vielzahl entsprechend vorbereiteter Docker-Abbilder an, die sich insbesondere an die Entwickler von Webapplikationen wenden. Auf die genannten Images verweist der Entwickler in »azkfile.js«. Alle für den Betrieb der Container nötigen Parameter gibt er in der Datei ebenfalls an.

Am Ende ruft er lediglich Azk mit dem entsprechenden Template auf – wenn das Programm seine Arbeit erledigt hat, ist die Entwicklungsumgebung fertig. Benötigt der Entwickler die gleiche Umgebung zu einem späteren Zeitpunkt erneut, ruft er einfach wieder Azk auf und ist binnen kürzester Zeit am Ziel.

Schnell im Ziel

Der Funktionsumfang von Azk ist nicht mit jenem der großen Container-Orchestrierer zu vergleichen, aber genau das wollen seine Entwickler ja auch gar nicht. Seinen festen Platz hat Azk stattdessen in der Entwicklung. Wer sich mit der Syntax der Manifest-Datei »azkfile.js« einmal vertraut gemacht hat, kommt schnell zu Ergebnissen, und zwar ohne einen kompletten und riesigen Kubernetes-Cluster mit all seinen Komponenten zu betreiben.