Kubernetes und Docker – zwei Synonyme für die Erstellung und den Betrieb von Microservices und Containern. So stark, wie diese beiden Begriffe für eine neue Technologie stehen, so häufig hat man sie in den Anfangszeiten der Container-Nutzung gemeinsam gesehen: Docker macht Container, Kubernetes den Betrieb der Docker-Hosts. Doch diese Zeiten sind (eigentlich schon länger) vorbei. Kubernetes hat die Unterstützung von Docker als „deprecated“ markiert und will sie in den nächsten Jahren komplett einstellen. Woran liegt das? Und was bedeutet das für meine Container-Umgebungen?
Zunächst ein kleiner Hinweis zu den Begrifflichkeiten: Wenn wir von Containern in Form einer „Lösung“, „Umgebung“ oder „Runtime“ sprechen, ist damit das Stück Software gemeint, das die Container auf den (physischen oder virtuellen) Servern ausführt. Die Orchestrierung (in diesem Fall Kubernetes) verteilt Aufgaben auf die Container-Lösungen und sagt den einzelnen Servern, welche Container gestartet werden.
Docker – der Vorreiter bei Containern
Docker war eine der ersten Container-Lösungen, die sich auf die Zielgruppe Entwickler konzentriert hat. Es wurde ein gut beherrschbares Toolset entwickelt, mit dem man Anwendungen inkl. aller Abhängigkeiten aber ohne das Betriebssystem bereitstellt. Hierzu wurden einige Design-Entscheidungen getroffen, die im Nachhinein nicht optimal, doch aus der damaligen Sicht durchaus nachvollziehbar waren. Dazu gehört vor allem anderen die Nutzung eines eigenen Dienstes (unter Linux: Daemon), um die Container zu verwalten. Dieser wird mit Kommandozeilenwerkzeugen gesteuert. Dadurch ergeben sich allerdings einige Sicherheitsimplikationen, weil dieser Daemon als root-User (also dem „Super-Admin“) ausgeführt werden muss.
Viele moderne Container-Lösungen machen das anders.
OCI –Open Container Initiative und CRI-O – Container Runtime Interface using OCI
Um eine sicherere und vor allem besser standardisierte Umgebung für Container zu ermöglichen, wurde die Open Container Initiative der Linux Foundation ins Leben gerufen. Diese stellt eine Spezifikation für Container-Umgebungen bereit, an der sich viele neue Lösungen orientieren, z.B. Podman von Red Hat. Die Idee dahinter: Wenn sich alle Container-Lösungen an die Spezifikationen halten, kann ich mir die Lösung aussuchen, die meinen Use Case am besten bedient, z.B. im Bereich Performance. Um alle diese Lösungen an Kubernetes anbinden zu können, gibt es das „Container Runtime Interface using OCI compliant runtimes“ (CRI-O). Das vereinfacht die Auswahl bzw. den Austausch der grundlegenden Container-Lösung auf den zu verwaltenden Hosts erheblich. Ich bin mit meiner (OCI-kompatiblen) Container-Umgebung auf den Systemen nicht mehr zufrieden? Kein Problem, ich kann es durch eine andere austauschen!
Die prominente Ausnahme, die die Spezifikationen nicht bedient: Docker! Und hier fangen die Schwierigkeiten für eine umfassende Orchestrierungslösung – in diesem Fall Kubernetes – an:
Kubernetes und die Sonderlösung für Docker
Kubernetes hat sich in den 6 Jahren seit seiner Veröffentlichung zum Platzhirsch bei der Containerorchestrierung entwickelt. Es gibt kaum eine umfassende Lösung für den Betrieb von Containern – Open Source oder kommerziell, on-prem oder Cloud – die nicht auf Kubernetes basiert.
Durch die (anfangs) weite Verbreitung von Docker ergab sich aber das Problem, dass Kubernetes diese Lösung unterstützen musste, weil Docker lange Zeit das Synonym für Container war. Hätte man es nicht unterstützt und eine andere Lösung erzwungen, es wäre wahrscheinlich nicht so gut angenommen worden.
Doch diese Unterstützung hatte ihren Preis: Das Kubernetes-Team bzw. die Community entwickelt und aktualisiert etwas, dass sich „docker-shim“ nennt. Dabei handelt es sich um eine Abstraktionsschicht, die die Eigenheiten von Docker berücksichtigt, aber vor der eigentlichen Orchestrierungsschicht „versteckt“. Für Kubernetes sieht es (mehr oder weniger) aus wie jede andere OCI-kompatible Container-Umgebung, spricht aber nach unten die Sprache von Docker. Man kann sich vorstellen, dass bei zunehmendem und divergierendem Funktionsumfang von Docker und den OCI-Spezifikationen der Aufwand für die Wartung unverhältnismäßig groß wird.
Da Docker zunehmend an Bedeutung verliert, ist es verständlich, dass man diesen alten Zopf abschneiden will – insbesondere bei kommerziellen Angeboten und Angeboten aus der Cloud ist mittlerweile v.a. wichtig, dass die eingekaufte Gesamtlösung funktioniert, und nicht, was genau unter der Haube passiert.
Das heißt übrigens nicht, dass Sie morgen Ihre auf Docker aufbauende Kubernetes-Umgebung nicht mehr nutzen können. Eine zumindest grundlegende Unterstützung ist noch bis voraussichtlich 2022 vorgesehen. Man sollte diese Deadline aber im Auge behalten!
Fazit
Einer der Urväter moderner Microservice-Modelle und der Umsetzung in Form von Containern wird mehr und mehr von seinen Nachfolgern bzw. Konkurrenten ersetzt, gerade in großen und/oder produktiven Umgebungen. Das ist aus technischer Sicht nachvollziehbar, aber für manch einen Docker-Fan vielleicht etwas traurig.
Docker wird jedoch weiterhin als die Lösung in Erinnerung bleiben, die den Trend Microservice und Container für die Entwickler und RZ-Betreiber dieser Welt beherrschbar gemacht hat.
