© Sergejs Belovs, 123RF

Das Kata-Containers-Projekt verbindet die sichere Trennung von virtuellen Maschinen mit der Leichtfüßigkeit von Container-Virtualisierung. Nun verspricht die Version 2.0 der Software elementare Verbesserungen.

Seit Docker 2013 das Thema Container auf die Linux-Tagesordnung setzte, kennt der Hype um Container-Virtualisierung keine Grenzen. Das ist schlüssig und nachvollziehbar: Mussten Entwickler sich früher mit etlichen verschiedenen Zielplattformen für ihre Software herumschlagen und Pakete für diverse Linux-Varianten anbieten, stellen sie heute einen Container zur Verfügung, der auf jedem System mit Laufzeitumgebung für Container ohne Sperenzchen funktioniert. In die Welt dieser Laufzeitumgebungen ist in der Zwischenzeit zwar etwas Bewegung gekommen, weil Red Hat CRI-O entwickelt und Docker damit in gewisser Weise das Wasser abgegraben hat. Für Anwender ändert sich letztlich aber nicht viel, zumal CRI-O sogar CLI-kompatibel mit Docker ist. Container sind insofern eine echte Erfolgsgeschichte.

Schon Kurt Tucholsky stellte fest: “Jedes Glück hat einen kleinen Stich”. Das ist bei Containern nicht anders. Weil sie sich die Ressourcen mit ihrem Host-System teilen und weder einen Hypervisor im klassischen Sinn noch einen eigenen Kernel verwenden, fehlen ihnen Sicherheitsfeatures klassischer Virtualisierung. Die größte Sorge: Steigen Ganoven über eine Lücke in einen Dienst ein, der in einem Container läuft, zieht das die anderen Container unweigerlich in Mitleidenschaft. Absurde Workarounds sind um dieses Problem herum entstanden und bis heute erhalten geblieben – etwa der Ansatz, Container in virtuelle Maschinen zu verpacken. Das konterkariert nicht nur den durch Container deutlich reduzierten Overhead im Vergleich zu echten VMs, sondern bedingt auf der administrativen Ebene auch mehr Aufwand.

Wegdiskutieren lässt sich das Bedrohungsszenario indes auch nicht. Voll- oder Paravirtualisierung nutzt, zumindest in der Theorie, Features der Hardware, um einzelne VMs voneinander abzugrenzen. Insbesondere Intel kann allerdings ein Liedchen davon singen, was passiert, wenn sich die Schutzmechanismen der Hardware als fehlerhaft herausstellen. Bei der Virtualisierung in Containern trennt dagegen als einzige Hürde der gemeinsam genutzte Linux-Kernel die Workloads, im Detail dessen Namespace-Funktion. Gelingt es Angreifern also, den Kernel auf welche Art und Weise auch immer, zu kompromittieren, hat der Admin Feuer unterm Dach.

Zwei Unternehmen erkannten das Problem bereits 2015: Intel als globaler Player auf der einen Seite und das chinesische Startup Hyper.sh auf der anderen. Unabhängig voneinander und zeitgleich schickten sich die Firmen an, eine Lösung zu entwickeln. Erst 2017 machte man dann gemeinsame Sache und legte so den Grundstein für das Kata-Containers-Projekt. Anders als Hyper.sh hat Intel bis heute überlebt, was wohl auch an der Einbindung der Community und seiner finanziellen Potenz liegt.

Ende 2018 ging das Linux-Magazin bereits ausführlich auf Kata Containers [1] ein [2]. Zwischenzeitlich hat sich viel getan: Seit Mitte Oktober 2020 steht die Version 2.0 bereit. Grund genug, einen erneuten Blick auf das Projekt zu werfen: Was bringen die Änderungen der neuen Version? Ist Kata Containers nun noch sicherer, besser zu verwalten, schneller – oder alles zusammen?

Ein schlanker Hypervisor

Zur Erinnerung: Hyper.sh und Intel hatten seinerzeit beide das erklärte Ziel, die Performance-Vorteile von Containern mit der Sicherheit von Voll- und Paravirtualisierung zu kombinieren. Gleichzeitig sollte die erdachte Lösung mit vorhandenen Container-Schnittstellen – seinerzeit also vorrangig Docker – kompatibel sein. Nur so war davon auszugehen, dass die neue Technik schnell weite Verbreitung erreichen würde. Entwickler würden sich nicht dafür entscheiden, müssten sie ihren kompletten Workflow umstellen. Faktisch bedeutete das, dass man eine Lösung auf Basis echter Virtualisierung würde bauen müssen, die man aber an allen Seiten so mit Agents ausstattet, dass sie von außen wie ein Container erscheint.

Intel und Hyper.sh vereinigten ihre Kräfte wie beschrieben Ende 2017 unter der Federführung der OpenStack Foundation im Kata-Containers-Projekt. Ganz am Anfang traf man zusammen mehrere wegweisende Entscheidungen. Es lag etwa die Frage auf dem Tisch, wie man die Voll- oder Paravirtualisierung umsetzen wollte. Der Linux-Kernel bietet in Form seiner PVops-Funktionalität in der Theorie alle Bausteine, um einen eigenen Hypervisor zu bauen, der auf Container spezialisiert ist. Die Entwickler von Intel und Hyper.sh aber entschieden sich bewusst dagegen, das Rad neu zu erfinden. Getreu dem Motto “Neue Räder sind auch nicht runder” landete man stattdessen bei einem alten Bekannten der Linux-Welt, bei KVM. Zu Recht fragt manch misstrauischer Admin an dieser Stelle, worin denn dann der Unterschied zwischen Kata Containers und einer normalen Docker-Instanz liegen soll, die Container startet. Doch das ist schnell erklärt.

KVM: Die Frage ist, wie

So weisen die Kata-Containers-Entwickler beispielsweise darauf hin, dass ein Kernproblem virtueller Maschinen deren Overhead ist. Davon produziert KVM selbst aber nur einen kleinen Teil. Ein weit größerer Overhead entsteht, weil die virtuellen Instanzen einen ganzen Sack voller Software mitschleppen, die für den Betrieb der jeweiligen Instanz notwendig ist – etwa mit diversen Funktionen im Kernel, die für den Betrieb von Containern eigentlich nicht gebraucht werden. Setzt man hier den Rotstift an, lässt sich der durch Voll- oder Paravirtualisierung induzierte Overhead erheblich reduzieren.

Doch das ist nicht der einzige Vorteil von Kata Containers. Fast noch wichtiger erscheint der Umstand, dass die Kata-Containers-Runtime kompatibel zu CRI-O und zu Docker ist. Im Klartext bedeutet das, dass der ausführende Entwickler sich um KVM oder dessen Emulator Qemu im Hintergrund nicht kümmern muss. Ein Kata-Container sieht aus Nutzersicht nicht anders aus als ein Container von Docker oder auch Podman, obwohl im Hintergrund wesentlich mehr Magie passiert.

Mittlerweile ist KVM übrigens nicht mehr der einzige Hypervisor, mit dem sich Kata Containers nutzen lässt. Seit Version 1.5 steht auch Firecracker von Amazon als Option zur Verfügung, das seinerseits deutlich leichtfüßiger als KVM auf der Ebene des Hypervisors unterwegs ist.

Wie Version 1 funktionierte

Um die Neuerungen in Kata Containers 2.0 besser zu verstehen, ist ein kurzer Blick zurück auf die Version 1 nützlich. Zum Zeitpunkt des letzten Artikels zu Kata mussten die Entwickler nämlich noch durch einige brennende Reifen springen, um Kata Containers und Containerd (und damit im weiteren Verlauf auch Kubernetes) unter einen Hut zu bekommen.

Die immer selbe Frage dabei: Wie lassen sich die von Kubernetes oder einem CLI-Client kommenden Befehle in tatsächliche Befehle innerhalb der Mini-VMs und dort in Anweisungen in den Containern konvertieren? Der Sinn und Zweck der Mini-VMs liegt ja gerade darin, eine harte Trennung zu erreichen, die man für das Ausführen von Befehlen aber irgendwie überwinden muss – freilich, ohne dabei zu große Sicherheitsrisiken zu bedingen. Und das ist ja auch nicht die einzige Grenze, die es im Konstrukt Kata Containers zu überwinden gilt: Containerd als Bestandteil von CRI-O etwa nutzt eine andere API als Kubernetes und wieder eine andere API als Kata Containers selbst.

Kata Containers 1 war deshalb modular aufgebaut, und im Wesentlichen übernahmen drei Komponenten die Hauptarbeit. Die Runtime von Kata Containers 1 hielt Ausschau nach Anweisungen, die von einer Steuer-Software (etwa der Docker-CLI, Kubernetes oder OpenStack) in Richtung Container ergingen. Damit textliche Ein- und Ausgabewerte von Containern zwischen den eigentlichen Steuerungs-APIs sowie den Containern in den Kata-Containers-VMs fließen konnten, gab es obendrein mehrere sogenannte Shims, die das Routing dieser Meldungen übernahmen (Abbildung 1).

Abbildung 1: Kata Containers 1.0 brauchte noch allerlei Zusatzkomponenten, um mit Kubernetes & Co. zu kommunizieren. In der Version 2.0 weicht das Chaos gediegener Ordnung.

Noch nicht gelöst ist damit das Problem, wie die Anweisungen aus der Kata-Containers-Runtime und den Shims ihren Weg in die tatsächlichen Container finden. Hier machten sich die Entwickler einen Trick zunutze: Sie bauten eine kleine Komponente namens Kata-proxy, die mit den Shims und der Kata-Containers-Runtime via gRPC kommuniziert und auf der Hypervisor-Seite an eine serielle Schnittstelle angebunden ist. Die war mit einer virtuellen Instanz verbunden, wo eine Komponente namens Kata-agent sie als Eingabekanal nutzte und den gesamten relevanten Datenverkehr routete. Was in der Praxis funktionierte, war architektonisch freilich alles andere als elegant. Erste Bestrebungen, das Komponentenchaos zu beseitigen, gab es deshalb bereits Ende 2018.

Ein Zwischenschritt

Im ersten Schritt beschlossen die Entwickler, den Mechanismus mit Proxy und gRPC-Stream-Multiplikation in den Ruhestand zu verabschieden, um mehrere Level an Abstraktion aus dem Konstrukt zu entfernen. An seine Stelle trat der Vsock-Mechanismus des Linux-Kernels, der eine generische Schnittstelle für die Kommunikation mit virtuellen Instanzen bietet. Warum man diese Lösung nicht gleich nutzte, wird wohl ein historisches Rätsel bleiben, denn neu ist Vsock nicht: VMware hatte die Funktion bereits 2013 als offiziellen Patch in den Linux-Kernel eingebracht. Kata-shim und Kata-runtime konnten fortan über definierte virtuelle Sockets unmittelbar mit Agents in den Container-VMs kommunizieren. Auch Kata-runtime selbst wollten die Entwickler jedoch loswerden.

Da kamen ihnen Neuerungen in Containerd gerade recht: Containerd hat in seiner neuen Runtime V2 nämlich diverse Funktionen spendiert bekommen, die die Entwickler vorher mühsam in der Runtime selbst implementieren mussten. Der Schlüssel zum Erfolg lag am Ende darin, eine neue Version von Kata-shim für die V2-Runtime von Containerd zu entwerfen. Die Runtime-Komponente von Kata wurde dadurch zwar nicht überflüssig, weil der Kata-v2-Shim für die Zusammenarbeit mit der neuen Containerd-Runtime irgendwo beheimatet sein muss. Darüber hinaus übrig blieb letztlich aber eben nur eine Art Framework für den Betrieb von Kata-shim und jenes selbst. Damit ist klar: Schon innerhalb des ersten Release-Zyklus hat Kata sich an vielen Stellen mächtig verändert. Genug Potenzial für zusätzliche Verbesserungen sahen die Entwickler ganz offensichtlich dennoch.

Kata-agent 2.0

Das wird schon beim Blick auf Kata-agent deutlich. Weil Container in Kata Containers Voll- oder Paravirtualisierung nutzen, können sie den Kernel des Hosts nicht verwenden – das ist ja überhaupt erst der Sinn der Übung. Innerhalb der virtuellen Instanz ist dann aber einerseits ein Linux-Kernel notwendig und andererseits ein Dienst, der die per Vsock einlaufenden Kommandos liest, interpretiert und in eine konkrete Systemkonfiguration umsetzt (also etwa einen Container startet). Das Linux-System innerhalb der VM übernimmt Kata Containers aus der Open-Source-Welt: Hier kommt Clear Linux OS (Abbildung 3) zum Einsatz, eine stark gestutzte Distribution, die für eben solche Einsatzzwecke konzipiert wurde.

Abbildung 2: Clear Linux gibt es zwar auch für Desktops, doch Kata Containers nutzt die Mini-Distribution als Runtime in seinen VMs. Quelle: Linux Community

Beim Agenten gibt es indes keine Vorarbeit anderer Projekte, die Kata Containers sich zunutze machen könnte. Kata-agent ist deshalb ein zentrales Stück Software des Projekts selbst. In Kata Containers 1 basierte der Agent auf Go und brachte immerhin 11 MByte auf die Waage. Das klingt nicht nach viel, doch hält man sich vor Augen, dass das für Kata Containers genutzte Basis-Image gerade mal 150 MByte umfasst, sind 11 MByte eine ganze Menge. Noch deutlicher wird der Unterschied, setzt der Admin nicht auf KVM, sondern auf Firecracker: Dessen MicroVM ist noch kleiner. Bisher hat Kata-agent sich also einen ganz schönen Schluck aus der Ressourcenpulle genehmigt.

Kata Containers 2.0 macht Schluss mit der Völlerei: Den vorherigen Agenten werfen die Entwickler kurzerhand komplett weg. Ihn ersetzt ein Rewrite auf Basis von Rust, das denselben Funktionsumfang bietet, sich aber mit wesentlich weniger Ressourcen begnügt. 300 KByte beansprucht der neue Agent noch für sich, und die neue Version begnügt sich auch mit weniger RAM als ihr Vorgänger. Der durch Kata-agent bedingte Overhead schrumpft damit radikal.

gRPC muss gehen

Der Umstieg von Go auf Rust ist nicht der einzige Faktor, der beim Agenten in Kata Containers 2.0 zu besserer Performance führt. Bisher setzten die Entwickler für den Austausch von Befehlen zwischen den Komponenten auf gRPC. Das ist zwar zuverlässig, aber auch dafür bekannt, nicht zaghaft mit vorhandenem Speicher umzugehen. Eine am Markt etablierte Alternative bietet ttRPC von den Containerd-Entwicklern. Es kommt als RPC-Lösung für Low-Memory-Umgebungen daher, sodass das vom Kata-Agenten benötigte RAM nochmals drastisch schrumpft. Zwar sind gRPC und ttRPC nicht kompatibel, im geschützten Kata-Umfeld ist das aber kein Problem: Anwendungen von Drittanbietern, die mit dem Kata-Agenten via gRPC kommunizieren und nun eine Anpassung bräuchten, gibt es nicht. Der Agent kommt nur innerhalb von Kata Containers zum Einsatz, zumindest bisher (Abbildung 3).

Abbildung 3: Die Kata-Containers-Runtime, das alte Kata-shim und Kata-proxy gehören in Kata Containers 2.0 endgültig der Vergangenheit an und sind nicht mehr Teil des Pakets. Quelle: Kata Containers

Beim Agenten legen die Kata-Entwickler damit in Summe ordentlich vor: 300 KByte statt 11 MByte Größe, eine erheblich reduzierte Angriffsfläche und deutlich geringerer Speicherverbrauch sprechen eine deutliche Sprache. Davon profitieren vorrangig Umgebungen mit großen Mengen an Containern auf den einzelnen Systemen. Ein paar MByte eingesparten Speichers sind zwar nicht ausschlaggebend, doch 300 oder 400 Mal ein paar MByte eingesparten Speichers machen oft den Use-Case finanziell attraktiver.

Wissen, was los ist

Im Kontext von Cloud- und Container-Lösungen hat das Linux-Magazin in den vergangenen Jahren regelmäßig auf die Notwendigkeit hingewiesen, neben einem umfassenden Monitoring auch Trending zu betreiben. Anders als in klassischen Umgebungen muss der Admin in skalierbaren Umgebungen wie Container-Flotten unbedingt wissen, welche Ressourcen ihm noch zur Verfügung stehen und wann er Hardware nachstecken muss. In Docker- oder Kubernetes-Umgebungen ist das grundsätzlich auch kein Problem: Für Docker wie Kubernetes existieren diverse Werkzeuge, um Metrikdaten zu sammeln und hin zu Konsumenten wie InfluxDB oder Prometheus zu senden. Dort lassen sie sich dann mittels Grafana sogar visualisieren.

Admins von Kata Containers hatten bisher deutlich weniger Einsicht in das, was die Umgebung tat. Zwar waren die Werte aus Kubernetes und Docker ebenso verfügbar, doch bilden die eben nicht den kompletten Zustand des Setups ab. Den durch die eigenen Kernel der schlanken Container-VMs verursachten Overhead und das durch KVM tatsächlich genutzte virtuelle RAM sowie virtuelle CPUs bilden Docker oder Kubernetes in ihren Metrikdaten nicht ab. Kein Wunder, denn faktisch spielen diese Werte auf der Container-Ebene gar keine Rolle.

In Kata Containers 2.0 eilen die Entwickler genervten Administratoren endlich zu Hilfe und spendieren der Kata-Containers-Engine eine Schnittstelle für Prometheus. Das funktioniert feingliedrig: Über quasi alle Aktivitäten führt Kata künftig in Form einer eigenen Komponente penibel Buch und erlaubt es dem Administrator auch, diese per definierter REST-Schnittstelle auszulesen. Dass man sich hier für die Prometheus-API entschieden hat, ist zudem ein Fingerzeig: Langsam, aber sicher etabliert sich das Prometheus-Format als Standard in der FL/OSS-Welt. Das liegt nicht zuletzt auch daran, dass InfluxDB das Format nativ handhaben kann, weil etwa die Telegraf-Komponente des Diensts sowohl die eigene API als auch jene von Prometheus ansprechen kann.

Wie frisch nach der Einführung einer Funktion üblich, mangelt es noch etwas am Drumherum. Für Grafana finden sich im Netz etwa noch keine Dashboards, die die aus Kata stammenden Metrikdaten visualisieren und dem Admin aufbereitet anbieten könnten. Erfahrungsgemäß wird es aber nicht sehr lange dauern, bis findige Entwickler auch diesen Mangel beheben. Aus der Sicht des Administrators ist das Feature für das Sammeln von Metrikdaten ein echter Segen.

VirtIO-FS nun Standard

Auch an der Performance-Schraube drehen die Entwickler. In Kata Containers 2.0 erreicht VirtIO-FS (Abbildung 4) endlich einen produktiv nutzbaren Zustand und fungiert zudem als Standardkonfiguration. Mithilfe von VirtIO-FS lösen die Entwickler ein Problem, das der Emulator als harte Kante zwischen Host und Container erst einführt.

Abbildung 4: VirtIO-FS kommt in Kata Containers 2.0 standardmäßig zum Einsatz und ermöglicht den Zugriff auf einzelne Teile des Host-Dateisystems aus einer VM heraus. Quelle: VirtIO-FS-Projekt

Wer sich schon einmal im Detail mit Containern befasst hat, der weiß: Regelmäßig finden sich beispielsweise Konfigurationsdateien für Dienste in Containern nicht in diesen, sondern werden per Bind-Mount von außen in den Container eingehängt. Das ermöglicht es, Konfiguration und Container-Abbild völlig separat voneinander zu speichern und zu pflegen.

Was beim normalen Docker oder Kubernetes kein Problem ist, stellt bei Kata eine Herausforderung dar: Der Emulator soll direkten Zugriff auf den Host aus der VM heraus, in der die Container laufen, ja eigentlich gerade unterbinden. Die Entwickler haben in den vergangenen zwei Jahren mehrere Hacks ausprobiert, um sich des Problems zu entledigen. Mal versuchte man es mit virtuellen Blockgeräten, die Kata dynamisch an neue Instanzen anhing. Dann wieder war 9pfs das Werkzeug der Wahl, ein für System 9 entwickeltes Netzwerkdateisystem, das Kata für die jeweilige VM automatisch einrichtete.

Seit Kata Containers 1.7 liegt der Fokus auf einem paravirtualisierten (deshalb VirtIO-)Treiber für ein virtuelles Dateisystem. VirtIO-FS kommt zwar nicht direkt von den Kata-Containers-Entwicklern, diese haben jedoch einen erheblichen Anteil an der Entwicklung. Seit Linux 5.4 gehört der Treiber offiziell zu Linux; Qemu unterstützt ihn seit der Version 5.0 offiziell. Auch Libvirt versteht sich mittlerweile auf VirtIO-FS.

Praktisch funktioniert das dann so, dass der Zugriff aus Containern heraus auf einen definierten Ordner des Hosts möglich ist, in dem der Admin wie gewohnt seine Konfigurationsdateien ablegt. Der übliche Workflow, Dateien in Container einzubinden, funktioniert damit auch durch die Barriere von KVM hindurch.

Ab sofort im Mono-Repo

Eine weitere zentrale Neuerung offeriert Kata Containers 2.0 nicht vorrangig für Admins, sondern für Entwickler, die am Projekt mitarbeiten möchten. Bisher folgte man dem in der Open-Source-Welt weitverbreiteten Ansatz, für einzelne Tools im eigenen Bestand separate Git-Repositories zu verwenden. Für Kata Containers 2.0 haben die Entwickler nun aber die Verzeichnisse sämtlicher Komponenten in einem Git-Repository zusammengezogen.

Der Ansatz firmiert allgemein als “Mono-Repo-Approach” und hat prominente Befürworter, allen voran Google (Abbildung 5). Das Kernargument lautet so: Wenn alle Dienste in einem Verzeichnis liegen und die Regel gilt, dass alle Komponenten in HEAD stets funktionieren müssen, tut man sich wesentlich leichter damit, die Komponenten zusammen und aktuell zu halten. Der typische Versionswirrwarr, bei dem auf Systemen dann plötzlich Version A des Moduls 1 und Version B des Moduls 2 desselben Projekts installiert sind, entfällt.

Abbildung 5: Kata Containers setzt mittlerweile auf den Mono-Repo-Ansatz und erhofft sich davon, das eigene Git-Verzeichnis besser verwalten zu können.

Admins, die Kata Containers aus den Quellen selbst übersetzen, sind von der Änderung unmittelbar betroffen. Wer vorgefertige Pakete nutzt, dürfte nicht viel davon mitbekommen, weil die jeweiligen Distributoren das Layout ihrer Pakete vermutlich kaum ändern werden (es ist meist durch verschiedene Regelwerke festgelegt). Immerhin profitieren dann aber die Entwickler der Linux-Distributionen, die in Zukunft mit weniger losen Teilen hantieren müssen.

Neben den großen Neuerungen ergeben sich in Kata Containers 2.0 freilich auch viele Detailverbesserungen. Cloud Hypervisor, ein eigener Virtual Machine Monitor (VMM) auf Basis von KVM, lässt sich nun alternativ zu Qemu mit Feature-Parität nutzen. Qemu selbst haben die Entwickler auf das aktuelle Major-Release 5.0.0 aktualisiert, wohl auch, weil erst in dieser der Support für VirtIO-FS als stabil markiert ist. In der eigenen Version von Clear Linux OS bringt Kata Containers außerdem den Kernel auf einen neueren Stand: Die Version 5.4.71 ist zwar alles andere als topaktuell, genügt für die Aufgaben im Kontext von Kata Containers aber völlig und ist zudem daran angepasst.

Fazit

Schon Ende 2018 war Kata Containers ein cooles Projekt, und das bleibt es weiterhin. In der Version 2.0 der Software beseitigten die Entwickler nicht nur erfolgreich einige architektonische Schwächen der ersten Variante, sondern sie rüsteten auch Funktionalität nach, deren Fehlen bislang wehtat. Dass Kata-shim bloß noch an Containerd andockt und nicht mehr wild in der Gegend herumkonvertiert, ist gerade im Debugging-Kontext ein Segen. Dass das separate Kata-proxy mitsamt dem alten Shim verschwindet, war praktisch längst überfällig. Und die Rosskur für Kata-agent, die den Agenten von 11 MByte auf 330 KByte einschmolz, sorgt nicht nur für weniger Verbrauch von Speicherplatz, der Agent reagiert auch merklich flinker. Das dürfte mit an ttRPC liegen, das gRPC abgelöst hat und viel effizienter mit dem verfügbaren Speicher umgeht.

Im Alltag besonders bemerkbar macht sich der Einsatz von VirtIO-FS, der das Einbinden von Ordnern des Hosts in virtuelle Instanzen nun viel leichter und ohne Kapriolen ermöglicht. Die Notwendigkeit, Konfigurationsdateien über Umwege irgendwie in die Container hineinzubekommen, war für manchen Admin zuvor ein echter Showstopper. In Kata Containers 2.0 hingegen lassen sich Konfigurationsdateien praktisch so einbinden, wie es bei normalem Docker oder Kubernetes auch der Fall wäre; aus Nutzersicht ergibt sich also kein Unterschied.

Erst die Zeit wird allerdings zeigen, ob die Änderungen in Kata Containers 2.0 die Lösung wirklich für einen größeren Benutzerkreis attraktiv machen. Bis dato bleibt Kata Containers in der Anwendergunst hinter den Erwartungen eher zurück, trotz Schützenhilfe der OpenStack Foundation. Möglicherweise beschleunigen die nun eingeführten Änderungen die Adaption der Technologie. Praktischen Bedarf gibt es zweifellos: Admins werden sich nicht bis in alle Ewigkeit damit abfinden, erst wieder eine klassische VM um Container herumzubauen, um für ausreichende Trennung zu sorgen. Kata bietet eine perfekte Lösung, die in der Startbox steht und mit den Hufen scharrt. Damit die Technologie in der Breite ankommt, müssen lediglich genug Admins den Startschuss für die eigenen Systeme geben. (jcb/jlu)