© Artur Szczybylo / 123RF.com

Während die großen Linux-Distributoren immer stärker zu Containern tendieren, fragen sich viele Administratoren, wozu der Hype gut sein soll. Oft ist diese Frage berechtigt. Denn Container sind weit davon entfernt, die Universallösung für alle Probleme zu bieten.

Container, Kubernetes, Rancher, OpenShift, Docker, Podman – wer sich als Admin mit den Themen Container und Kubernetes (kurz: K8s) noch nicht ausführlich beschäftigt hat, bekommt bisweilen den Eindruck, er müsse eine komplett neue Sprache erlernen. Dass orchestrierte Flotten auf Container-Basis mit Kubernetes keine Eintagsfliege sind, haben sie hinlänglich bewiesen. Vielen Admins geht das ewige Container-Lied mittlerweile allerdings gehörig auf die Nerven. Ganz gleich, bei welchem Anbieter man aktuell ins Portfolio schaut – überall, so scheint es, ist der maßgebliche Faktor für Erfolg nur noch die Frage: Wie bekomme ich mein gesamtes Portfolio möglichst schnell Cloud-ready?

Negativbeispiel Ceph

Für Administratoren fernab von neuen Plattformen auf der grünen Wiese birgt das indes nicht nur Vorteile. Die verteilte Objektspeicherlösung Ceph bietet ein Beispiel dafür. Glaubt man dem Hersteller Red Hat, ist das Deployment in Form von Containern mittlerweile der beste Weg, Ceph auszurollen. Alle Ceph-Komponenten kommen dabei als einzelne Container daher, die Cephadm passend auf die Systeme bügelt.

Schön und gut, doch wer als Admin die Arbeit mit Ceph gewohnt ist und anschließend ein einfaches »ceph -w« auf der Kommandozeile ausführen will, um sich über den Zustand des Clusters zu informieren, erlebt eine böse Überraschung: Command not found heißt es dann nämlich. Logisch: Wenn alle Ceph-Komponenten in Containern stecken, gilt das auch für Cephs CLI-Werkzeuge (Abbildung 1). Mittels »cephadm shell« kommt man zwar in eine virtuelle Umgebung, die das Ausführen entsprechender Kommandos ermöglicht, Userland-Software profitiert davon allerdings nicht. Programme, die Librados brauchen oder auch nur darauf angewiesen sind, dass »/etc/ceph/ceph.conf« existiert und die richtigen Adressen der MON-Server enthält, greifen ins Leere.

Abbildung 1: Ein containerisiertes Ceph stellt Admins ohne Container-Erfahrung vor Herausforderungen, weil sich etwa die bekannten Werkzeuge nicht mehr dort finden, wo sie normalerweise liegen.

Red Hat zwingt Admins hier also dazu, sich mit dem Container-Thema ausführlich zu befassen, ob sie wollen oder nicht. Klar: Aus Sicht des Herstellers ergibt das durchaus Sinn. Denn Red Hat muss Ceph bloß noch in jeweils einer Version pro Major Release pflegen, um lauffähige Programme für Red Hat Enterprise Linux in allen Versionen, dessen Derivate und sogar für Ubuntu oder Suse zu bekommen. Überall, wo eine Laufzeitumgebung für Container zur Verfügung steht, funktionieren diese Container schließlich identisch. Auf diese Weise zwangsbeglückte Administratoren rümpfen aber völlig zu Recht die Nase.

Es braucht nicht immer Container

Landauf und landab propagieren Hersteller Container heute als das universelle Allheilmittel für alle Probleme. Anwendungen müssen Cloud-ready sein; wer in seiner Umgebung noch nicht umfassend auf Container setzt, der ist zumindest ein Ewiggestriger, wenn nicht gar ein Innovationsverweigerer. Und wer die ideale Architektur eines Kubernetes-Clusters nicht im Schlaf aufsagen kann, der muss die letzten 25 Jahre wohl in der Pendeluhr geschlafen haben.

Dass Container und K8s durchaus ihre eigenen Probleme und Herausforderungen haben, fällt dabei viel zu oft unter den Tisch. An all jene Admins, die das Container-Treiben noch immer mit gesunder Skepsis betrachten, richtet sich dieser Text. Konkret geht es um die Frage, in welchen Fällen Container eben keine sinnvolle Alternative für bestehende oder neue Setups bieten. Wann kann der Admin sich den technischen Aufwand für eine Migration getrost sparen, weil er ohnehin (kaum) davon profitiert?

Klare Trennung

Ein fundamentales Problem der gesamten Container-Debatte besteht darin, dass es kaum noch eine Trennung zwischen technischen Konzepten gibt, die eigentlich gar nicht zwangsläufig zusammengehören – auch wenn sie einander ergänzen. Zunächst besteht das Ziel deshalb darin, eine klare argumentative Trennung zwischen den Konzepten von Containern als solchen und der Container-Orchestrierung zu bekommen.

Anwendungen in Containern können ihren Nutzen durchaus außerhalb von Kubernetes haben, und nicht nur aus Sicht des Anbieters. Wenn sämtliche Begriffe und Beschreibungen allerdings in einem großen Topf landen und beliebig zur Anwendung kommen, weiß am Ende niemand mehr, worum sich die Debatte eigentlich dreht. Die Themen Containerisierung und Kubernetes betrachtet dieser Text deshalb im Folgenden getrennt voneinander.

Container sind praktisch

Container sind in vielerlei Hinsicht praktisch. Immer wieder führen Verfechter des Prinzips etwa ins Feld, dass die Abhängigkeitshölle klassischer Paketverwaltungen in Containern praktisch nicht mehr existiert. Schließlich bringt jeder Container neben der jeweiligen Anwendung gleich auch deren Userland mit, das autark funktioniert. Dadurch gestalten sich auch Updates einfacher: Im Zweifelsfall hält der Admin einfach einen laufenden Container an, checkt die neue Version des jeweiligen Abbilds aus, startet sie mit der alten Konfiguration und den alten Daten, und fertig ist der Lack.

Auch in Sachen Sicherheit positionieren Container sich zunächst vorteilhafter als die althergebrachte Konkurrenz. Unter der Haube sind Container schließlich nichts anderes als eine Kombination verschiedener Werkzeuge des Linux-Kernels, um Prozesse vom Rest des Systems und voneinander abzuschirmen. Läuft ein verwundbarer Webserver im Container und ein Angreifer verschafft sich unautorisierten Zugang, bleibt er im Container gefangen und kommt im Normalfall auch nicht heraus. Das ist zumindest eine zusätzliche Sicherheitsebene, die bei Anwendungen ohne Container-Layer fehlt.

Der Mythos Sicherheit

Sieht man allerdings genauer hin, bröselt der Mythos der sicheren Container schnell und dauerhaft. Wie bei Paketen kommt es auch bei Containern schließlich darauf an, wer ihr Urheber ist und ob es sich dabei um eine vertrauenswürdige Stelle handelt.

Die gängigen Paketverwaltungen der großen Distributoren haben dieses Problem längst gelöst: Sowohl Rpm als auch Dpkg verfügen über Mechanismen, um eine bis zum installierten Paket auf einem System dokumentierte Chain of Trust herzustellen. Dazu signieren die meisten Distributoren die Verteilungslisten ihrer Paketmanager mit digitalem PGP-Schlüssel. Mittels einer derart signierten Datei kann der Admin dann überprüfen, ob das installierte Paket mit dem dort verzeichneten Paket übereinstimmt, ob also etwa die SHA256-Summen der einzelnen Dateien passen. So lässt sich hervorragend und Compliance-konform nachvollziehen, ob es lokale Veränderungen an Paketinhalten gegeben hat.

Ganz anders stellt sich die Situation bei Container-Abbildern dar. Dafür bieten die großen Hersteller zwar ebenfalls fertige Basis-Images an, doch die enthalten in der Regel keine Dienste. Hier ergeben sich für den Administrator zwei mögliche Vorgehensweisen.

Komplexes CI/CD-Gebilde

Die erste Möglichkeit besteht darin, eine eigene Umgebung für Continuous Integration und Continuous Deployment (CI/CD) auf die Beine zu stellen. Dabei bekommt man es zwangsläufig mit Tools wie Jenkins oder Zuul zu tun. Die Idee: Auf Grundlage der Abbilder der Distributoren bauen CI/CD-Systeme bei Erscheinen einer neuen Version einer Software automatisch ein neues Image und bereiten es so vor, dass der Admin das Deployment in die Produktion nur noch per Mausklick bestätigen muss. Das Ausrollen selbst übernimmt wieder das CI/CD-System, sodass sich der Arbeitsaufwand für den Administrator in engen Grenzen hält. Das liegt freilich per se daran, dass der Automationsgrad in Setups dieser Art sehr hoch ist.

Der Pferdefuß: Wer nicht für viel Geld ein fertiges CI/CD-System einkauft, investiert reichlich Zeit, um eines zu konstruieren. Bei Jenkins und Konsorten handelt es sich um komplexe Hilfsmittel, die man kaum als selbsterklärend bezeichnen kann. Es erfordert also viel Zeit und Aufwand, ein CI/CD-System zusammenzustellen, das letztlich denselben Zustand ermöglicht, den Rpm, Dpkg & Co. auf Paketbasis seit Jahrzehnten bieten.

Updates und gerade auch deren Handling sollten dabei keinesfalls in Vergessenheit geraten. Denn mit Fug und Recht vertrauen Administratoren darauf, dass ein »apt dist-upgrade« auf ihrem System alle von Canonical oder Debian angebotenen Sicherheitsaktualisierungen einspielt. Wer hingegen auf CI/CD setzt, muss Security-Updates selbst tracken und betroffene Container eher einzeln austauschen als kollektiv.

Mehr Aufwand durch Umwege

CI/CD-Systeme sind also keinesfalls Selbstläufer und produzieren in mancherlei Hinsicht sogar mehr Aufwand als klassische Paketmanager. Nicht wenige Admins versuchen, sich diese Arbeit zu ersparen und greifen stattdessen zu fertigen Abbildern aus dem Internet. Docker Hub ist eine beliebte Quelle für solche Abbilder, doch kann hier jeder beinahe jedes Image in jeder beliebigen Form hochladen.

Zwar gibt es für verbreitete Dienste wie MariaDB oder MongoDB fertige Abbilder direkt vom Hersteller, doch Images weniger bekannter Software lassen sich oft nur über die Community beziehen. Genau das stellt ein riesiges Problem dar, wie das Linux-Magazin bereits etliche Male bis ins Detail ausgeführt hat [1]. In vielen Fällen lässt sich bei solchen Abbildern aus Sicht des Admins nicht einmal nachvollziehen, wie sie überhaupt gebaut wurden. Mithin kann man auch nur raten, was sich darin verbirgt.

So entpuppten sich in der Vergangenheit bereits etliche Docker-Hub-Images für diverse Dienste als verkappte Bitcoin-Miner. Andere Abbilder werden nur einmal hochgeladen und durch ihre ursprünglichen Autoren danach nicht mehr gepflegt. Fällt für das enthaltene Programm eine Sicherheitsaktualisierung an, steht der Admin im Regen. Vom Einsatz solcher Blackboxes im produktiven Betrieb kann man mithin nur dringend und kategorisch abraten. Wer sie dennoch nutzt, verkehrt die eigentlichen Sicherheitsvorteile von Containern ins glatte Gegenteil und hat am Ende deutlich unsicherere Systeme, als es beim Einsatz klassischer Paketmanager der Fall wäre.

Der Mythos Abhängigkeitshölle

Hinzu kommt, dass die Abhängigkeitshölle, der viele Admins durch Container entkommen wollen, eigentlich ein Relikt aus der Vergangenheit ist (Abbildung 2). Wer auf seinen Systemen nur auf Pakete des Herstellers, aus ordentlich gepflegten Backport-Verzeichnissen oder (oft) auf die Pakete von Anwendungsherstellern zurückgreift, hat mit Problemen bei der Installation und bei Updates nur noch selten zu kämpfen. Denn Red Hat, Suse, Debian & Co. haben längst ihre Hausaufgaben gemacht und ermöglichen heute sogar Cross-Version-Updates, etwa von Ubuntu 20.04 auf Ubuntu 22.04 bei Canonical. Wer auf seinen Systemen eine definierte Menge von Diensten betreibt und diese kennt, kommt mit klassischen Paketen deutlich schneller ans Ziel als mit einer kompletten CI/CD-Umgebung.

Abbildung 2: Der berüchtigten Abhängigkeitshölle fallen heute eigentlich nur noch Systeme zum Opfer, auf denen schlecht gepflegte Software von Drittanbietern zum Einsatz kommt. Quelle: reddit.com / <i>Pablo<I>

Automation tut not – und gut

Das gilt gerade auch für jene Szenarien, in denen klassische Automation über Ansible und ähnliche Tools eine bedeutende Rolle spielt. Ein anderer, von Container-Verfechtern gern erwähnter Container-Vorteil besteht nämlich darin, dass CI/CD-Systeme viel Automation bieten und sich Systeme schnell wieder in Gang setzen lassen, sollte einmal etwas katastrophal schieflaufen. Es genüge schließlich, so das Narrativ, den Container samt Konfiguration auf einem anderen System auszurollen und dort wieder zu starten.

Dabei fällt allerdings unter den Tisch, dass vergleichbare Setups selbstverständlich auch völlig ohne Container und direkt auf dem Blech möglich sind. Physische Hardware etwa lässt sich völlig problemlos mit Open-Source-Software wie Foreman (Abbildung 3) verwalten. Dem Administrator steht dann ein umfassendes Lifecycle-Management zur Verfügung, über das Rechner sich aus der Ferne neu starten, neu installieren und komplett löschen lassen. Wer sich spezifisch an einen Hersteller binden kann und will, findet bei Red Hat (Red Hat Satellite), Suse (Suse Manager) und Canonical (Landscape) auch entsprechende Boxed-Produkte im Regal, die sich in kurzer Zeit ausrollen lassen.

Abbildung 3: Lifecycle-Manager wie Foreman unterstützen den Admin dabei, Systeme nach Problemen schnell durch eine Neuinstallation wieder zum Laufen zu bringen. Container sind dafür nicht notwendig. Quelle: Foreman

Obendrein steht Administratoren heute das komplette Arsenal gut ausgereifter, perfekt getesteter Automatisierer zur Seite. Ganz gleich, ob die Wahl dabei auf Puppet, Chef, Salt oder Ansible fällt: Mit all diesen Werkzeugen lassen sich einfache Aufgaben wie die Installation eines Diensts samt des Ausrollens einer Konfigurationsdatei auf Template-Basis schnell und gut umsetzen – völlig ohne den Umweg über CI/CD.

Erleidet ein Server einen Hardwareschaden, installiert ein Gespann aus Foreman und Ansible diesen samt seiner benötigten Dienste und deren Konfiguration in wenigen Minuten sauber neu, auch ohne jede Beteiligung von Docker oder Podman. Das bedingt freilich eine vom Admin etablierte, valide Automationsstory. Doch selbst deren Ausarbeitung dürfte in vielen Fällen schneller und leichter gelingen als die Arbeit mit Jenkins und Konsorten.

Komplizierteres Handling

Ein weiterer Faktor, der klar gegen Container spricht, kam eingangs schon kurz zur Sprache, verdient aber genauere Betrachtung. Auf Systemen laufende Container sind in der alltäglichen Arbeit des Sysadmins ungewohnt und zumeist auch komplexer in der Handhabung, eben weil der Administrator es hier mit der Laufzeitumgebung für Container zu tun bekommt. Der Zugriff auf die Dienste geschieht also durch diese Umgebung hindurch.

Und da geht die Misere schon los: Wer Red Hat Enterprise Linux 8 oder dessen Klone einsetzt, bekommt die klassische Docker-Engine nur noch über Trampelpfade und inoffizielle Quellen. Das kann nicht nur in Sachen Sicherheit und Compliance zu einem Problem werden, sondern nervt auch gewaltig. Denn Red Hat hat sich von Docker längst verabschiedet und geht in Form von Podman stattdessen eigene Wege. Die, so versichert man in Raleigh, seien zwar auf der Kommandozeile komplett kompatibel zu Docker. Im Alltag jedoch merkt der Admin schnell, dass es mit der Kompatibilität zwischen Podman und Docker an vielen Stellen dann doch nicht so weit her ist.

Schaut man bei den anderen Herstellern vorbei, ist die Situation kaum besser: Zwar steht die Community-Edition von Docker für Suse, Debian und Ubuntu unverändert weiterhin zur Verfügung. Canonical allerdings wünscht sich für die eigenen Nutzer eher, dass diese auf Snap zurückgreifen, ein eigenes Format also. Wer Systeme von Red Hat, Debian und Canonical unter den Fingern hat, bekommt es also mit drei unterschiedlichen Laufzeitumgebungen, zwei komplett unterschiedlichen CLIs und diversen Kompatibilitätsproblemen zu tun.

Wirres Debugging

Selbst wer exklusiv auf Podman oder Docker oder Snap setzen kann, merkt im Alltag schnell, dass Container viele Dinge komplizierter machen. Soll ein im Container laufender Dienst etwa automatisch beim Systemstart losrennen, erfordert das eine Systemd-Unit-Datei. Die muss allerdings mit der Container-Verwaltung interagieren, statt den jeweiligen Dienst einfach direkt zu starten.

Apropos Container-Verwaltung: Fast schon zur Folklore gehören heute auch Erzählungen von Admins, die verzweifelt versuchen, die Ausgaben auf Stdout ihrer laufenden Container zu finden. Bei Ceph etwa schreiben die OSDs und MONs zwar eigene Log-Dateien, die sich im Host-System auch unter »/var/lib/ceph/osd/« finden. Die unmittelbaren Meldungen der Dienste enthalten sie allerdings nicht. Wer sie braucht, hängt sich stattdessen mittels »docker logs -f« an den laufenden Container (Abbildung 4).

Abbildung 4: Wer die Fehlermeldungen von in Containern verpackten Ceph-Diensten auf Stdout sehen will, muss sich unmittelbar an den Container anhängen, statt auf eine normale Logdatei zurückzugreifen.

Zur Ehrenrettung der Container sei angemerkt: Vieles davon lässt sich konfigurieren. Die Behauptung, Container funktionierten ab Werk besser, schneller und zuverlässiger sowie sicherer als Pakete, darf man angesichts all dieser Faktoren aber getrost bezweifeln.

Sieht man sich zudem die Art und Weise an, wie in Containern laufende Dienste an das lokale Netz angebunden sind, scheinen zusätzliche Zweifel angebracht. Weil Container ab Werk darauf ausgelegt sind, nicht an die IP-Adressen des Host-Systems gebunden zu sein, nutzen Docker & Co. Port-Weiterleitungen als Trick. Die Container machen auf dem Host dann ein virtuelles Netz auf, an das der Kernel Pakete für die eigentliche Ziel-IP weiterleitet. Das bedeutet im Umkehrschluss aber auch, dass Debugging mit Werkzeugen wie Tcpdump komplizierter ist als in konventionellen Umgebungen.

Zwischenfazit

Wie man es auch dreht und wendet: Container haben durchaus ihre Vorteile, erzwingen auf Seiten des Admins aber viel Lernaufwand und lösen manche Probleme dann trotzdem nicht so elegant wie ein Gespann aus klassischer Automation und Paketmanagement. Wer klar abschätzen kann, welche Dienste er auf welchen Systemen betreiben möchte, fährt mit einer Kombination aus Ansible, Konfigurations-Templates und den klassischen Paketen der Anbieter besser und zuverlässiger. Vor allem aber kommt er mit weniger Komplexität in Berührung als bei Docker, Podman und den anderen Container-Lösungen.

Kubernetes: Ja, aber …

Im zweiten und deutlich kürzeren Teil dieses Artikels muss auch Kubernetes zur Sprache kommen, jene Software, die den von Docker ausgelösten Container-Hype zweifelsohne noch einmal ordentlich befeuert hat. Klar: Admins lieben moderne Technik, und wenn eine Lösung erst einmal zum Hype wird, zieht sie alle Blicke auf sich. So war das auch bei Kubernetes, seit Jahren ist es in aller Munde. Bei vielen heute vorgestellten Lösungen auf Kubernetes-Basis gerät allerdings völlig aus dem Blick, wofür die Software steht und welches Problem sie eigentlich lösen will: Kubernetes kommt eigentlich aus der Welt des Cloud Computings und ergibt besonders vor dessen Hintergrund viel Sinn.

Springen wir ein paar Jahre zurück: Docker hatte gerade Container unter Linux überhaupt erst salonfähig gemacht, nachdem das Lösungen wie OpenVZ über Jahrzehnte hinweg nicht gelungen war. Das hatte freilich auch etwas damit zu tun, dass Docker nicht nur die Laufzeitumgebung für Container unter Linux anbot, sondern gleich auch ein passendes Ökosystem schuf, zu dem zweifelsohne der bereits erwähnte Docker Hub gehört.

Längst galt seinerzeit allerdings das Cloud Computing als Mittel der Wahl für Unternehmen, die vom IT-Krauter zum großen Plattformanbieter werden und zumindest in einer ähnlichen Liga wie Amazon spielen wollten. Container versprachen ihnen eine riesige Dividende, denn Orchestrierung sowie Automation in Verbindung mit fertig verpackten Anwendungen sind quasi die Autobahn auf dem Weg hin zu Platform-as-a-Service- (PaaS) und Software-as-a-Service-Angeboten (SaaS). Was noch fehlte, war eine Lösung, die Container über eine beliebige Anzahl physischer Hosts völlig automatisch verwalten und steuern konnte. Kubernetes etablierte sich schnell als Lösung für genau diese Aufgabe, schon weil das Produkt als (bis dahin) Inhouse-Entwicklung bei Google genau darauf perfekt ausgelegt war.

Überdrehter Hype

Die allermeisten Funktionen, die K8s in den vergangenen Jahren erhalten hat oder die sich über externe Werkzeuge nachrüsten lassen, dienen den bereits beschriebenen Einsatzbereichen PaaS und SaaS. Schon deutlich weniger gut eignet sich Kubernetes etwa für klassisches IaaS. Hier spielen klassische VMs auf Basis von KVM oder Xen ihre Vorteile stärker aus.

Das hielt und hält bis heute jedoch – und das ist in gewisser Weise der Kern des Problems – viele Kubernetes-Dienstleister nicht davon ab, K8s als Universallösung für alles zu verkaufen. Auch lokale Setups, so das Versprechen, profitierten von Kubernetes, weil das Handling von Anwendungen leichter werde. Dass das nur gilt, wenn sich die Anwendungen für den Betrieb in Containern überhaupt eignen und dass sich selbst dann bei vielen eher konventionellen Anwendungen ganz eigene Herausforderungen ergeben, verschweigen die Prospekte geflissentlich. Der größte Teil der bereits für Container ohne K8s beschriebenen Probleme trifft auf Container in Kubernetes zudem genauso zu. Zugegeben: Manche Unternehmen nutzen den Umstieg auf Container und Kubernetes für einen Kehraus ihrer bestehenden Anwendungslandschaft, schreiben einige Teile davon sogar neu. Doch das ist längst nicht in jedem Fall möglich oder bezahlbar.

Hinzu kommt: Kubernetes ist in bester Manier darauf ausgelegt, nahtlos in die Breite zu skalieren, also eine ewig wachsende Plattform zu gründen. Die braucht man allerdings nur dann wirklich, wenn man eine Plattform betreiben möchte, die mit beliebigen Mengen an Daten und Diensten zurechtkommt. Wer ein klar abgetrenntes Setup in einer definierten Zielgröße (mit gewisser Schwankungsbreite) im Sinn hat, kann den größten Teil der Kubernetes-Funktionalität kaum sinnvoll einsetzen. Hier wird K8s dann schnell zum hyperkomplexen Klotz am Beim, dessen Vielschichtigkeit in keiner Relation zum tatsächlichen Bedarf und Nutzen steht.

Fazit

Kubernetes ist vorrangig für jene Unternehmen interessant, die beliebige Mengen an Containern für SaaS- oder PaaS-Anwendungen über große Flotten physischer Systeme hinweg betreiben wollen. Es ergeben sich dabei durchaus auch Einsatzzwecke für den eigenen Bedarf; wer etwa seine Produktionssoftware auf As-a-Service-Prinzipien umstellt, dem leistet Kubernetes intern ebenfalls gute Dienste. Der Betrieb einer K8s-Plattform ist insofern keineswegs an die Eigenschaft gebunden, ein großer Plattformprovider zu sein.

Wer jedoch auf der Suche nach einer Lösung ist, die einzelne Anwendungen gut automatisiert und skalierbar ausrollt, tut sich wie schon bei den eigentlichen Containern mit einer Lösung auf Basis von klassischer Automation leichter. Bei Bedarf lässt sich diese durchaus sinnvoll mit Virtualisierung kombinieren, das Gespann aus VMware oder KVM und Ansible findet sich vielerorts. Auch Virtualisierungslösungen wie Proxmox (Abbildung 5), die sich gut mit bestehender Automation verzahnen lassen, gehen dem Admin hier hilfreich zur Hand. Fast alle Gespanne dieser Art sind in der Handhabung und der Wartung deutlich einfacher als K8s und bieten dadurch auch weniger Funktionalität.

Abbildung 5: Proxmox VE lässt sich wie andere Virtualisierungslösungen hervorragend mit vielen Automatisieren verknüpfen, sodass auch hier eine gewisse Form der Skalierbarkeit entsteht. Das gesamte Setup ist dennoch deutlich weniger komplex als eine ausgewachsene K8s-Umgebung. Quelle: Proxmox

Für viele Unternehmen, die sich heute ohne klaren Plan auf das Kubernetes-Abenteuer einlassen, genügt die Funktionalität klassischer Automation allerdings völlig: Container und Container-Automation sind eben nicht nur die Fortsetzung von Virtualisierung mit anderen Mitteln. (jcb)