Suchen

Die Konsolidierung per Cloud-Computing Container Orchestration Tools im Vergleich

Autor / Redakteur: Dipl. -Ing. Thomas Drilling / Stephan Augsten

Seit „Docker“ das Licht der IT-Welt erblickte, haben Container die DevOps-Idee revolutioniert. Dazu bedarf es eines Container-Cluster nebst zugehöriger Verwaltungsinstrumente wie „Kubernetes“. Wie stehen Container, Docker, DevOps und Cloud-native Computing in Zusammenhang.

Firmen zum Thema

Mit wachsender Anzahl der zu verwaltenden Container muss auch unter Docker eine Orchestrierungslösung her.
Mit wachsender Anzahl der zu verwaltenden Container muss auch unter Docker eine Orchestrierungslösung her.
(Collage: © Francesco Italia / Marina Ignatova - stock.adobe.com)

Kubernetes war und ist die treibende Kraft hinter Platform-as-a-Service (PaaS) und damit quasi die Google-Interpretation von Cloud Consolidation. Inzwischen lässt sich PaaS auch dank Kubernetes in zahllosen Varianten betrieben: zwischen eigener Hardware und Google Cloud Engine beziehungsweise AWS, Azure oder den anderen Public-Cloud-Anbietern sowie in privaten Clouds wie OpenStack.

Sogar Entwickler der konkurrierenden Projekte einschließlich Docker tragen heute zu Kubernetes bei. Die Github-Seite des Kubernetes-Projekts meldete Mitte 2019 fast 2.100 Beitragende mit über 77.000 Commits. Stetig agiler werdende Anforderungen an Development und Operations treiben die Use Cases für DevOps mit Container-Clustern und damit auch Kubernetes voran.

Das Wesen des Containers

Wer über DevOps auf Basis von Microservices und Container-Clustern spricht, muss wissen, was Container sind, vor allem in ihrer Abgrenzung zu virtuellen Maschinen. Letztere bringen ein komplett eigenes Betriebssystem mit, welches auf Basis virtueller Hardware installiert wird und VMs im Vergleich zu Containern relativ groß und behäbig macht.

Im Vergleich startet eine neue VM je nach Größe binnen Minuten, während die Startzeit von Containern im unteren Sekundenbereich oder sogar darunter angesiedelt ist. Trotzdem versprechen und bieten beide Konzepte Portabilität – keine Abhängigkeit von der Hardware oder vom Betriebssystem des Hypervisors oder Container-Hosts – und Isolation.

Aus Sicht des Betriebssystems des Container-Hosts ist der Container dabei lediglich ein Prozess in der Prozess-Hierarchie des Container-Host-OS (Linux), allerdings auf Namespaces beschränkt. Innerhalb eines Namespaces verfügt jeder Prozess über eine andere Prozess-ID und verwendet eigene Netzwerkrouten, Control Group Limits oder DNS-Einstellungen. Somit ist gewährleistet, dass Prozesse, die einen Namespace teilen – also die gesamte Prozess-Hierarchie innerhalb eines Namespaces/Containers –, auch die vorhandenen Ressourcen teilen.

eBook „Container-Orchestrierung“

Container-OrchestrierungContainer-Orchestrierung gewinnt in den letzten Jahren im DevOps-Bereich an Bedeutung. Dieses eBook behandelt die wichtigsten Fragen rund um das Thema und stellt einige Anbieter in einen Vergleich miteinander.(PDF | ET 31.10.2019)


eBook herunterladen »

Trotzdem bleiben sie von anderen Container-Prozessen und dem Host-System selbst isoliert. Die für Server- und App-Konsolidierung geforderte und bei einer virtuellen Maschine durch den Hypervisor samt virtueller Hardware prinzipiell gegebene Customer-Segregation wird bei Containern also durch die geschickte Nutzung der Linux-Kernel-Features Namespaces, cgroups und capabilities gewährleistet.

Container und Docker

Wenngleich Container in der Linux- und Provider-Welt seit langem bekannt sind und auch benutzt werden – bekannte Vertreter sind/waren „OpenVZ“und „Virtuozzo“ oder das erst ab 2008 entstandene „Linux Containers“ (LXC) –, hat sich Container-Virtualisierung erst mit dem Erscheinen von Docker flächendeckend durchgesetzt.

Das gilt vor allem deshalb, weil Docker zum Beispiel im DevOps-Umfeld, in dem sich Administratoren zwangsläufig mit unterschiedlichen Laufzeitumgebungen, Configuration-Management-Werkzeugen, Paketformaten und Deployment-Strategien auseinandersetzen müssen, für einheitliche Standards sorgt. Hauptidee von Docker war und ist, sämtliche zum Bauen, Transportieren und Starten von Containern erforderlichen Werkzeuge in einen einzigen CLI-Befehl zu integrieren. Diese Art von Standardisierung hat sicher zur einfachen Verwendbarkeit von Docker und damit zur flächendeckenden Verbreitung beigetragen.

Container-Images und Docker Hub

Eine weitere Besonderheit von Docker und maßgeblich mit für die schnelle Verbreitung verantwortlich ist das Konzept der Docker-Images. Docker hat dazu ein CoW-Dateisystem (Copy on Write) – quasi ein Snapshot-Verfahren – implementiert, welches Images in Schichten organisiert, wobei jeweils nur im obersten Layer, also der Instanziierung eines Images in Form des Containers Schreibrechte bestehen.

Das Prinzip erlaubt, dass immer nur eine überschaubare Anzahl relativ großer Basis-Images durch differenzielle Unterschiede der eigentlichen App-Images verändert wird. Für das CoW-Dateisystem kommt bei Docker das Linux AuFS (Another Union File System) zum Einsatz, bei dem Images in der beschriebenen Weise übereinander geschichtet werden.

Ebenfalls maßgeblich am Erfolg von Docker beteiligt ist der Docker Hub, ein öffentliches Repository für Docker-Images, das allerdings wegen der anfangs noch recht dürftigen Sicherheits- und Authentizitäts-Mechanismen auch in der Kritik stand.

Andere Laufzeitumgebungen für Container

Das Container-Prinzip wie es Docker umsetzt – also ein einziges, mittels Root-Rechten auszuführendes Kommando, das sämtliche Container-Operationen erschließt –, widerspricht eigentlich dem Unix-Prinzip „Ein Kommando für genau eine Aufgabe“. Dieser Umstand und andere Uneinigkeiten zwischen Docker und den am Docker-Ökosystem beteiligten Partnern haben in der Vergangenheit zur Entwicklung alternativer Container Runtimes sowie zur weiteren Modularisierung von Docker und zur Bildung der Open Container Initiative (OCI) geführt.

Die bekannteste alternative Doc-Runtime ist „Rkt“ von CoreOS. Zudem hat das Kubernetes-Projekt mit „cri-o“ eine eigene Runtime im Rennen, die perfekt mit dem Container Runtime Interface harmoniert, einem Standard zum Starten von Containern durch Container-Orchestrierungsumgebungen. Nicht zuletzt initiierte auch Intel mit „Clearcontainers“ eine Container Runtime, die den Container-Prozess selbst mit Hilfe eines auf Basis von „Qemu“-KVM implementierten Hypervisors isoliert und so für mehr Sicherheit sorgt. Ähnlich macht es auch VMware mit „vSphere Integrated Containers“.

Schließlich steuert seit Ende letzten Jahres auch Red Hat mit der „Openshift Container Engine“ eine quasi eigene Container Engine bei. Die OpenShift Container Engine ist eine minimale Konfiguration der Openshift Container Platform. Sowohl Engine als auch Platform basieren auf der gleichen Unternehmensplattform von Kubernetes und enthalten wichtige Linux-, Containerlaufzeit-, Netzwerk-, Management- und Sicherheitsfunktionen. Während Engine und Platform grundsätzlich dasselbe Produkt sind, haben Benutzer von Openshift Container Platform Zugriff auf ein größeres Spektrum an Funktionen – einschließlich erweiterter Netzwerk-, Management- und DevOps-Services.

DevOps und Container-Orchestrierung

Das Ausführen einzelner Container auf einem beliebigen Container-Host und die damit verbundene Portabilität ist das Eine. Schließlich war es das Ziel des Docker-Projekts – laut des legendären Zitats von Docker-Gründer Solomon Hykes „Shipping code to servers is hard“ –, das Bereitstellen komplexer Applikation zu vereinfachen. Seit sich Container als Standard in Service-orientierten Architekturen und DevOps-Szenarien etabliert haben, war aber auch absehbar, dass mit wachsender Anzahl der zu verwaltenden Container eine Orchestrierung her muss.

Docker allein beantwortet nun einmal nicht die Fragen, wie Container zum Beispiel in puncto Netzwerk und Storage zusammenarbeiten oder im Verbund, etwa hinter einen Load Balancer, betrieben werden können oder wie man eine automatische Skalierung konfiguriert. Docker kann zwar Container starten und stoppen, aber nur ein echter Cluster-Manager orchestriert die Zusammenarbeit von Containern, etwa dass und wie sich Container Ressourcen auf dem gleichen Container-Host teilen, wie sie lokalen oder netzwerkverbundenen persistenten Speicher nutzen oder wie vorhandene Load Balancer mit IP-Adressen von Containern zu verbinden sind.

Auch eine einheitliche IP- und DNS-Verwaltung fällt in den Aufgabenbereich des Cluster-Managers, ebenso wie Versionsverwaltung, Lifecycle-Management oder Monitoring. Docker ist also ohne Zweifel ein hervorragendes Open-Source-Tool, die Docker-Engine allein (ohne „Swarm“) kann sich aber nicht um Clustering und komplexe Anwendungsbereitstellungen kümmern, denn für das Clustering müssen nicht nur ordnungsgemäße Installationsarbeiten durchgeführt werden, die Ressourcen müssen je nach Anforderungen auch skalierbar sein.

eBook „Container-Orchestrierung“

Container-OrchestrierungContainer-Orchestrierung gewinnt in den letzten Jahren im DevOps-Bereich an Bedeutung. Dieses eBook behandelt die wichtigsten Fragen rund um das Thema und stellt einige Anbieter in einen Vergleich miteinander.(PDF | ET 31.10.2019)


eBook herunterladen »

Auf der folgenden Seite finden Sie Kurzabrisse zu den populärsten Tools und Services für Container-Clustering und Orchestrierung: Kubernetes, Docker Swarm und Apache Mesos. Unser eBook „Container-Orchestrierung“ widmet sich den einzelnen Vertretern auch noch einmal im Detail.

Apache Mesos

„Mesos “ist ein Cluster-Management-Tool, das ursprünglich für Twitter und dessen Infrastruktur entwickelt und dann unter eine Apache Open-Source-Lizenz gestellt wurde. Mesos wird heute von bekannten Unternehmen wie eBay und Airbnb verwendet. Allerdings ist Apache Mesos kein spezielles oder dediziertes Werkzeug zur Container-Orchestrierung.

Mesos lässt sich allgemein für das Clustering von VMs, Containern oder physischen Maschinen verwenden, kommt aber vorrangig beim Betrieb von Clustern für das Ausführen von Big-Data-Workloads zum Einsatz. Allerdings verfügt Mesos über ein sehr effizientes Framework mit der Bezeichnung „Marathon“, das unter anderem auch das Bereitstellen und Verwalten von Containern in einem Mesos-Cluster erlaubt, so dass man beispielsweise einen Kubernetes-Cluster auf einem Mesos-Cluster ausführen kann.

Google Kubernetes

Kubernetes ist ein Open-Source-Cluster-Manager. Er wurde ursprünglich von Google entwickelt, später aber der ebenfalls von Google initiierten Cloud Native Computing Foundation übergeben. Allgemein kann Kubernetes für ein automatisches Bereitstellen und für die Skalierung von Container-Anwendungen verwendet werden, wobei Kubernetes stets mehrere Container in logische Teile zusammenfasst, was die Verwaltung und die Übersicht vereinfacht.

Kubernetes besitzt einen hervorragenden Scheduler und Ressourcen-Manager. Dieser erlaubt es, Container auf effiziente und hochverfügbare Weise bereitzustellen. Kubernetes ist für viele Organisationen heute das Defacto-Container-Orchestrierungswerkzeug. Häufig wird Kubernetes als Konkurrenzprodukt zum nativen Container-Cluster-Manager des Docker-Projektes angesehen (Docker Swarm). Dabei wird oft übersehen, dass es Kubernetes etwas länger gibt als Docker Swarm.

So bot Kubernetes in der Anfangszeit der Container-Orchestrierung Lösungen für viele Probleme, die Docker selbst seinerzeit noch nicht bedienen konnte. Nur mit Kubernetes war es seinerzeit möglich, Container ohne Datenverlust zu bewegen, Netzwerke zwischen Containern zu erstellen oder einen Load Balancer zu verwenden. Generell ist es aber verhältnismäßig einfach, mit Kubernetes zu starten, wenn man zum Beispiel „Google Kubernetes Engine“ (GKE) in der Cloud nutzt.

Diese Vorteile erkauft man sich jedoch mit dem Nachteil, dass Kubernetes einen komplizierteren Ansatz verfolgt als Docker mit komplett anderer CLI, anderen APIs und eigenen YAML-Definitionen. Daher ist es mit Kubernetes nicht möglich, das Docker CLI oder Docker Compose für die Container-Definition zu verwenden. Wer das Konzept von Kubernetes verstehen will, muss dieses und das Zusammenarbeiten der einzelnen Komponenten vom Prinzip her durchdringen. So besteht ein Kubernetes-Cluster aus einem Master Node und mehreren Worker Nodes.

eBook „Container-Orchestrierung“

Container-OrchestrierungContainer-Orchestrierung gewinnt in den letzten Jahren im DevOps-Bereich an Bedeutung. Dieses eBook behandelt die wichtigsten Fragen rund um das Thema und stellt einige Anbieter in einen Vergleich miteinander.(PDF | ET 31.10.2019)


eBook herunterladen »

Der Master Node ist die Kontrollzentrale, von der aus die Container verwaltet werden. In Produktiv-Setups hat man aus Gründen der Ausfallsicherheit meist mehrere Master. Die Kommunikation mit dem Master erfolgt über ein Control-Layer via REST-API mit umfangreichen Funktionen. Der Master Node enthält weitere wichtige Komponenten wie KV-Store (z. B. etcd), Controller-Manager, Scheduler und Kubelet, wobei Kubelet und etcd direkt mit dem API-Server kommunizieren.

Den „etcd“-Layer kann man sich als eine Art Datenbank vorstellen, in der die Konfigurationen der einzelnen Cluster gespeichert sind. Kubelet ist eine Verwaltungsinstanz für die Pods, die auf den Hosts laufen. Der Scheduler sorgt dafür, dass Container auf den richtigen Systemen innerhalb eines Clusters landen. Dazu entscheidet er eigenständig über die Verteilung der Pods abhängig vom Workload. Der Controller-Manager überwacht die von der API ausgehenden Prozesse und platziert Workloads auf den Nodes.

Docker Swarm

Das stetig wachsende Docker-Ökosystem umfasst inzwischen Werkzeuge von der Entwicklung bis zur Bereitstellung von Produktionssystemen. Darin fügt sich seit einiger Zeit auch Docker Swarm für die Cluster-Verwaltung ein. So kann der Nutzer eine Komposition aus Docker-Compose-, Swarm- und Overlay-Netzwerk und einem guten Service-Discovery-Tool wie „etcd“ oder „consul“ ebenfalls zum Verwalten eines Clusters von Docker-Containern verwenden.

Im Vergleich zu den etablierten Open Source-Container-Cluster-Management-Tools befindet sich Docker Swarm immer noch in einem Reifeprozess in Bezug auf die vorhandenen und noch geplanten Funktionalitäten. Da das Docker-Projekt aber über ausreichend Manpower verfügt, wird es wohl nicht mehr lange dauern, bis Docker Swarm zu den anderen Lösungen aufschließt oder sie gar überflügelt.

Container in der Cloud

Sehr populär sind zunehmend auch der Betrieb und das Management von Container-Clustern in der Cloud. Allein AWS bietet hier mit „ECS, EKS“ und „Fargate“ gleich drei Services an, wobei auch hier im Falle von EKS Kubernetes mit im Spiel ist – genau wie bei Googles Cloud Kubernetes Engine (CKE), was kaum überrascht. Ebenfalls von Bedeutung sind in dieser Kategorie „Azure Kubernetes Service (AKS)“ oder „Red Hat Openshift Online“.

Doch auch wer Openshift Enterprise oder „Origin“ in der eigenen Private Cloud einsetzt, kommt an Kubernetes kaum vorbei. Was Container-Cluster in der Cloud angeht, soll auch der Kubernetes-Service von Digital Ocean nicht unerwähnt bleiben. Mit diesem Service bietet Digital Ocean einen verwalteten Kubernetes-Dienst für die Bereitstellung von Container-basierten Anwendungen an.

Fazit

Kubernetes ist vorrangig auf Skalierbarkeit, Verfügbarkeit und Sicherheit in sehr großen Clustern ausgelegt. Hier stehen vor allem Zuverlässigkeit und Flexibilität im Vordergrund. Zudem bietet Kubernetes maximale Freiheit bei der Wahl des Betriebssystems. Bei komplexen Anwendungen in einem großem bis sehr großen Maßstab hat Kubernetes damit die Nase vorn vor Docker Swarm. Den Vorteil erkauft man sich mit der Komplexität bei Aufbau und Wartung eines Clusters über eine komplett eigene API.

In mittleren bis kleineren Cluster-Umgebungen punktet Docker Swarm durch die einfache Verwendbarkeit und die native Unterstützung aller Docker-Befehle. Darüber hinaus kann Kubernetes auch unter anderen Blickwinkeln betrachtet und für andere Aufgaben eingesetzt werden. Eigentlich konkurrieren die drei Lösungen überhaupt nicht miteinander, da sie jeweils auf komplett anderen Abstraktionsebenen arbeiten und damit völlig unterschiedliche Zielgruppen adressieren.

Dieser Beitrag stammt aus dem eBook „Container-Orchestrierung“.

Artikelfiles und Artikellinks

(ID:46299267)

Über den Autor

Dipl. -Ing. Thomas Drilling

Dipl. -Ing. Thomas Drilling

IT-Consultant, Trainer, Freier Journalist