Bereits Kunde? Jetzt einloggen.
Lesezeit ca. 12 Min.

Container-Orchestrierung im Vergleich (1): Chefdirigent


IT Administrator - epaper ⋅ Ausgabe 11/2019 vom 30.10.2019

Mit Docker haben Container ihren Durchbruch erzielt. In größeren Umgebungen ist es wichtig, Anwendungen möglichst automatisiert und hoch skalierbar bereitzustellen. Bei einem Vergleich gängiger Cluster-Manager für Container-Workloads haben neben Kubernetes vor allem AWS ECS, Docker Swarm und Apache Mesos eine Daseinsberechtigung. Der erste Teil unserer zweiteiligen Übersicht vergleicht Kubernetes beziehungsweise die Google Kubernetes Engine mit Docker Swarm.


Artikelbild für den Artikel "Container-Orchestrierung im Vergleich (1): Chefdirigent" aus der Ausgabe 11/2019 von IT Administrator. Dieses epaper sofort kaufen oder online lesen mit der Zeitschriften-Flatrate United Kiosk NEWS.

Bildquelle: IT Administrator, Ausgabe 11/2019

Quelle: deklofenak – 123RF

Einzelne Container auf einem Container- Host bereitzustellen, ist einfach. Die damit einhergehende Portabilität war ...

Weiterlesen
epaper-Einzelheft 8,99€
NEWS 14 Tage gratis testen
Bereits gekauft?Anmelden & Lesen
Leseprobe: Abdruck mit freundlicher Genehmigung von IT Administrator. Alle Rechte vorbehalten.

Mehr aus dieser Ausgabe

Titelbild der Ausgabe 11/2019 von Security auf einen Blick. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
Security auf einen Blick
Titelbild der Ausgabe 11/2019 von Mehr Schutz. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
Mehr Schutz
Titelbild der Ausgabe 11/2019 von Vier Server-Musketiere. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
Vier Server-Musketiere
Titelbild der Ausgabe 11/2019 von Vorausschauend. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
Vorausschauend
Titelbild der Ausgabe 11/2019 von Interview: »Schnelligkeit und Robustheit schließen sich nicht aus.«. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
Interview: »Schnelligkeit und Robustheit schließen sich nicht aus.«
Titelbild der Ausgabe 11/2019 von VMworld USA, San Francisco, 25. bis 29. August 2019: Alles auf Kubernetes!. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
VMworld USA, San Francisco, 25. bis 29. August 2019: Alles auf Kubernetes!
Vorheriger Artikel
Container mit LXC betreiben: Eingesperrte Prozesse
aus dieser Ausgabe
Nächster Artikel Anwendungs-Deployment mit Hashicorp Nomad: Auf Wanderschaft
aus dieser Ausgabe

... schließlich Hauptziel der Entwicklung von Docker. Container als Betriebsmodell für Microservice-basierte Anwendungen benötigen jedoch Orchestrierung. Docker allein kümmert sich in einem Verbund von Docker-Hosts nämlich nicht darum, wie einzelne Container in puncto Netzwerk und Storage zusammenarbeiten, wie sich mehrere Container zu einem Service verschnüren lassen oder wie sich feststellen lässt, ob im Verbund von Docker- Hosts noch Kapazitäten frei sind. Docker selbst kann nur Container starten und stoppen. Ein Cluster-Manager hingegen orchestriert nicht nur die Zusammenarbeit von Containern, auch die IP-, DNS- und Versionsverwaltung, das Lifecycle-Management oder das Monitoring gehören zu den Aufgaben des Cluster-Managers. Grundlagen von Kubernetes Kubernetes ist der populärste Cluster-Manager.

Allerdings ist Container-Orchestrierung nur ein möglicher Einsatzbereich von Kubernetes. Allgemein hilft Kubernetes dabei, Cloud-native Anwendungen einfacher bereitzustellen und hochverfügbar beziehungsweise skalierbar zu betreiben.

Die Vielseitigkeit von Kubernetes zeigt sich auch darin, dass Google Kubernetes als (Teil)-Projekt von “Google’s Infrastructure for Everyone Else” [1] betrachtet, denn ursprünglich wurde Kubernetes von Google allein entwickelt und basiert auf den Erfahrungen beim Betrieb von Containern mit dem eigenen Cluster- Management-System Borg.

Kubernetes ist die treibende Kraft hinter Platform-as-a-Service (PaaS), wie sich an populären Diensten wie OpenShift Online, AWS Beanstalk oder Google App Engine zeigt. Admins können derartige Angebote dank Kubernetes heute in zahllosen Varianten selbst implementieren, wahlweise auf eigener Hardware, in der Public Cloud oder in der privaten Wolke, zum Beispiel unter Open Stack.

Die Bausteine von Kubernetes

Die kleinste “adressierbare” Einheit in einem Kubernetes-Cluster (das, was Kubernetes eigentlich “orchestriert”) sind die Pods – Worker-Prozesse, die auf den sogenannten Worker-Nodes laufen. Jeder Pod besteht aus mindestens einem oder mehreren Containern, die sich eine Runtime und deren Ressourcen teilen. Die meisten Kubernetes-Implementierungen nutzen primär Docker als Container-Engine, verzichten aber so weit möglich auf die Docker-API oder spezifische Docker- Funktionen. Die Docker-API wird nur für einfache native Aufgaben benutzt, etwa das Starten von Containern. Ein Kubernetes-Cluster muss aber nicht mehr zwingend die Docker-Engine verwenden, weil Kubernetes zum Beispiel auch rkt von CoreOS unterstützt und die eigene Container-Engine cri-o [2] mitbringt.

Das Akronym setzt sich aus “CRI” und “OCI” zusammen, das heißt, der Fokus richtet sich hier auf OCI-kompatible Container und mit CRI wird Kubernetes Runtime-unabhängig. Red Hat hat cri-o gerade in diesen Tagen der Cloud Native Computing Foundation übergeben.

Der Kubernetes-Master

Kubernetes steuert den Cluster von einem dedizierten Host aus, dem Kubernetes- Master. Die Kommunikation zwischen diesem und den einzelnen Nodes erfolgt mit Hilfe sogenannter “Kubelets”, die auf den jeweiligen Nodes laufen. Meistens stellt der Master zudem mit etcd einen zentralen Key-/Value-Store als Datenbank für alle zur Verwaltung des Clusters erforderlichen Informationen bereit. Etcd dient also zum Speichern des Cluster-Zustands.

Allerdings ist etcd nicht komplett integriert, lässt sich also bei Bedarf durch eine externe Lösung wie zum Beispiel Consul [3] von Hashicorp ersetzen. Consul kann auch gleich das Service-Discovery übernehmen und sich mit den integrierten Healthchecks um die Lastverteilung kümmern. Der APIServer des Kubernetes-Masters greift über eine einfache HTTP-Schnittstelle beziehungsweise JSON-API auf die im KV-Store gespeicherten Informationen zu. Clientanfragen müssen bei Kubernetes also stets gegen den API-Server gerichtet sein. Dieser fungiert damit nicht nur als Verwaltungs- Hub für den Kubernetes-Master, sondern erleichtert auch die Kommunikation zwischen den übrigen Komponenten, was letztendlich der Aufrechterhaltung der Gesundheit des Clusters dient.

Bild 1: Eine detaillierter Blick auf die Architektur zeigt, dass bei Kubernetes etliche Komponenten ineinandergreifen.


Weitere nur vom Master bereitgestellte Komponenten sind der Scheduler, der neu erzeugte Pods einem Node zuweist, sowie der “Controller Manager”. Letzterer gewährleistet, dass der gewünschte Status des Clusters immer mit dem aktuellen Zustand übereinstimmt. Außerdem überwacht und steuert der Controller Manager den gesamten Cluster und alle Komponenten, um etwa ausgefallene Nodes jederzeit ersetzen zu können. Alle Bestandteile arbeiten zustandslos, mit Ausnahme des etcd-Stores. Der API-Server kann und sollte aus Gründen der Ausfallsicherheit redundant beziehungsweise verteilt betrieben werden. Google empfiehlt zur Sicherstellung von Quorum-Mehrheit eine ungerade Anzahl von drei, fünf, sieben oder neun Instanzen.

Die Worker-Nodes

Auf den Worker-Nodes laufen die in Pods zusammengefassten Einzel-Container sowie die Kubelets genannten Agenten, die die Kommunikation mit dem API-Server übernehmen. Der cAdvisor misst dabei den Verbrauch von CPU und RAM auf den Nodes und kommuniziert beides an den Master, damit der Scheduler bei Bedarf neue Pods auf die zur Verfügung stehenden Ressourcen verteilt. Das Besondere an Kubernetes ist, dass alle Komponenten beziehungsweise Instanzen selbst in Containern laufen, jeweils “gebootstrapped” von systemd, wobei als Fundament ein einfaches Container-Linux wie Red Hat Atomic oder CoreOS Container Linux Verwendung findet – nur, um Software als Container laufen zu lassen.

Das bringt den Vorteil mit sich, dass auf den Worker-Nodes keine Paket- oder Konfigurationsmanagement-Maßnahmen notwendig sind. Sie haben also einen merklich einfacheren Aufbau als die Master- Knoten. Das Kubelet nimmt Befehle des API-Servers entgegen, etwa um Container zu starten oder zu stoppen, und kommuniziert auf Seite des Worker- Nodes mit der jeweiligen Container-Runtime.

Optional richtet Kubernetes einen DNS-Server für den Cluster ein, der automatisch nach neuen Diensten sucht, um diese per Namensauflösung zu adressieren, was aber auch Consul tun kann.

Kubernetes einrichten

Trotz dieser Komplexität lässt sich ein Kubernetes-Cluster relativ einfach ausprobieren, sofern Sie dies in der Public Cloud machen, der am häufigsten anzutreffenden Deployment-Variante. Neben Google Kubernetes Engine (GKE) bieten auch AWS und Azure entsprechende Services an. AWS hat mit ECS, EKS und Fargate gleich drei Container-Cluster- Manager im Portfolio. Microsofts Kubernetes- Service hört auf den Namen Azure Kubernetes Service (AKS). Am einfachsten gelingt das Aufsetzen eines Kubernetes- Clusters derzeit mit der Google Kubernetes Engine.

Sämtliche Container in einem Pod laufen auf dem gleichen Worker-Node und teilen sich dessen Ressourcen wie Dateisysteme, Kernel-Namespaces oder IP-Adresse. Jeder Pod besteht im einfachsten Fall aus einem einzigen Image, zum Beispiel busybox [4]. Ein Manifest für einen Nginx- Pod könnte damit so aussehen: apiVersion: v1 kind: Pod metadata: name: nginx spec: containers: - name: nginx image: nginx:1.7.9 ports: - containerPort: 80

Für das Erzeugen der Pods-Basis des Manifests kann dann das kubectl-Tool zum Einsatz kommen: kubectl create -f nginx.yaml

In größeren Setups werden Pods in “Replicasets” beziehungsweise in “Deployments” eingebettet, um Skalierbarkeit und Ausfallsicherheit zu gewährleisten. Deployments bestehen dann aus je einer Gruppe von Pods.

Das abgebildete Nginx-Beispiel startet drei Pods, wobei ein Replica-Set sicherstellt, dass auch immer drei Pods laufen. Terminiert der Nutzer einen Pod zum Beispiel mitubectl pods delete , wird dieser unmittelbar ersetzt. In GKE lässt sich das Nginx- Deployment mit wenigen Klicks erstellen.

Nach der Auswahl des Basis-Containers (“nginx:latest”) richten Sie das Deployment im Abschnitt “Konfiguration(2)” weiter ein. Hier erwartet der Dialog zu- nächst den Namen der neuen Anwendung (“nginx-1”) und eine Benennung für den Namespace (“default”). Außerdem spielen in Kubernetes Labels eine wichtige Rolle – Key-/Value-Paare, denen sich Objekte anheften lassen. Sie helfen beim Suchen oder Aktualisieren mehrerer Objekte, die dann als ein Single-Set behandelt werden. Nach Auswahl des Ziel-Clusters bei “Cluster” rollen Sie das Deployment mit einem Klick auf “Bereitstellen” aus. Ist alles erledigt, genügt ein weiterer Klick auf “Bereitstellen” und nach wenigen Sekunden sind drei Pods im Menü “Arbeitslasten” des GKE-Dashboards sichtbar.

Bild 2: Fertig – so sieht in GKE ein durchgelaufenes App-Deployment mit drei Pods aus.


Services verwalten

Services sind in Kubernetes per Namen adressierbare Endpunkte, die Sie mit Hilfe der erwähnten Label-Selektoren an die Pods anschließen, wobei Service-Anfragen zur Lastverteilung automatisch zwischen Pods rotieren. Der Service verbindet also den eigentlichen Pod bei Bedarf mit der Außenwelt. Konkret holt der Service die Pods auf dem Target-Port des mit Hilfe des Selectors gelabelten Nodes ab und erzeugt dann einen zufälligen Port auf dem Node, der als Endpunkt für das Loadbalancing dient. Ein Service ist also eine Abstraktion, die eine logische Gruppe von Pods definiert, die irgendwo im Cluster laufen und dieselbe Funktionalität bieten.

Jeder Service erhält beim Erstellen eine eindeutige IP-Adresse, die bei Kubernetes “Cluster IP” heißt und an die Lebensdauer des Dienstes gebunden ist, sich also im Verlauf der Lebensdauer des Diensts nicht ändert. Pods lassen sich damit jederzeit so konfigurieren, dass sie mit dem Service kommunizieren. Dabei wird die Kommunikation mit dem Service automatisch an einen Pod weitergeleitet, der Mitglied des Diensts ist. Auch das Einrichten eines Services mit zwei Nginx- Replicas kann via kubectl, etwa mitkubectl expose, erfolgen: kubectl expose deployment/my-nginx

Im Fall der Google Kubernetes Engine können Sie das Ganze auch wieder komfortabel in der Managementkonsole erledigen.

Hier kümmert sich GKE automatisch darum, dass diese Information bei Kubernetes erfragt und der richtige Endpunkt eingetragen wird. Das Service- Discovery findet sich im GKE-Dashboard im Abschnitt “Dienste und Ingress”. Das Veröffentlichen, also das Einrichten von Diensten und das Binden an Pods, passiert im GKE-Dashboard im Menü “Arbeitslasten”. Hier öffnen Sie das bereitgestellte Deployment und klicken dann rechts oben auf “Freigeben”. Dabei bedarf es mindestens der Angabe eines Quellund Ziel-Ports (optional), des Protokolls (TCP) und des Diensttyps, zum Beispiel mit Loadbalancer. Danach klicken Sie erneut auf die Schaltfläche “Freigeben”.

Anschließend taucht der neue Dienst auch im Menü “Dienste und Ingress” auf. Dem veröffentlichten Endpunkt (“Externe Endpunkte”) können Sie in der GUI dann einfach per Mausklick folgen

Loadbalancing, Netzwerk und Storage

Kubernetes stellt Ausfallsicherheit dadurch sicher, dass es Pods auf unterschiedliche Knoten verteilt. Dazu erkennt ein Loadbalancer Pods mit Schwierigkeiten und verteilt die Anfragen auf die gesunden Nodes. Der Loadbalancer selbst ist dabei ein spezieller Service. Da in Kubernetes jede Anwendungsstufe in Form eines Pods definiert ist, kann jede Stufe auch für sich skalieren, wahlweise manuell oder automatisiert.

Der Deployment-Controller von Kubernetes unterstützt Rolling-Update- oder Recreation-Strategien. Rolling-Update bedeutet, dass der Admin entweder die maximale Anzahl von Pods angibt, die nicht verfügbar sind, oder die maximale Anzahl an Pods, die im Verlauf des Up-dateprozesses noch laufen. Ändern Sie zum Beispiel nachträglich die Versionsnummer des Images, führt Kubernetes unmittelbar ein Rolling-Update durch und erzeugt automatisch ein neues Replica-Set.

Das logische Netzwerkmodell von Kubernetes ist flach, das heißt, sämtliche Pods können theoretisch miteinander kommunizieren, wobei Sie mit Hilfe von Netzwerkrichtlinien angeben können, wie sie das tun. Die logische Netzwerkab straktion in Form eines Overlay-Netzwerks benötigt immer zwei CIDR-Ranges. Aus der einen erhalten die Pods eine IP-Adresse und aus der anderen die Dienste. Sie können das logische Networking für Kubernetes aber auch mit Hilfe von Calico [5] und Netzwerk- Policies implementieren. Damit ist es dann möglich, Kubernetes-Pods und Services so zu isolieren, dass Netzwerk- Policies wie Firewallregeln auf Basis von Kubernetes-Namespaces und -Labeln wirken. Da Kubernetes weitgehend standardisiert ist, lassen sich zustandslose Apps relativ problemlos bereitstellen, egal wo Sie den eigentlichen Cluster betreiben.

Bild 3: Das Freigeben eines Deployments bedarf in GKE nur weniger Mausklicks.


Aufwendiger gestaltet es sich, wenn Anwendungen auch Daten speichern. Kubernetes bietet zwei Storage-APIs. Die eine stellt eine Abstraktionsebene für diverse individuelle Storage-Backends wie NFS, Ceph, AWS EBS oder Flocker bereit, die andere eine Abstraktion für Speicheranfragen, die dann durch unterschiedliche Speicher-Backends bedient werden. Ändert sich eine Speicherressource, die vom Docker-Daemon auf einem Node verwendet wird, müssen Sie den Knoten vorübergehend aus dem Cluster entfernen.

Kubernetes bietet mehrere Arten persistenter Volumes auf Block- oder Datei- Ebene, wie beispielsweise iSCSI, NFS, FC, AWSs, Google Cloud Platform und Microsoft Azure. Ferner gibt es ein nicht persistentes Volume namens “emptyDir”.

Docker Swarm

Die Cluster-Orchestrierung von Docker gibt es in drei Varianten, “Docker (native) Swarm”, “Swarmkit” und “Docker Swarm Mode”, wobei nur Letztere noch von Bedeutung ist. Docker Swarm native (initial vorgestellt mit Docker 1.6) geht noch auf die Docker-Anfänge im Jahr 2014 zurück.

Diese Version ist im Gegensatz zum Swarm-Mode (ab 1.12) nicht fest in die Docker-Engine integriert, sondern arbeitet in Form der Swarm Binary eigenständig.

Beim nativen Docker Swarm verbindet der Swarm-Modus die einzelnen Docker-Hosts zu einem Cluster und unterstützt externe KV-Stores (etcd oder Consul), sehr komplexe Filter für die Container-Ersetzung und integriert sich dank der gleichen Docker-API recht problemlos in ThirdParty-Tools.

Das Swarmkit aus 2016 ist ein eigenständiges Tool, das Docker noch kurz vor dem Docker-Release 1.12 veröffentlicht hatte. Das Swarmkit stellt allgemein Funktionen für das Ausführen eines Clusters sowie die Aufgabenverteilung an die Cluster-Knoten zur Verfügung und bildet auch die Grundlage des in Docker 1.12 enthaltenen Swarm- Mode. Die “Inspiration” zu Swarmkit und Teile des Konzepts gehen auf die Übernahme von SocketPlane im Jahr 2015 zurück. Der Swarm-Mode gilt seit Docker 1.2 als offiziell von Docker empfohlener Weg.

Swarm-Mode unter der Haube

Die Konzepte von Docker Swarm ähneln zwar denen von Kubernetes, funktionieren im Detail aber doch anders. Ein Knoten in Docker-Swarm ist die Instanz eines Schwarms. Unter einem Schwarm versteht Docker eine Gruppe von Knoten beziehungsweise Docker-Engines. In einem Swarm-Cluster orchestrieren Sie allerdings nicht das Ausführen von Container-Befehlen, sondern nur die Dienste selbst.

Dabei erhalten Manager-Knoten die konfigurierten Service-Definitionen und versenden Workloads an Worker-Knoten. Worker-Knoten wiederum sammeln und führen Aufgaben (Tasks) von Manager- Knoten aus. Tasks sind hier spezielle Container mit servicespezifischen Eigenschaften und bilden in einem Swarm-Cluster die kleinste mögliche Einheit. Der Task dient als Verbindungskomponente zwischen Containern und Schwarm.

Tasks sind notwendig, weil ein gewöhnlicher Container Prozesse kapselt und im Grunde keine Ahnung von der Service- Abstraktion von Docker Swarm hat. Ein Schwarm besteht aus mehreren Docker- Hosts, die im Schwarm-Modus ausgeführt werden. Hierbei kann ein Knoten wahlweise die Rolle “Manager” (Verwalten der Mitgliedschaft und Delegierung) oder “Worker” (Schwarmdienste ausführen) oder gegebenenfalls auch beide übernehmen. Erstellen Sie unter Docker Swarm einen Service, können Sie optional den gewünschten Status festlegen, etwa die Anzahl der Replicas, die verfügbaren Netzwerk- und Speicherressourcen oder die Ports, über die der Dienst für die Außenwelt erreichbar ist. Im Swarm-Modus versucht Docker stets, den gewünschten Zustand aufrechtzuerhalten. Fällt ein Worker aus, verteilt der Manager die Aufgaben dieses Knotens auf andere Knoten. Der Task selbst ist ebenfalls nur ein Container, der als Teil eines Swarm-Services fungiert und von einem Swarm-Manager verwaltet wird, im Gegensatz zu einem gewöhnlichen Docker-Container, der nicht vom Swarm-Manager kontrolliert wird.

Der Vorteil von Swarm-Services oder -Tasks im Vergleich zu Standalone-Containern besteht darin, dass Nutzer die Konfiguration eines Diensts jederzeit ändern können, einschließlich der Netzwerke und Volumes, ohne dass der Dienst neu starten muss. Der Swarm Manager aktualisiert in diesem Fall lediglich die Konfiguration, stoppt die Service-Tasks mit der veralteten Konfiguration und erstellt neue Tasks mit der gewünschten Konfiguration.

Läuft Docker also im Schwarm-Modus, können Nutzer neben Swarm-Diensten weiterhin auch Standalone-Container auf jedem Docker-Host ausführen, der Teil des Schwarms ist (Worker oder Manager).

Der Unterschied zwischen Standalone- Containern und Schwarm-Diensten ist, dass nur Swarm-Manager einen Swarm verwalten können, während sich Standalone- Container auf jedem Docker-Daemon starten lassen. Insofern ist der Docker- Swarm eigentlich nur eine Art Betriebsmodus für die Docker-Engine.

Bild 4: Die Architektur von Docker Swarm im Überblick.


Im Swarm-Modus werden Dienste im Gegensatz zu Standalone-Containern ähnlich wie bei Kubernetes deklarativ spezifiziert.

Wie erwähnt können Sie einen Dienst aber falls gewünscht so konfigurieren, dass er auf mehreren Knoten repliziert wird. Auch im replizierten Service-Modell kommt eingehendes Loadbalancing zum Einsatz, wobei der interne DNS für das Bereitstellen hochverfügbarer Dienst-Endpunkte sorgt.

Bereitstellen von Anwendungen

Am deutlichsten zeigen sich die Unterschiede zu Kubernetes bei der Anwendungsbereitstellung. Die Möglichkeiten dazu sind unter Kubernetes vielfältig, basieren aber alle auf einer Kombination aus Pods, Deployments und Services, wobei Pods als Gruppe von (co-platzierten) Containern die atomare Einheit für die App-Bereitstellung bilden, ein Deployment aber auch Repliken über mehrere Knoten haben kann. Nach außen treten die durch Kubernetes bereitgestellten Workloads als Services in Erscheinung.

Docker Swarm hingegen betreibt Anwendungen als Dienste in einem Swarm-Cluster. Während ein Task die auf exakt einem Knoten beschränkte Instanziierung eines Dienstes darstellt, können Dienste mit Hilfe von Labels auch über mehrere Rechenzentren verteilt werden.

Hochverfügbarkeit, Autoscaling und Netzwerk

Da der Swarm-Manager für das Verwalten der Ressourcen aller Worker-Knoten verantwortlich ist und sich Dienste über sämtliche Swarm-Knoten replizieren lassen, stellt Docker Swarm Dienste immer lastausgeglichen nach außen bereit. Im Gegensatz zu Kubernetes besitzt Docker Swarm eine fest eingebaute DNS-Komponente, die eingehende Requests auf die entsprechenden Services verteilt. Services werden dabei entweder an vom Nutzer spezifizierte Ports gebunden oder wählen den zu verwendenden Port automatisch.

Auch bei der Skalierung von Anwendungen unterscheiden sich Kubernetes und Docker Swarm. Da bei Kubernetes jede Anwendungsstufe in Form eines Pods definiert ist, kann sie skalieren, sofern sie von einem “Deployment” verwaltet wird. Bei Swarm kümmert sich Docker Compose um die Skalierung, wobei Dienste wahlweise global oder repliziert sein können. Globale Dienste laufen dann immer auf allen Knoten, während replizierte Dienste nur Repliken der Dienste auf dem jeweiligen Knoten ausführen.

Im Schwarm-Modus erstellt jeder Node, der einem Docker-Swarm-Cluster beitritt, ein Overlay-Netzwerk für Dienste, das alle Hosts im Schwarm umfasst, sowie ein Host-Only-Docker-Bridge-Netzwerk für Container. Per Default verschlüsseln die Knoten im Swarm-Cluster Overlay-Control- und Management- Traffic untereinander via TLS. Benutzer hingegen können sich entscheiden, Container- Datenverkehr zu verschlüsseln, wenn sie ein Overlay-Netzwerk selbst erstellen. Die Docker-Engine und Docker Swarm unterstützen das Mounten von Volumes in einen Container hinein. Als gemeinsame Dateisysteme kommen NFS, iSCSI und Fibre Channel in Frage. Zusätzlich gibt es Plug-ins für Azure, Google Cloud Platform, NetApp, Dell EMC und andere.

Fazit

Kubernetes ist heute das am weitesten verbreitete Orchestrierungswerkzeug für Container-Cluster. Solange Google Hauptsponsor ist und Kubernetes auch intern nutzt, wird es seine Rolle langfristig noch festigen. Im Vergleich mit einem Docker-Swarm-Setup sind an Kubernetes deutlich mehr Komponenten beteiligt, was aber auch daran liegt, dass DNSServer oder KV-Store nicht vollständig integriert sind.

Zudem müssen Sie bei Kubernetes entsprechende Network-Overlay-Technologien explizit einbinden, etwa Calico, Weave oder Flannel, die dann Kommunikation zwischen den Pods erlauben. Docker Swarm lässt sich im direkten Vergleich deutlich stressfreier einrichten und konfigurieren, versteht aber nur Docker und bietet daher insgesamt weniger Flexibilität und Spielraum bei der Gestaltung des Clusters und damit indirekt beim Betrieb von Anwendungen. In Teil zwei widmen wir uns den AWS Container-Services und Apache Mesos.(ln)

Link-Code

[1] Google Infrastructure for Everyone Else jaz11
[2] Container-Engine cri-o jaz12
[3] Hashicorp Consul jaz13
[4] busybox.yaml auf GitHub jaz14
[5] Virtuelle logische Netzwerke mit Calico, IT-Administrator 09/2017 jaz15