Container Orchestration Tools im Vergleich

Die Konsolidierung der Cloud Container Orchestration Tools im Vergleich

31.12.2019Autor / 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-Clusters nebst zugehöriger Verwaltungsinstrumente wie Google Kubernetes. Hier klären wir die Zusammenhänge von Containern, Docker, DevOps und Cloud-native Computing.

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 Googles Interpretation von Cloud Consolidation. Inzwischen lässt sich PaaS auch dank Kubernetes in zahllosen Varianten betrieben: zwischen eigener Hardware und Google Cloud Engine bzw. AWS, Azure oder den anderen Public-Cloud-Anbietern sowie in privaten Clouds wie Open Stack.

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 bekanntlich 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-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 Hostsystem 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 oder Virtuozzo, bzw. 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 z. B. 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 Orchestrierungslösung her muss.

Docker allein beantwortet nun einmal nicht die Fragen, wie Container z. B. in puncto Netzwerk und Storage zusammenarbeiten oder im Verbund z. B. 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.