© blueximages, 123RF

Google betreibt die meisten Server und beschäftigt sich mit dem Thema Containervirtualisierung. Es stellt in Form von Kubernetes eine Spezialdistribution vor, um Sysadmins das Leben mit Docker zu erleichtern.

Nach wie vor gibt es handfeste Gründe, beim Virtualisieren auf Container zu setzen statt auf KVM oder Xen mit ihren vollvirtualisierten Systemen. So erlauben Container eine höhere Packungsdichte: Ein Container ist ja zunächst nicht mehr als ein Verzeichnis innerhalb eines Linux-Systems, das die Ressourcen des Hosts mitbenutzt. Anders als bei Vollvirtualisierern landet für den Container also wirklich nur das Nötige im Speicher, und es zehren nur jene Komponenten an der CPU, die für die Dienste innerhalb des Containers nötig sind.

Seit Jahren im Blick

Kein Wunder, dass auch Google laut eigener Aussage bereits seit Jahren auf Containervirtualisierung setzt. Und logisch ist auch, dass bei Google der Bedarf an Werkzeugen für eine effiziente Verwaltung besonders hoch ist: Es betreibt derart viel Infrastruktur, dass sich selbst kleinste Performance-Gewinne durch Vervielfachung schnell zu großen Einsparungen auswachsen.

Traditionell werkelt Google nicht nur im stillen Kämmerlein vor sich hin, sondern lässt die Open-Source-Community an den eigenen Produkten teilhaben. Vor diesem Hintergrund veröffentlichte das Unternehmen im Jahre 2014 die erste öffentliche Version von Kubernetes [1]. Hinter dem etwas sperrigen Namen versteckt sich eine eigene Linux-Distribution, die speziell auf den Betrieb von Docker-Containern ausgerichtet ist und Docker [2] um viele nützliche Funktionen im Hinblick auf große Computing-Netzwerke erweitert.

Mittlerweile beteiligen sich auch Suse und Red Hat an der Kubernetes-Entwicklung. Zeit also, sich mit Kubernetes genauer zu befassen: Wie kommt es in einem Markt an, in dem Core OS und diverse andere Mikrosysteme aktiv sind? Das Linux-Magazin hat die Software unter die Lupe genommen und beantwortet Fragen. Los geht es mit einer Erläuterung der grundlegenden Funktionen.

Das Problem

Eine Containersoftware allein ergibt noch keine im Rechenzentrum nutzbare Lösung. Docker als Tool zum Verteilen von generischen Quasi-Binaries eignet sich hierfür schon besser. Im Google-Beispiel reicht ein einzelnes Docker auf einem einzelnen Compute-Host aber nicht aus. Der Internetriese muss unzählige Systeme weltweit zu einer Computing-Umgebung vereinen und sicherstellen, dass sich die Server auch aus der Ferne gut verwalten lassen.

Hier gibt es einen Pool an Rechenleistung, und die Container sollen samt Netzwerk und Storage eben gerade dort laufen, wo es aus Sicht der Plattform am sinnvollsten ist. Kubernetes ist Googles Ansatz, Docker Enterprise-tauglich zu machen (Abbildung 1). Die Lösung soll die Vorteile großer Computing-Umgebungen ausschöpfen.

Abbildung 1: Docker kann ab Werk nur Container auf dem lokalen Host nutzen. Kubernetes soll das Werkzeug um Flottenfähigkeit erweitern.

Kubernetes hat übrigens Konkurrenz: Core OS [3] verfolgt ein ähnliches Ansinnen und setzt zu diesem Zweck auf Werkzeuge wie Systemd und Etcd. Das Project Atomic hat ebenfalls ganz vergleichbare Ziele.

Doch nimmt Kubernetes in der Riege der Flottenvirtualisierer mit Containertechnologie eine Sonderstellung ein. Weil es nicht auf eine der spezifischen Distributionen setzt und auch nicht von einem Distributor direkt entwickelt wird, verfolgt es einen übergeordneten Anspruch und will eine eher universale Lösung sein. Das zeigt sich unter anderem darin, dass Kubernetes unter Red Hat genauso funktionieren soll wie unter Ubuntu.

Docker ist ab Werk vernetzt und verwaltet Container auf einem bestimmten Host. Kubernetes soll Docker um den Faktor Flottenfähigkeit erweitern. In seinen Design-Dokumenten führt der Primus in Sachen Internetsuche gleich mehrere Fachbegriffe ein, um den eigenen Ansatz genauer zu erklären. Für das Verständnis von Kubernetes sind diese Begriffe wichtig, deshalb erklärt sie dieser Beitrag im Folgenden.

Hülsenfrüchte

Da ist zunächst der Begriff des Pod. Pod ist der englische Ausdruck für Hülse und gleichzeitig die kleinste Verwaltungseinheit, in der Googles Kubernetes denkt. Unter Pod summiert Google eine beliebige Menge an Containern, die es intern als Verwaltungseinheit betrachtet. (Google spricht in seiner Dokumentation stets von Applications und nicht von Containern.) Selbst wenn ein Nutzer nur einen einzelnen Container startet, baut Kubernetes um diesen herum ein Wrapper-Pod. Eigentlich sieht Google die Pods aber als eine Verwaltungsmöglichkeit für Tausende Container.

Pods kümmern sich im Kubernetes-Universum um die Orchestrierung. Für die Definition von Pods schreiben Admins Textdateien. Mögliche Formate sind Yaml oder Json. Die Pod-Definition enthält alle wesentlichen Details: Welche Container soll der Pod enthalten? Welche Betriebssysteme nutzen diese und welche besonderen Dienste sollen innerhalb der Pods laufen? Ist eine passende Datei zum Starten des Pod entstanden, übergibt der Admin diese an Kubernetes – das sich im Hintergrund darum kümmert, die Container wunschgemäß zu starten.

Alte Bekannte: Namespaces

Auf Server-Seite zeichnen sich Pods durch mehrere Eigenschaften aus. Da ist zunächst die Tatsache, dass ein Pod den in ihm laufenden Containern mehrere Linux-Namespaces überstülpt, auf die alle Pod-Container dann zugreifen können. Zur Erinnerung: Namespaces sind ein Feature im Linux-Kernel, das in verschiedenen Bereichen wie der Netzwerk- oder der Prozess-Ebene virtuelle Teilbereiche einrichtet. Applikationen, die innerhalb eines Namespace laufen, können diesen nicht einfach verlassen, sondern sind quasi darin eingesperrt.

Die Container eines Pod haben also Zugriff auf denselben virtuellen Stack für das Netzwerk und die eigenen Prozesse. Obendrein teilen sie sich den Hostnamen. Auch die Möglichkeit der Interprozess-Kommunikation ist Kubernetes in die Wiege gelegt. Fast scheint es, als betrachte Google Docker-Container in einem Pod gar nicht als Container, sondern als einzelnes Programm.

Das passt auch zur Aussage des Herstellers, Kubernetes sei in Wirklichkeit Applikations-spezifisch. Der Internetriese stellt klar, dass es in einem Pod zwar viele Container geben kann; doch jeder Container innerhalb der Umgebung erledigt genau eine spezifische Aufgabe und betreibt im Idealfall auch nur eine einzelne Applikation. Wer mehr als eine Applikation hosten will, ist also gehalten seinen Pod einfach mit entsprechend mehr Containern schon bei der Pod-Definition zu versehen.

Gruppenkuscheln

Die Applikationen, die zu einem Pod gehören, sind zur Durchsetzung dieses Prinzips stets colocated, also auf demselben Host gelagert. Wer dabei an die Themen Hochverfügbarkeit und Redundanz denkt, könnte hier ins Stutzen geraten. Google weist aber darauf hin, dass Pods eigentlich ephemeral sind, also nicht darauf ausgelegt, dauerhaft zu laufen. Die Idee hat in den vergangenen Jahren gerade beim Thema Cloud für Furore gesorgt. Denn sie kollidiert scheinbar mit dem Mantra der Hochverfügbarkeit.

Tatsächlich erreicht sie das gleiche Ziel aber nur auf andre Weise: Statt einzelner, hochspezifischer Hosts existieren viele generische Systeme, die sich im Falle eines Falles schnell aus der Tüte wieder herstellen lassen. Spezifische Daten sind nicht unmöglich, müssen aber separat angebunden werden. Google betrachtet Pods in Kubernetes nach dem gleichen Prinzip: Persistenz ist zwar über einen eigens anzubindenden Speicher möglich, doch das betrifft nur die tatsächlich spezifischen Daten.

Die Pods und die dazu gehörenden Applications sind zu jedem Zeitpunkt austauschbar. Deshalb fehlen Kubernetes auch alle Funktionen zum Umziehen von VMs: Statt eine Migration durchzuführen würde einfach auf einem anderen Host der gleiche Pod noch einmal gestartet, um im Anschluss den gleichen, persistenten Speicher an ihn anzuschließen.

Labels

Zusätzlich zu den Pods erhält der Admin in Kubernetes auch die Möglichkeit, eine zwischen Pods existierende Bedingung zum Ausdruck zu bringen. Dafür sind Labels vorhanden: Pods, die ähnliche Dienste anbieten, könnten etwa mit Hilfe des Service-Labels auf Kubernetes-Ebene zu einer logischen Einheit verknüpft werden. Labels haben vor allem administrativen Nutzen: Durch ihre Verwendung bringt der Admin etwa zum Ausdruck, dass drei verschiedene Pods Applikationen enthalten, die im Hintergrund miteinander reden.

Ein Galera-Cluster mit MySQL wäre ein typisches Beispiel: Mindestens drei Pods mit einer Galera-Application wären dafür notwendig. Mit einem entsprechenden Label Selector würde der Admin sicherstellen, dass Kubernetes die Pods als zusammengehörig erkennt und etwa für vernünftige Netzwerkfunktionalität zwischen den Pods sorgt.

Der Master-Server

Wenn Pods und Labels virtuelle Sammlungen von Containern sind und Kubernetes das über ihnen liegende Management-Framework, dann müssen die beiden Sphären irgendwie miteinander verbunden sein. Google setzt dafür gleich auf mehrere Komponenten.

Der zentrale Dreh- und Angelpunkt einer Kubernetes-Installation ist dabei ein Master-Server. Der Master-Server besteht aus mehreren Komponenten: Einer Sammlung von APIs, einem Scheduler für Pods, einem Controller für Serverdienste des Nutzers und einer Datenbank für die Konfiguration der Cloud und einer Authentifizierungskomponente, an der sich alle anderen Dienste orientieren.

Die APIs sind dabei der nach außen am besten sichtbare Teil: »kubectl« ist das Standard-CLI von Kubernetes. Mit ihm erteilt der Admin der Plattform unmittelbar Befehle. Ein »kubectl« -Aufruf führt zu einem Request an das Kubernetes-API, das auf dem Restful-Prinzip basiert. Vorher meldet sich der Client noch beim Autorisierungsdienst an. Der Kubernetes Info Service stellt auch die Informationen für die Kubelet-Instanzen auf den Container-Hosts aus dem Kubernetes-API heraus bereit.

Kubelet bezeichnet dabei den Dienst, der als Agent auf den Hypervisoren läuft und auf Zuruf Container startet. Ein eigener Scheduler in Kubernetes legt fest, welcher Hypervisor eine VM starten soll – der Scheduling Actuator leitet die Info an die Kubernetes Info Services weiter, von wo die Kubelet-Instanzen sich ihre Befehle abholen.

Integrierte Replikation

Zusätzlich findet sich auf dem Master-Server bei Kubernetes eine Komponente namens Controller Manager, der einen Replication Controller verwaltet. Das ist – ähnlich wie der »service« – ein Label, das die Abhängigkeit zweier Pods zum Ausdruck bringt. Replication Controller sorgen in Kubernetes etwa für das Skalieren in die Breite: Ist ein Replication Controller für einen Pod gesetzt, startet Kubernetes anhand definierbarer Parameter automatisch neue Instanzen jenes Pod – etwa dann, wenn spezifische Lastgrenzen überschritten sind.

Schließlich ist auch Etcd eine integrale Komponente beim Kubernetes-Master. Der Dienst fungiert als Plattform-weiter Key/Value-Store für Einstellungen, die auf den Hypervisor-Knoten benötigt werden. Etcd ist dezentral und repliziert seine Informationen automatisch über alle Instanzen der Installation, sodass auf jedem Host mit laufendem Etcd alle Konfigurationsoptionen verfügbar sind.

Arbeit aus der Ferne

Neben dem bereits erwähnten Kubelet laufen für Kubernetes auch auf den Hypervisor-Hosts noch andere Dienste. Da wäre etwa das Thema Netzwerk: Aktuell kommt Kubernetes mit einer eigenen Komponente namens Proxy, die sich zentralisiert um Netzwerkzugriff innerhalb und außerhalb der Plattform kümmert (Abbildung 2).

Abbildung 2: Kubernetes kommt ab Werk mit einem eher einfachen Netzwerksetup daher. Doch auch an der Integration mit SDN-Lösungen wie Open Vswitch arbeiten die Entwickler.

Wann immer ein Pod erreicht werden soll, geht das im Augenblick durch den von Kubernetes konfigurierten Proxyserver. Elegant ist das allerdings nicht, und um ein echtes SDN-Setup zu werden, braucht der Proxyserver noch einiges an Funktionalität. Ohnehin hat längst die Rallye begonnen, SDN-Ansätze wie Open Vswitch mit Kubernetes zu koppeln. Langfristig dürften sich solche Lösungen gegenüber dem einfachen Proxyansatz durchsetzen.

Abschließend sei freilich auch Saltstack erwähnt: Kubernetes setzt intern auf Saltstack, das selbst ein Werkzeug für Konfigurationsmanagement und Clouds ist. Grundsätzlich ist es dabei durchaus mit anderen Lösungen wie Puppet oder Chef vergleichbar, doch betitelt der Hersteller das Produkt als “optimiert für die Cloud”. Besonders bei skalierbaren Systemen soll Saltstack gegenüber anderen Lösungen massive Vorteile bieten.

Die Kubernetes-Entwickler hat das ganz offenbar überzeugt: Jeder Kubernetes-Hypervisor gilt als Minion, wobei “Minion” im Saltstack-Sprech die Standardbezeichnung für einen Host ist, der am Konfigurationsmanagement durch Saltstack teilnimmt.

Spätestens mit der Entscheidung, ein eigenes Werkzeug für die Pflege und das Verteilen von Konfigurationsdateien zum Einsatz zu bringen, hat Google – ob gewollt oder nicht – für Kubernetes einen gewissen Anspruch definiert. Denn wenn eine Virtualisierungslösung eine eigene Verwaltung mitbringt, geht es nicht mehr um ein kleines Werkzeug – sondern eine ausgewachsene Umgebung.

Mit Kubernetes arbeiten

Damit sind die grundlegenden Komponenten eines Kubernetes-Setups klar. Nicht beantwortet sind hingegen die Fragen, warum Kubernetes für Admins interessant sein soll und welche Aufgaben sie damit eigentlich lösen können. Als sicher darf gelten, dass Google Kubernetes im Bereich der Cloudframeworks positionieren will, und dort etwa im gleichen Umfeld, in dem Core OS, Project Atomic oder die vielen anderen Makro-Distributionen aufgehoben sind.

Doch Kubernetes erfordert deutlich mehr Aufwand, um zu einer fertigen Installation zu kommen. Mit Core OS ist es viel leichter, loszulegen. De facto lässt sich Kubernetes aber auch als Aufsatz auf Core OS nutzen. Immerhin: Google stellt im Rahmen des Google Computing Environment (GCE) fertige Images für Kubernetes bereit, sodass sich die Anwendung per Mausklick schnell und einfach testen lässt. Wer die Arbeit mit purem Docker bereits kennt, wird sich an die Funktionalität von Kubernetes nach einer kurzen Zeit der Einarbeitung gern gewöhnen. Denn durch die Möglichkeit, Container im Rahmen eines Clusters mit Pods und Labels zu betreiben, erweitert Google Docker um eine Funktion, die bei der normalen Variante fehlt.

Bis jetzt erfolgte die Kubernetes-Entwicklung maßgeblich in den heiligen Hallen von Google. Erst durch die Öffnung hin zu anderen Anbietern und Herstellern wird das Projekt wirklich interessant. Da nun Red Hat und Suse ebenfalls im Boot sind, dürfte eine komfortablere Installation nicht lange auf sich warten lassen. Und auch ein Kubernetes-GUI, das derzeit noch fehlt, wird wohl irgendwann kommen. Wer Containervirtualisierung im Verbund eines Setups vieler Hypervisor-Knoten betreibt, wird sich also von Kubernetes früher oder später angesprochen fühlen.

Kubernetes? Open Stack? Beides?

Beim Überblicken der am Markt verfügbaren Lösungen stellt sich eine ganz andere Frage: Ist Kubernetes überhaupt notwendig, wenn Cloudlösungen wie Open Stack oder Cloudstack verfügbar sind und eine deutlich größere Community haben? Kubernetes und Open Stack können gewisse Ähnlichkeiten ihrer Architektur nicht leugnen.

Das Server-Agent-Prinzip etwa findet sich bei beiden in ähnlicher Weise. Auch bei Open Stack gibt es die zentralen Server und APIs sowie die Agents, die auf den einzelnen Hypervisor-Hosts laufen und dort ihre Befehle entgegennehmen. Auch die Art der Funktionen ist bei Kubernetes und Open Stack ähnlich: Beide Lösungen wollen komfortabel die Nutzung von Computing-Ressourcen in einem Rechnerverbund ermöglichen.

Doch genaueres Hinsehen offenbart, dass es zwischen Open Stack und Kubernetes auch große Unterschiede gibt. Die Benutzerverwaltung sei als ein Beispiel genannt: Open Stack ist darauf ausgelegt, mandantenfähig zu sein. Kubernetes besitzt diese Möglichkeit im Augenblick nicht. Dafür ist Kubernetes ein hochgradig spezialisiertes Werkzeug, während bei Open Stack die Zeichen jeden Tag ein bisschen mehr auf “die universale Lösung für alles” stellt.

Zwar ist auch Kubernetes keine kleine Umgebung, doch im Vergleich mit dem fast übergroßen Open Stack wirkt es schnell und flexibel. So wundert es auch nicht, dass viele Beobachter Open Stack und Kubernetes nicht als Konkurrenten betrachten, sondern als sich sinnvoll ergänzende Komponenten.

Die aus Amerika kommende Firma Mirantis sieht das offenbar ähnlich (Abbildung 3). Mirantis hat sich in der Community einen Namen gemacht. Obendrein werkelt das Unternehmen aktiv an Fuel, einem Open-Stack-Setup-Werkzeug. Im Februar kündigte Mirantis an, dass ein Agreement mit Google getroffen sei, um eine sinnvolle Integration von Kubernetes in Open Stack zusammen mit dem Hersteller zu entwickeln. Zweck der Aktion sei es, am Ende eine brauchbare Form der Virtualisierung mit Containern in Open Stack anzubieten.

Abbildung 3: Mirantis versteht Open Stack nicht als Konkurrenz zu Kubernetes, sondern als sinnvolle Ergänzung. Die Firma arbeitet aktiv an der Integration der beiden Komponenten.

Genau daran scheitert es bis jetzt sehr offensichtlich: Der einzige irgendwie nutzbare Treiber für Container in Open Stack ist zwar auch für Docker gemacht, doch ist er nicht Teil der offiziellen Open-Stack-Distribution und produktiv nicht gut einsetzbar. Gelingt es Mirantis, Kubernetes und Open Stack sinnvoll aneinander zu binden, könnte sich für Open-Stack-Anwender wie für Kubernetes-Interessenten daraus also ein sehr fruchtbares Joint Venture ergeben.

Um unter Beweis zu stellen, dass man nicht nur Worthülsen produziert, heftete Mirantis dem Google-Announcement gleich auch ein kurzes Video an: Zu sehen ist ein Open-Stack-Dashboard, aus dem heraus sich bereits Pods in Kubernetes starten lassen (Abbildung 4). Leider nennt Mirantis aber noch kein Datum für die Verfügbarkeit der entsprechenden Komponenten.

Abbildung 4: Mirantis hat auch schon unter Beweis gestellt, dass es Kubernetes in die Netzwerkinfrastruktur von Open Stack integriert hat.

Fazit

Kubernetes ist ein interessantes Projekt mit einem mächtigem Geldgeber im Rücken. Gerade weil Google das Werkzeug als eigene Virtualisierungszukunft auserkoren hat und schon so einsetzt, dürfte Kubernetes keine Eintagsfliege sein. Admins sollten aber sorgsam prüfen, bevor sie sich an Kubernetes binden. Denn eine universelle Lösung ist die Software nicht. Stattdessen fokussiert sie sich auf die Idee, unter Verwendung weniger Ressourcen eine hohe Virtualisierungsdichte zu erreichen. Nur wer ähnliche Anforderungen hat, sollte sich mit Kubernetes beschäftigen. Alle anderen Anwender sind mit kleineren Projekten wie Core OS wohl besser bedient:

Auch interessant ist Kubernetes vor dem Hintergrund des Announcements von Mirantis [4] für Admins, die Open Stack nutzen und dort Containervirtualisierung verwenden wollen. Hier könnte das Produkt zum Bindeglied zwischen Open Stack und Docker werden.