Ein Positionspapier, in dem argumentiert wird, dass die Containerisierung auf Betriebssystemebene, deren kanonisches Beispiel Docker ist, nicht nur eine nützliche Werkzeugwahl, sondern eine grundlegende Technologie für die Konvergenz von Betriebs- und Informationstechnologie ist. Die Argumentation geht direkt auf die stärksten Einwände ein und kommt zu dem Schluss, dass diese eher nachvollziehbar als disqualifizierend sind.
Präambel
Eine anhaltende Skepsis geht mit der Einführung von Containern in industrielle Umgebungen einher. Die Einwände sind bekannt: Industriesysteme haben Lebenszyklen, die in Jahrzehnten gemessen werden, nicht Bereitstellungszyklen, die in Minuten gemessen werden; Echtzeit-Leistungsanforderungen können die Unvorhersehbarkeit einer Allzweck-Laufzeit nicht tolerieren; Die Sicherheitsauswirkungen der Ausführung eines Linux-Kernels, der Dutzenden von Containern ausgesetzt ist, sind unzureichend verstanden. Die betriebliche Reife der Arbeitskräfte im Bereich Operations Technology (OT) entspricht nicht der betrieblichen Komplexität moderner Cloud-nativer Tools.
Jeder dieser Einwände hat einen wahren Kern. Keiner von ihnen, so argumentiert dieser Artikel, hält einer ernsthaften Prüfung stand.
Die These ist direkt: Die Containerisierung auf Betriebssystemebene – deren kanonisches Beispiel Docker ist – ist das richtige Grundsubstrat für Industriesoftware. Seine Einführung ist keine Frage der Mode, sondern eine architektonische Notwendigkeit. Die Alternativen sind schlimmer. Die Einwände sind zwar real, identifizieren aber eher technische Probleme mit bekannten Lösungen als grundlegende Inkompatibilitäten.
Dieser Aufsatz gliedert sich in acht Abschnitte. Der erste legt fest, was Docker technisch ist, und unterscheidet die Technologie von der Marketingoberfläche. Der zweite Ansatz ordnet Container in ihre historische Abstammung ein, um den Eindruck zu zerstreuen, dass es sich hierbei um eine neuartige und unbewiesene Technologie handelt. Das dritte charakterisiert das Problem der industriellen Softwarebereitstellung, für dessen Bewältigung Container besonders gut geeignet sind. Der vierte bringt den positiven Fall voran. Im fünften Abschnitt werden die wichtigsten Einwände behandelt. Der sechste Abschnitt beschreibt die Architekturmuster, die sich bei industriellen Produktionseinsätzen herausgebildet haben. Der siebte Teil untersucht offene Probleme und die Bedingungen für eine verantwortungsvolle Adoption. Der achte Satz wiederholt und verteidigt den zentralen Anspruch.
Die Zielgruppe ist der Architekt oder technische Leiter, der abwägt, ob er eine industrielle Produktlinie auf eine Container-Infrastruktur umstellen soll. Das Argument soll gerade deshalb nützlich sein, weil es der Technik nicht schmeichelt.
Was Docker eigentlich ist
Ein sauberes Argument erfordert ein sauberes Objekt. Docker ist ein stark überladener Begriff, und die erhebliche Verwirrung in der industriellen Diskussion über Container ist direkt auf die Ungenauigkeit darüber zurückzuführen, was besprochen wird.
Im engeren Sinne bezieht sich Docker auf eine bestimmte Implementierung der Virtualisierung auf Betriebssystemebene unter Linux, die ursprünglich 2013 von dotCloud (später Docker, Inc.) veröffentlicht wurde [1]. In der aktuellen Praxis umfasst der Begriff mehrere unterscheidbare Komponenten: eine Container-Laufzeitumgebung (ursprünglich „libcontainer“, später „containerd“ und „runc“), ein Bildformat und ein Registrierungsprotokoll, ein Befehlszeilentool und eine Daemon-Architektur.
Die zugrunde liegenden technischen Grundelemente sind Kernel-Funktionen, keine Docker-spezifischen Erfindungen:
Linux-Namespaces [2] sorgen für die Isolierung von Systemressourcen auf Prozessebene. Die sieben Namespace-Typen – PID, Netzwerk, Mount, UTS, IPC, Benutzer und Cgroup – ermöglichen gemeinsam einer Gruppe von Prozessen den Betrieb in einer isolierten Ansicht von Prozess-IDs, Netzwerkschnittstellen, Dateisystem-Mounts, Hostnamen und Domäne, Kommunikationskanälen zwischen Prozessen, Benutzer- und Gruppen-IDs und Kontrollgruppenhierarchien. Ein Container ist auf Kernel-Ebene ein Prozessbaum, dessen sichtbarer Systemstatus durch diese Namespaces eingeschränkt wird.
Kontrollgruppen (cgroups) [3], ursprünglich bei Google entwickelt und 2007 in den Linux-Kernel integriert, ermöglichen die Ressourcenabrechnung und -begrenzung. CPU-Anteile, Speicherlimits, E/A-Bandbreite und Gerätezugriff können pro Prozessgruppe begrenzt werden. cgroups v2, die einheitliche Hierarchie, die in Kernel 4.5 (2016) eingeführt wurde und bis 2021 in den meisten Distributionen zum Standard wurde, verbesserte das Ressourcenkontrollmodell erheblich.
OverlayFS [4] und ähnliche Union-Dateisysteme ermöglichen das Layered-Image-Modell, das Docker von früheren Containersystemen unterscheidet. Ein Bild ist ein Stapel schreibgeschützter Ebenen. Ein laufender Container fügt darüber eine beschreibbare Ebene hinzu. Identische Schichten werden von Containern und Hosts gemeinsam genutzt, was zu einer erheblichen Speicher- und Netzwerkeffizienz führt.
Die inhaltsadressierbare Speicherung von Bildebenen, die durch kryptografischen Hash identifiziert werden, ermöglicht eine Garantie, die in herkömmlichen Bereitstellungsmodellen ihresgleichen sucht: Byte-für-Byte-Reproduzierbarkeit des bereitgestellten Artefakts. Das durch „sha256:abc...“ identifizierte Bild auf der Arbeitsstation eines Entwicklers ist bitidentisch mit dem Bild, das durch denselben Hash auf einem Produktions-Gateway identifiziert wird, unabhängig davon, wann oder wo es abgerufen wird.
Diese Grundelemente sind keine Erfindungen von Docker. Dabei handelt es sich um Linux-Kernel-Features, die Docker zu einem Produkt zusammengebaut hat. Ihre Existenz und Stabilität reichte lange vor der weit verbreiteten Einführung von Containern zurück und sie werden jetzt durch eine offene Spezifikation geregelt.
Seit 2015 wird das Container-Ökosystem im Rahmen der Open Container Initiative (OCI) [5] standardisiert und drei Spezifikationen hervorgebracht: die Laufzeitspezifikation, die Image-Spezifikation und die Verteilungsspezifikation. Die praktische Konsequenz ist, dass das Unternehmen Docker nun einer von mehreren Implementierern eines offenen Standards ist und die in der Produktion verwendeten Container-Laufzeiten – Containerd, CRI-O, Podman – über diese Spezifikationen zusammenarbeiten. Im Jahr 2025 „Docker zu nutzen“ bedeutet, OCI-Container zu verwenden; Marke und Technologie haben sich entkoppelt.
Diese Begriffsklärung ist wichtig, da Einwände gegen Docker häufig entweder das Unternehmen, die historische Daemon-Architektur oder periphere Tools betreffen – und nicht die zugrunde liegenden technischen Grundprinzipien, die den dauerhaften Kern des Arguments bilden.
Die historische Linie der Containerisierung
Container sind nicht neu. Die populäre Erzählung, die ihren Ursprung in der Veröffentlichung von Docker im Jahr 2013 sieht, verschleiert eine vier Jahrzehnte lange Tradition, die sich wesentlich darauf auswirkt, wie die Technologie für den industriellen Einsatz bewertet werden sollte. Ausgereifte Technologie mit langer Tradition verdient einen anderen Beweisstandard als aufstrebende Technologie, und Container sind eindeutig erstere.
Die Abstammungslinie beginnt mit „chroot“, das 1979 in Version 7 Unix eingeführt wurde [6]. „chroot“ ermöglichte die Beschränkung eines Prozesses auf einen Teilbaum des Dateisystems, das erste weit verbreitete systematische Isolationsprimitiv auf Dateisystemebene. Seine Sicherheitsbeschränkungen wurden früh erkannt – „chroot“ wurde nie als Sicherheitsgrenze konzipiert –, aber es schuf die konzeptionelle Grundlage für die Dateisystemvirtualisierung.
FreeBSD Jails [7], im Jahr 2000 von Poul-Henning Kamp und Robert Watson auf Wunsch eines Hosting-Anbieters eingeführt, erweiterten „Chroot“ um Prozess- und Netzwerkisolation und erzeugten so etwas, das erkennbar als Container im modernen Sinne galt. Gefängnisse wurden von Anfang an als Sicherheitsgrenzen konzipiert und werden seit fast einem Vierteljahrhundert in der Produktion eingesetzt. Ihre Einführung in Netzwerk-Appliances – pfSense, opnSense, NetApp – bietet eine lange Erfolgsgeschichte von Containern in geschäftskritischen Rollen.
Solaris Zones [8] wurde 2004 veröffentlicht und bot eine kommerzielle Containerisierung mit starken Isolationsgarantien, war in die Solaris Service Management Facility integriert und wurde vom Start an in der Unternehmensproduktion eingesetzt. Die technischen Investitionen von Sun Microsystems in Zones waren beträchtlich, und die Technologie wurde in Umgebungen – Telekommunikationsschaltern, Finanztransaktionssystemen – eingesetzt, die mindestens genauso kritisch waren wie typische industrielle Einsätze.
Linux-Container (LXC) [9], die etwa ab 2008 aufkamen, brachten über die oben besprochenen Namespaces und cgroups-Primitive Container-Funktionalität nach Linux. LXC war der direkte technische Vorgänger von Docker; Die frühen Versionen von Docker waren praktisch eine Entwicklererfahrungsschicht über LXC.
Der Beitrag von Docker im Jahr 2013 war keine technische Neuheit im Sinne des Kernels. Die Namensräume existierten schon seit Jahren; cgroups wurden 2007 zusammengeführt. Dockers Beitrag war das Image-Format, das Registrierungsprotokoll und eine Entwicklererfahrung, die die vorhandenen Kernel-Grundelemente für normale Anwendungsentwickler zugänglich machte. Die Technologie war 35 Jahre alt, als Docker sie nutzbar machte.
Googles Borg-System [10], der Vorläufer von Kubernetes, betrieb seit etwa 2003 – ein Jahrzehnt bevor Docker existierte – die gesamte Produktionsflotte von Google auf Containern. Als Docker 2014 die Version 1.0 erreichte, betrieb Google Milliarden von Containern pro Woche. Das Argument, dass sich die Containertechnologie in der Massenproduktion nicht bewährt hat, steht im Widerspruch zu dieser empirischen Bilanz.
Für die industrielle Einführung ist die relevante Frage nicht, ob die Technologie ausgereift ist – was offensichtlich der Fall ist –, sondern ob die branchenspezifischen Einsatzmuster ausgereift sind. Diese Frage wird in Abschnitt 6 behandelt.
Das Problem der industriellen Softwarebereitstellung
Um Container in der Industrie durchzusetzen, muss das Problem, das Container lösen, genau beschrieben werden. Die industrielle Softwarebereitstellung war in der Vergangenheit von einer Reihe von Pathologien betroffen, die nicht zufällig mit dem industriellen Kontext zusammenhängen, sondern direkt auf dessen strukturelle Merkmale zurückzuführen sind.
Lange Gerätelebenszyklen führen zu Abhängigkeitsdrift. Eine im Jahr 2010 eingesetzte Industriesteuerung ist möglicherweise auch im Jahr 2030 noch betriebsbereit – eine Lebensdauer von zwei Jahrzehnten. Die Softwareumgebung von 2010 ist jedoch nicht die Softwareumgebung von 2030. Bibliotheksversionen, Compiler-Toolchains, Laufzeitinterpreter und Betriebssystemkerne entwickeln sich alle weiter. Die herkömmliche Reaktion – den gesamten Stack zum Zeitpunkt der Bereitstellung einfrieren – erzeugt ein nicht wartbares Artefakt: Der Controller kann seine ursprüngliche Software ausführen, kann jedoch nicht sicher aktualisiert, gepatcht oder geändert werden, ohne dass das Risiko besteht, dass Abhängigkeiten auf unvorhersehbare Weise unterbrochen werden. Dies ist das Problem der Abhängigkeitsdrift.
Heterogene Bereitstellungsziele vervielfachen die Integrationskomplexität. Eine industrielle Software muss möglicherweise auf einem halben Dutzend Zielplattformen ausgeführt werden: verschiedene SoC-Architekturen, verschiedene Linux-Distributionen, verschiedene Kernel-Versionen, verschiedene Glibc-Versionen. Die Kombinatorik, jede Softwareänderung auf jeder Zielplattform zu testen, ist ohne eine starke Isolierung zwischen der Anwendung und ihrer Hostumgebung unlösbar. Ohne Isolation müssen Integrationstests umfassend sein; Bei Isolation kann es selektiv sein.
Update-Mechanismen waren in der Vergangenheit fragil. Das herkömmliche industrielle Update – ein Firmware-Image, das auf einen Flash-Speicher geflasht wird, wobei für das Rollback normalerweise physischer Zugriff erforderlich ist – unterstützt nicht die granularen, häufigen und beobachtbaren Updates, die moderne Sicherheitsmaßnahmen erfordern. Kritische Schwachstellen treten jetzt auf und erfordern Patches innerhalb von Tagen bis Wochen; Industrielle Firmware-Aktualisierungszyklen, die in Monaten oder Jahren gemessen werden, sind für Bedrohungsmodelle zunehmend unzureichend.
Reproduzierbarkeit ist betrieblich wichtig, aber technisch schwer zu erreichen. Wenn ein Industriesystem ausfällt, erfordert der Diagnoseprozess die Reproduktion des Fehlers in einer kontrollierten Umgebung. Wenn die Softwareumgebung des Produktionssystems nicht exakt reproduziert werden kann – weil sie aus einer bestimmten Kombination von Bibliotheksversionen, Konfigurationsdateien und Laufzeitstatus erstellt wurde, die niemand vollständig dokumentiert hat – wird die Diagnose zur Archäologie. Dies ist die Reproduzierbarkeitskrise, die auf Industriesoftware angewendet wird und die Branche viel Zeit bei der Reaktion auf Vorfälle gekostet hat.
Die Grenze zwischen Anwendung und Betriebssystem ist verschwunden. Moderne Industrieanwendungen hängen von einem wesentlichen Teil der Betriebsumgebung ab: bestimmte Bibliotheken, bestimmte Kernelmodule, bestimmte Systemd-Einheiten, bestimmte Dateisystemlayouts. Das historische Modell – „Stellen Sie die Anwendung bereit, das Betriebssystem ist das Problem eines anderen“ – entspricht nicht der betrieblichen Realität, in der Anwendungen und ihre Abhängigkeiten miteinander verknüpft sind und gemeinsam bereitgestellt werden müssen.
Jede dieser Pathologien kann im Prinzip allein durch sorgfältige technische Disziplin bekämpft werden. In der Praxis zeigt die empirische Bilanz industrieller Software, dass die Ingenieursdisziplin allein nicht ausreicht, da die Pathologien strukturell durch die Lücke zwischen der Anwendung und ihrer Umgebung entstehen. Container schließen diese Lücke, indem sie die Anwendung zusammen mit ihren Abhängigkeiten als ein einziges unveränderliches Artefakt bereitstellen. Dies ist keine stilistische Präferenz; Es ist eine strukturelle Lösung für ein strukturelles Problem.
Der positive Fall
Nachdem das Problem beschrieben wurde, kann die Verwendung von Containern in Industriesoftware aus sechs Gründen befürwortet werden.
Container suitability for industrial software criteria
bar chart4.1 Kryptografische Reproduzierbarkeit
Das durch einen bestimmten SHA-256-Digest identifizierte Bild ist auf jedem Host, der es abruft, bitidentisch. Dies ist eine stärkere Garantie als jeder herkömmliche Bereitstellungsmechanismus. Wenn in der Produktion ein Vorfall auftritt, kann die genaue Softwareumgebung, in der der Vorfall aufgetreten ist, mit mathematischer Sicherheit reproduziert werden – auf einer Entwickler-Workstation, in einer Testumgebung, in einer behördlichen Prüfung.
Der diagnostische Wert dieser Garantie kann kaum hoch genug eingeschätzt werden. Die Kosten für „nicht reproduzierbare“ Diagnosen bei der Reaktion auf industrielle Vorfälle sind nach Erfahrung jedes Praktikers erheblich. Durch die kryptografische Reproduzierbarkeit wird dieser Fehlermodus für die Softwareschicht eliminiert, sodass nur die wirklich schwer zu reproduzierenden Umgebungsfaktoren – Sensorrauschen, elektromagnetische Interferenzen, mechanischer Verschleiß – als verbleibende Ursachen für Nichtreproduzierbarkeit übrig bleiben.
Die gleiche Garantie unterstützt Compliance und Audit. Wenn bei einem industriellen Einsatz aus regulatorischen Gründen nachgewiesen werden muss, dass es sich bei der im Feld ausgeführten Software genau um die Software handelt, die validiert und genehmigt wurde, liefert der Image Digest diesen Nachweis in einer Form, die kryptografisch Manipulationen widersteht.
4.2 Atomare Bereitstellung und Rollback
Herkömmliche Industrie-Updates haben die Eigenschaft, dass sie nicht einfach zurückgesetzt werden können. Ein Firmware-Update, das sich in der Produktion als problematisch erweist, erfordert entweder physischen Zugriff zum erneuten Flashen oder einen komplexen Update-Mechanismus, der A/B-Partitionen und explizite Rollback-Unterstützung umfasst – und selbst diese Mechanismen sind auf Firmware-Ebene typischerweise alles oder nichts.
Die Containerbereitstellung erfolgt atomar auf der Granularität der einzelnen Arbeitslast. Ein neues Container-Image wird abgerufen, validiert und gestartet; Das alte Bild wird gestoppt. Wenn das neue Image eine seiner Integritätsprüfungen nicht besteht, wird der Übergang rückgängig gemacht. Der Systemstatus am Ende einer fehlgeschlagenen Bereitstellung ist identisch mit dem Status zu Beginn der Bereitstellung.
Diese Eigenschaft hat erhebliche betriebliche Konsequenzen. Es ermöglicht aggressive Aktualisierungsrhythmen ohne proportionale Erhöhung des Betriebsrisikos. Es ermöglicht Canary-Bereitstellungen – das Testen eines neuen Images auf einer Teilmenge der Flotte vor der breiteren Einführung. Es ermöglicht ein automatisiertes Rollback als Reaktion auf Telemetriesignale. Keines dieser Muster ist mit herkömmlichen Firmware-Update-Mechanismen realisierbar.
4.3 Abhängigkeitsisolierung
Jeder Container trägt seine eigenen Abhängigkeiten. Zwei Container auf demselben Host hängen möglicherweise von inkompatiblen Versionen derselben Bibliothek ab und beide funktionieren ordnungsgemäß. Das Host-Betriebssystem muss nur den Kernel bereitstellen; Die Userspace-Abhängigkeiten sind im Image gekapselt.
Die industrielle Bedeutung dieser Eigenschaft besteht darin, dass ein Industrie-Gateway mehrere Anwendungen hosten kann – möglicherweise von verschiedenen Anbietern entwickelt, möglicherweise zu unterschiedlichen Zeiten bereitgestellt, möglicherweise abhängig von unterschiedlichen Versionen gemeinsamer Bibliotheken – ohne die Integrationskomplexität, die in der Vergangenheit mit einer solchen gemeinsamen Residenz einherging. Bei der Bereitstellung einer neuen Anwendung besteht kein Risiko, dass bestehende Anwendungen beschädigt werden, da die Abhängigkeiten nicht interagieren.
Dies ist die strukturelle Voraussetzung für das Anwendungsmarktplatzmodell, das seit mehreren Jahrzehnten mit begrenztem Erfolg für Industriesteuerungen versucht wird. Die Container-basierte Anwendungsverteilung macht den Markt machbar, da das Integrationsproblem – historisch gesehen das Haupthindernis – größtenteils gelöst ist.
4.4 Workload-Portabilität
Ein Container-Image, das in der lokalen Umgebung eines Entwicklers ausgeführt wird, läuft mit hoher Wiedergabetreue auf einem Produktions-Gateway. Dasselbe Image läuft auf einem x86-Server in einem Rechenzentrum oder auf einem ARM-basierten Industrie-Gateway, wenn ein Image mit mehreren Architekturen vorliegt. Die Ausführungsumgebung ist in allen Bereitstellungskontexten weitgehend invariant.
Diese Portabilität hat zwei wichtige Konsequenzen für Industriesoftware. Erstens beseitigt es eine erhebliche Klasse von Integrationsfehlern – solche, die durch Unterschiede zwischen Entwicklungs- und Produktionsumgebungen verursacht werden. Zweitens macht es die Grenze zwischen Cloud und Edge zu einer Bereitstellungsentscheidung und nicht zu einer Architekturentscheidung. Die gleiche Arbeitslast kann an beiden Standorten ausgeführt werden, und der Standort kann ohne Codeänderung geändert werden. Dies ist die praktische Voraussetzung für das Edge-Cloud-Co-Design [11], bei dem Workloads je nach betrieblichem Bedarf zwischen den Ebenen migrieren.
4.5 Sicherheitsverbesserungen gegenüber der Bare-Metal-Bereitstellung
Ein häufiges Missverständnis geht davon aus, dass Container eine schwächere Sicherheitsgrenze darstellen als virtuelle Maschinen und daraus der Schluss gezogen wird, dass Container eine Sicherheitsregression darstellen. Der Vergleich ist richtig, aber die Schlussfolgerung ist falsch, denn der relevante Vergleich ist nicht Container vs. VM, sondern Container vs. kein Container – das heißt, die historische Alternative zur containerisierten industriellen Bereitstellung ist nicht die virtualisierte Bereitstellung; Es handelt sich um eine Bare-Metal-Bereitstellung ohne Isolation.
Im Vergleich zu dieser historischen Ausgangslage sind Container eindeutig eine Verbesserung. Sie bieten:
Die NIST-Sonderveröffentlichung 800-190 [12] bietet eine maßgebliche Referenz für die Konfiguration der Containersicherheit in regulierten Umgebungen. Richtig konfigurierte Container mit Rootless-Ausführung, Capability-Drop, Seccomp-Filterung und Image-Scanning stellen eine wesentlich stärkere Sicherheitslage dar als die Bare-Metal-Industriebereitstellungen, die sie ersetzen.
Die berechtigte Sorge – dass der Kernel eine größere Angriffsfläche als ein Hypervisor darstellt – gilt unter bestimmten Umständen und wird in Abschnitt 5 behandelt.
- Prozessisolation über Namespaces, um versehentliche oder böswillige Eingriffe zwischen koresidenten Anwendungen zu verhindern.
- Ressourcenbeschränkungen über Kontrollgruppen, um zu verhindern, dass eine einzelne Anwendung die Hostressourcen erschöpft.
- Fähigkeitsverlust, wodurch gefährliche Linux-Funktionen standardmäßig aus Containerprozessen entfernt werden.
- Schreibgeschützte Root-Dateisysteme, wodurch eine wichtige Klasse der Persistenz nach der Ausnutzung eliminiert wird.
- Seccomp-Filter, die die für einen Containerprozess verfügbaren Systemaufrufe einschränken.
- AppArmor- und SELinux-Integration, die obligatorische Zugriffskontrollen bietet.
4.6 Operative Konvergenz mit moderner Softwarepraxis
Das letzte Element des positiven Falls ist vielleicht das folgenreichste, obwohl es am schwierigsten zu quantifizieren ist. Container bringen Industriesoftware in die gleiche operative Toolchain wie die breitere Softwareindustrie. Die Continuous-Integration-Pipelines, die Supply-Chain-Sicherheitstools, die Observability-Stacks, die Deployment-Automatisierungssysteme – sie alle sind Container-nativ.
Dies bedeutet, dass die industrielle Softwareentwicklung auf dem breiteren Arbeitsmarkt für Softwareentwicklung rekrutieren, im Hyperscaler-Maßstab validierte Praktiken und Tools übernehmen und sich ohne maßgeschneiderte Anpassung in das Cloud-native Ökosystem integrieren kann. Die historische Isolation der industriellen Softwareentwicklung vom breiteren Software-Ökosystem – mit den damit einhergehenden Talentengpässen, Werkzeuglücken und Sicherheitsdefiziten – wird durch die Einführung von Containern aufgelöst.
Dieser Effekt ist strukturell und langfristig. Die Folgen werden sich über ein Jahrzehnt oder länger auswirken, aber die Richtung ist klar: Die industrielle Softwareentwicklung ist in Werkzeugen und Praxis nicht mehr von der modernen Anwendungsentwicklung zu unterscheiden.
Konfrontation mit den Einwänden
Eine ernsthafte Interessenvertretung muss sich mit den stärksten Formen der Einwände auseinandersetzen, mit denen sie konfrontiert wird, nicht mit den schwächsten. In diesem Abschnitt werden die vier am häufigsten vorgebrachten Einwände gegen die industrielle Containerisierung behandelt.
5.1 Der Echtzeit-Leistungseinwand
Container führen zu nicht deterministischer Planung und Ressourcenkonflikten, die sie von industriellen Echtzeit-Workloads ausschließen.
Der Einwand ist in seiner schärfsten Form berechtigt, aber die Form, in der er normalerweise vorgebracht wird, ist zu pauschal. Industrielle Echtzeit-Workloads sind nicht monolithisch; Sie reichen von harter Echtzeit-Bewegungssteuerung (Fristen in Mikrosekunden, verpasste Frist entspricht Sicherheitsvorfall) über weiche Echtzeit-Prozesssteuerung (Fristen in Dutzenden von Millisekunden, gelegentliche Fehlschläge tolerierbar) bis hin zu Nicht-Echtzeit-Analysen (keine Frist).
Für harte Echtzeit-Workloads sind Container zwar ungeeignet – herkömmliches Linux jedoch auch. Harte Echtzeit unter Linux erfordert einen Kernel, der mit PREEMPT_RT [13] oder gleichwertig gepatcht ist, eine sorgfältige CPU-Affinität, die Isolierung von Echtzeitkernen vom Scheduler und den Ausschluss von Nicht-Echtzeit-Workloads aus der Echtzeitdomäne. Diese Anforderungen gelten unabhängig von der Containerisierung. Ein ordnungsgemäß konfiguriertes Echtzeit-Linux-System kann Echtzeit-Workloads in Containern mit vollständiger Echtzeitgarantie hosten, sofern die Konfigurationsdisziplin eingehalten wird.
Quantitative Messungen belegen dies. Benchmarks von containerisierten Echtzeit-Workloads auf PREEMPT_RT Linux [14] zeigen einen Latenz-Overhead im niedrigen Mikrosekundenbereich im Vergleich zur Bare-Metal-Ausführung – deutlich innerhalb der Toleranz selbst anspruchsvoller industrieller Workloads. Der Overhead entsteht größtenteils durch die Cgroup-Abrechnung, die selektiv für Echtzeit-Cgroups deaktiviert werden kann, bei denen deterministische Latenz wichtiger ist als eine feinkörnige Ressourcenabrechnung.
Für weiche Echtzeit- und Nicht-Echtzeit-Workloads – die den Großteil der Industriesoftware ausmachen – verursachen Container einen Overhead in der Größenordnung von 1–3 % für CPU-gebundene Workloads und einen statistisch vernachlässigbaren Overhead für I/O-gebundene Workloads. Dies stellt kein ernsthaftes Hindernis dar.
5.2 Der Einwand der Sicherheitsgrenze
Container-Escape-Schwachstellen werden regelmäßig entdeckt; Container können als Sicherheitsgrenze für hochwertige industrielle Workloads nicht vertrauenswürdig sein.
Der Einwand vereint zwei unterschiedliche Ansprüche. Das erste – dass Container-Escape-Schwachstellen bestehen – ist wahr. Der zweite Punkt – dass dies Container von der industriellen Nutzung ausschließt – folgt nicht, da es auch Fluchtmöglichkeiten für virtuelle Maschinen gibt und Bare-Metal-Bereitstellungen überhaupt keine Grenzen für die Flucht haben. Die relevante Frage ist die Sicherheitslage im Verhältnis zu Alternativen, nicht im Verhältnis zur Perfektion.
Die historische Aufzeichnung von Container-Escape-Schwachstellen ist aufschlussreich. Die wichtigsten CVEs – runc CVE-2019-5736, Dirty Pipe CVE-2022-0847, CVE-2024-0132 im NVIDIA Container Toolkit – wurden jeweils innerhalb weniger Tage nach der Offenlegung gepatcht und innerhalb weniger Wochen im Ökosystem verbreitet. Das Expositionsfenster für ordnungsgemäß gewartete Systeme war kurz.
Für Workloads, die eine Isolierung auf Hypervisor-Niveau erfordern, bieten leichte VM-basierte Containerlaufzeiten – Kata Containers [15], Firecracker [16], gVisor [17] – diese unter Beibehaltung der Containerschnittstelle. Diese Technologien ermöglichen eine Hybridbereitstellung, bei der die meisten Arbeitslasten in herkömmlichen Containern ausgeführt werden, während besonders sensible Arbeitslasten in Mikro-VMs ausgeführt werden, die alle von derselben Orchestrierungsebene verwaltet werden.
Die ernsthafte Sicherheitsherausforderung für die industrielle Containerisierung ist nicht die Angriffsfläche des Kernels; es ist die Lieferkette. Ein Container-Image, das aus nicht vertrauenswürdigen Basis-Images, aus Paketen aus kompromittierten Repositorys und aus Build-Pipelines ohne Herkunft erstellt wurde, ist ein Gefährdungsvektor, den die Container-Isolation nicht beheben kann. Die Antwort auf diese Herausforderung – auf die in Abschnitt 6 eingegangen wird – ist die Einführung von Sicherheits-Frameworks für die Lieferkette wie SLSA [18] und der Verteilung signierter Bilder über Sigstore [19].
5.3 Der Stateful Workload-Einwand
Container wurden für zustandslose Workloads konzipiert. Industrielle Anwendungen sind zutiefst zustandsbehaftet, und wenn sie in ein zustandsloses Modell gezwungen werden, entstehen schlechte Architekturen.
Die Prämisse ist teilweise richtig – die frühen Leitlinien für Container betonten zwar die Staatenlosigkeit –, die Schlussfolgerung ist es jedoch nicht. Das Containermodell berücksichtigt zustandsbehaftete Arbeitslasten durch Volume-Mounts, persistente Volumes in orchestrierten Umgebungen und explizite Datenverwaltungsprimitive. Die erforderliche Disziplin besteht darin, den Status extern adressierbar und explizit zu verwalten, anstatt ihn im Laufzeitspeicher der Anwendung implizit zu speichern.
Diese Disziplin ist tatsächlich ein Vorteil für industrielle Anwendungen und kein Kostenfaktor. Eine zustandsbehaftete Industrieanwendung, deren Zustand implizit, undokumentiert und mit dem Laufzeitspeicher verknüpft ist, ist genau die Art von Anwendung, die weder debuggt noch migriert werden kann und deren Wiederherstellung nach einem Ausfall unmöglich ist. Der Containerisierungsprozess erzwingt die Externalisierung und explizite Verwaltung des Zustands – wodurch Anwendungen entstehen, die robuster und nicht weniger widerstandsfähig sind.
Für wirklich zustandsbehaftete industrielle Workloads – historische Datenbanken, Kalibrierungsdaten, Konfigurationsspeicher – bietet das Container-Ökosystem ausgereifte Tools: persistente Volumes mit geeigneter Dateisystemunterstützung, Operatormuster für die Verwaltung von Datenbanklebenszyklen und in die Speicherschicht integrierte Sicherungsprimitive.
5.4 Der Einwand der betrieblichen Komplexität
Container-Orchestrierung führt zu betrieblicher Komplexität, auf deren Bewältigung OT-Teams nicht vorbereitet sind. Die Alternative – einfache Firmware-Updates – ist betrieblich einfacher, wenn auch technisch minderwertig.
Der Einwand hat erhebliche empirische Unterstützung. Kubernetes wird allgemein als betrieblich komplex angesehen und die für den Betrieb erforderlichen Fähigkeiten sind in OT-Teams normalerweise nicht vorhanden.
Zwei Bemerkungen relativieren den Einwand jedoch. Erstens ist für die Containerbereitstellung kein Kubernetes erforderlich. Für industrielle Einzelknotenbereitstellungen – die die überwiegende Mehrheit der Edge-Gateway-Szenarien beschreiben – bieten Docker Compose, Podman oder von Systemd verwaltete Containereinheiten eine Betriebsoberfläche, deren Komplexität mit der herkömmlichen Serviceverwaltung vergleichbar ist. Der vollständige Orchestrierungsstapel wird nur für Bereitstellungen im Flottenmaßstab benötigt, und in diesem Maßstab wird die Komplexität der Orchestrierung durch die betrieblichen Vorteile ausgeglichen.
Zweitens hat die leichte Orchestrierung – K3s [20], KubeEdge [21], MicroK8s – die betriebliche Komplexität für Edge-Bereitstellungen im Flottenmaßstab erheblich reduziert. Das historische Komplexitätsprofil von Kubernetes spiegelt seine Ursprünge in Hyperscaler-Workloads wider; Die Lightweight-Varianten sind explizit für die betrieblichen Gegebenheiten des Edge-Einsatzes konzipiert.
Die tiefere Antwort auf den Einwand der betrieblichen Komplexität besteht darin, dass die betriebliche Komplexität von nicht-containerisierter Industriesoftware jahrzehntelang unterschätzt wurde. Die undokumentierten Abhängigkeiten, die nicht reproduzierbaren Vorfälle, die Bereitstellungsprozesse, die nur als Stammwissen in den Köpfen bestimmter Ingenieure existieren – das sind Formen betrieblicher Komplexität, die nicht gemessen werden, weil sie nicht sichtbar sind. Die sichtbare Komplexität der Container-Orchestrierung ersetzt die unsichtbare Komplexität, die immer vorhanden war. Ob es sich dabei um eine Nettozunahme oder -abnahme der betrieblichen Belastung handelt, hängt von der konkreten Bereitstellung ab, aber die Annahme, dass die nicht-containerisierte Basislinie betrieblich einfach ist, hält einer Prüfung nicht stand.
Architekturmuster für den industriellen Einsatz
Der Übergang von der theoretischen Vertretbarkeit zur umsetzbaren Praxis hängt von der Reife der Architekturmuster ab. Die Muster, die sich bei industriellen Einsätzen in der Produktion herausgebildet haben, bedürfen einer ausführlichen Beschreibung.
6.1 Single-Node-Gateway-Bereitstellung
Das häufigste Muster ist das Single-Node-Gateway: ein industrielles Gateway, auf dem eine kleine Anzahl von Containeranwendungen ausgeführt wird, wobei Docker Compose oder von Systemd verwaltete Containereinheiten die Orchestrierungsoberfläche bereitstellen. Aktualisierungen werden aus einer zentralen Registrierung abgerufen, optional nach einem Zeitplan, der durch eine Watchtower-ähnliche Abgleichsschleife definiert wird. Der Status wird auf lokalen Volumes gespeichert und in der zentralen Infrastruktur gesichert.
Die Stärke dieses Musters liegt in der einfachen Bedienung. Die Schwäche besteht darin, dass das Flottenmanagement nicht direkt unterstützt wird – jedes Gateway wird unabhängig verwaltet. Für den Einsatz von Dutzenden bis wenigen Hunderten von Gateways ist dies akzeptabel. Für größere Flotten ist das nächste Muster besser geeignet.
6.2 Orchestrierung im Flottenmaßstab
Für flottengroße Bereitstellungen sorgen schlanke Kubernetes-Distributionen (K3s, KubeEdge) für die Orchestrierung in der gesamten Flotte. Jedes Gateway wird zu einem Knoten – entweder als Einzelknoten-Cluster oder als Worker-Knoten in einem größeren Cluster – und Arbeitslasten werden über Standard-Kubernetes-Tools geplant, aktualisiert und überwacht.
Die Stärke des Musters liegt im Flottenmanagement mit einem ausgereiften Ökosystem. Seine Schwäche ist die in Abschnitt 5.4 diskutierte betriebliche Komplexität, die das Muster nur in ausreichendem Maßstab rechtfertigt.
6.3 GitOps für Edge-Konfiguration
In beiden Mustern wird die Konfiguration der Gateways – welche Container ausgeführt werden, welche Images bereitgestellt werden, welche Ressourcen zugewiesen werden – deklarativ in einem versionierten Repository beschrieben. Ein Abstimmungscontroller (Flux, Argo CD, Fleet), der auf dem Gateway oder auf einem Controller in der Cloud läuft, beobachtet die Lücke zwischen beobachtetem und gewünschtem Zustand und wendet die erforderlichen Änderungen an, um diese zu schließen.
Die Stärke dieses Musters liegt in der Überprüfbarkeit und Atomizität auf Flottenebene. Der vollständige Verlauf der Flottenkonfiguration wird in Git erfasst. Rollback ist eine Git-Operation. Das Muster wurde nahezu unverändert aus Cloud-nativen Vorgängen übernommen und lässt sich gut auf den Rand übertragen.
6.4 Sicherheit der Lieferkette
Bei industriellen Einsätzen ist die Sicherheit der Lieferkette von Container-Images von entscheidender Bedeutung. Das ausgereifte Muster umfasst:
Dies ist für industrielle Einsätze nicht optional. Die Supply-Chain-Angriffe, die in den letzten fünf Jahren auf Softwarepaketierungs-Ökosysteme stattgefunden haben – SolarWinds, die verschiedenen NPM- und PyPI-Kompromittierungen – zeigen, dass die Bedrohung real und die Abwehrmaßnahmen notwendig sind.
- Imageaufbau in einer vertrauenswürdigen CI-Infrastruktur mit dokumentierter Herkunft (SLSA-Framework [18])
- Bildsignierung mit Sigstore [19] oder gleichwertig
- Provenienznachweis gemäß Gesamtspezifikation [22]
- Software-Stücklistenerstellung nach SPDX [23] oder CycloneDX
- Kontinuierliches Schwachstellenscannen mit Trivy, Grype oder kommerziellen Äquivalenten
- Zugangskontrolle auf Gateway-Ebene, die nicht signierte oder anfällige Bilder ablehnt
6.5 Hardware-Zugriffsmuster
Industrielle Workloads erfordern häufig Zugriff auf physische Hardware: serielle Ports, GPIO-Pins, CAN-Busse, industrielle Feldbusse, GPU-Beschleuniger. Das Containermodell berücksichtigt dies durch Geräte-Cgroups und explizite Geräte-Mounts.
Das disziplinierte Muster besteht darin, bestimmte Geräte bestimmten Containern zur Verfügung zu stellen, anstatt privilegierte Container mit vollem Hostzugriff auszuführen. Der Geräte-Cgroup-Controller des Kernels ermöglicht eine fein abgestimmte Zugriffskontrolle. udev-Regeln können physische Geräte stabilen Namen zuordnen, auf die Container verweisen. Für den GPU-Zugriff bieten das NVIDIA Container Toolkit und gleichwertige Produkte Hardwarezugriff ohne Rechteausweitung.
6.6 Echtzeit-Augmentation
Für Bereitstellungen mit Echtzeitanforderungen kombiniert das Muster einen PREEMPT_RT-Kernel, CPU-Isolierung über den Boot-Parameter „isolcpus“, dedizierte Echtzeit-Cgroups und sorgfältige Workload-Platzierung. Die Containerschnittstelle bleibt erhalten, der zugrunde liegende Scheduler ist jedoch für Echtzeit-Workloads konfiguriert.
Dabei handelt es sich um Ingenieursarbeit, nicht um ein Feature-Flag, sondern um gut dokumentierte Ingenieursarbeit [13][14], die Latenzprofile liefert, die den Anforderungen aller bis auf die anspruchsvollsten harten Echtzeit-Workloads gerecht werden.
Offene Probleme und verantwortungsvolle Übernahme
Die Argumente für die industrielle Containerisierung sind stark, aber nicht uneingeschränkt. Mehrere offene Probleme erfordern eine ausdrückliche Anerkennung.
Disziplin der Image-Größe. Container-Images wachsen durch angesammelte Abhängigkeiten, Debug-Tools und das Aufblähen des Basis-Images häufig auf Gigabyte an. Bei bandbreitenbeschränkten industriellen Einsätzen, bei denen der Bildabruf über Mobilfunk- oder Satellitenverbindungen erfolgt, ist dies betrieblich kostspielig. Disziplinierte Praktiken (distrolose Basisimages [24], mehrstufige Builds, sorgfältiges Abhängigkeitsmanagement) halten Produktionsimages für die meisten Arbeitslasten unter 100 MB, aber die Disziplin erfolgt nicht automatisch.
Kompetenzentwicklung. Das Container-Ökosystem setzt ein Maß an betrieblicher Komplexität voraus, das in Industrie-Engineering-Teams nicht einheitlich vorhanden ist. Um diese Lücke zu schließen, sind explizite Investitionen in Schulungen, in Tools, die die Betriebsoberfläche reduzieren, und in Muster erforderlich, die es OT-Teams ermöglichen, Container-Infrastruktur zu betreiben, ohne Kubernetes-Spezialisten zu werden.
Beobachtbarkeit im Flottenmaßstab. Telemetriedaten von tausend Container-Gateways erzeugen eigene Telemetriedaten. Die Auswahl, welche Metriken mit welcher Granularität ausgegeben werden sollen und wie sie aggregiert werden sollen, ist ein ungelöstes technisches Problem am Edge. OpenTelemetry [25] hat die Situation verbessert, aber kantenspezifische Muster sind nach wie vor unterentwickelt.
Langfristige Image-Bewahrung. Ein heute bereitgestelltes Container-Image muss auf der heute bereitgestellten Hardware lauffähig bleiben, und zwar in fünfzehn Jahren, nachdem die Registry, die das Image ursprünglich gehostet hat, den Besitzer gewechselt hat oder nicht mehr existiert. Industrielle Bereitstellungen erfordern eine explizite Image-Aufbewahrung – lokale Register, archivierte Images, dokumentierte Abhängigkeiten –, was nicht der Standardbetriebsmodus des breiteren Container-Ökosystems ist.
Hardware-Abstraktionsgrenzen. Einige industrielle Hardware – insbesondere FPGAs, spezielle I/O-Karten und Hardware mit proprietären Kernel-Treibern – abstrahiert nicht sauber in das Containermodell. Bei diesen Workloads erfolgt die Containerisierung nur teilweise: Die Userspace-Komponente wird in Containern gespeichert, während der Kernel-Treiber ein Problem auf Hostebene bleibt. Dies ist akzeptabel, führt jedoch zu einer Kopplung, die durch eine disziplinierte Bereitstellung explizit verwaltet werden muss.
Diese Probleme sind real und erfordern fortlaufende technische Investitionen. Sie machen den positiven Fall nicht ungültig; sie qualifizieren es.
Schlussargument
Das Argument lässt sich kompakt formulieren. Industriesoftware litt in der Vergangenheit unter einem strukturellen Problem: Die Lücke zwischen Anwendung und Betriebsumgebung ist unkontrolliert, was zu Abhängigkeitsdrift, Reproduzierbarkeitsfehlern, Sprödigkeit bei der Bereitstellung und schwer zu verteidigenden Sicherheitsvorkehrungen führt. Container schließen diese Lücke, indem sie die Anwendung zusammen mit ihren Abhängigkeiten als kryptografisch reproduzierbares, atomar aktualisierbares und isolierbares Artefakt bereitstellen. Die Technologie ist in ihren konzeptionellen Grundlagen vier Jahrzehnte alt, basiert auf offenen Standards und ist im Hyperscaler-Maßstab betriebsvalidiert. Die gegen die industrielle Einführung vorgebrachten Einwände sind real, aber nachvollziehbar – sie identifizieren technische Probleme mit bekannten Lösungen, nicht strukturelle Inkompatibilitäten.
Die strukturelle Alternative zur Containerisierung ist die Fortsetzung der historischen Praxis: maßgeschneiderte Bereitstellung pro Plattform, nicht reproduzierbare Produktionsumgebungen, spröde Update-Mechanismen und betriebliche Isolation vom breiteren Software-Ökosystem. Diese Alternative ist kein stabiles Gleichgewicht. Es handelt sich um den Status quo, dessen Grenzen inzwischen so deutlich sichtbar sind, dass sich die Branche davon entfernt, und die Frage ist nicht, ob man Container einführen soll, sondern wie man sie gut einführen kann.
Die folgende Empfehlung ist direkt. Industrielle Produktlinien sollten von Anfang an für den Containereinsatz konzipiert sein. Die erforderlichen Investitionen – in die Sicherheit der Lieferkette, in Observability-Tools, in die Kompetenzentwicklung, in die Disziplin der Bildbewahrung – sollten explizit geplant und budgetiert werden. Die in Abschnitt 6 beschriebenen Muster sollten übernommen, angepasst und weiterentwickelt werden, wenn die Praxis ausgereift ist.
Die Alternative besteht darin, in einem architektonischen System zu bleiben, das nicht mehr lebensfähig ist. Der Übergang wird nicht kostenlos sein. Es wird wesentlich weniger kostspielig sein, als es nicht zu schaffen.
References
[1] S. Hykes. „Die Zukunft der Linux-Container.“ PyCon US, 2013.
[2] E. W. Biederman. „Mehrere Instanzen der globalen Linux-Namespaces.“ Linux-Symposium, 2006.
[3] P. B. Menage. „Hinzufügen generischer Prozesscontainer zum Linux-Kernel.“ Linux-Symposium, 2007.
[4] N. Brown. „Overlay-Dateisystem.“ Linux-Kernel-Dokumentation, 2014.
[5] Open-Container-Initiative. Laufzeitspezifikation, Bildspezifikation und Verteilungsspezifikation. 2017–heute. https://opencontainers.org
[6] D. M. Ritchie und K. Thompson. Unix Programmer's Manual, Siebte Auflage. Bell Laboratories, 1979.
[7] P.-H. Kamp und R. N. M. Watson. „Gefängnisse: Die allmächtige Wurzel begrenzen.“ Zweite Internationale SANE-Konferenz, 2000.
[8] D. Price und A. Tucker. „Solaris Zones: Betriebssystemunterstützung zur Konsolidierung kommerzieller Workloads.“ USENIX LISA, 2004.
[9] D. Lezcano et al. Linux Containers (LXC)-Projekt. 2008–heute. https://linuxcontainers.org
[10] A. Verma et al. „Groß angelegtes Clustermanagement bei Google mit Borg.“ EuroSys, 2015.
[11] B. Burns et al. „Borg, Omega und Kubernetes.“ Mitteilungen der ACM, 59(5), 2016.
[12] Nationales Institut für Standards und Technologie. Sicherheitsleitfaden für Anwendungscontainer. NIST-Sonderpublikation 800-190, 2017.
[13] T. Gleixner und I. Molnar. PREEMPT_RT: Echtzeit-Preemption-Patches für den Linux-Kernel. https://wiki.linuxfoundation.org/realtime/
[14] L. Abeni et al. „Containerbasierte Echtzeitplanung im Linux-Kernel.“ ACM SIGBED Review, 16(3), 2019.
[15] Kata Containers-Projekt. Kata Containers: Die Geschwindigkeit von Containern, die Sicherheit von VMs. https://katacontainers.io
[16] A. Agache et al. „Kracher: Leichte Virtualisierung für serverlose Anwendungen.“ USENIX NSDI, 2020.
[17] gVisor-Projekt. gVisor: Anwendungskernel für Container. Google, 2018. https://gvisor.dev
[18] Google et al. Lieferkettenebenen für Softwareartefakte (SLSA). Open Source Security Foundation, 2021–heute. https://slsa.dev
[19] Linux Foundation. Sigstore: Software-Signierung für jedermann. https://sigstore.dev
[20] Rancher Labs / SUSE. K3s: Lightweight Kubernetes. https://k3s.io
[21] CNCF. KubeEdge: Ein Kubernetes-natives Edge Computing Framework. https://kubeedge.io
[22] S. Torres-Arias et al. „in-toto: Bereitstellung von Farm-to-Table-Garantien für Bits und Bytes.“ USENIX-Sicherheit, 2019.
[23] Linux Foundation. SPDX-Spezifikation (Software Package Data Exchange). ISO/IEC 5962:2021.
[24] Google. Distroless-Containerbilder. https://github.com/GoogleContainerTools/distroless
[25] OpenTelemetry-Projekt. OpenTelemetry-Spezifikation. CNCF, 2019–heute. https://opentelemetry.io
[26] C. Fowler. „Müllt eure Server weg und verbrennt euren Code: Unveränderliche Infrastruktur und Wegwerfkomponenten.“ 2013.
[27] J. Cappos et al. „Überlebbarer Schlüsselkompromiss in Software-Update-Systemen.“ ACM CCS, 2010. (The Update Framework / TUF.)
[28] Internationale Elektrotechnische Kommission. IEC 62443-4-1: Anforderungen an den sicheren Produktentwicklungslebenszyklus. 2018.
[29] B. Cantrill und J. Bonwick. „Parallelität in der realen Welt.“ Mitteilungen der ACM, 51(11), 2008.
[30] M. Souppaya, J. Morello und K. Scarfone. NIST SP 800-204C: Implementierung von DevSecOps für eine Microservices-basierte Anwendung mit Service Mesh. 2022.
Dieser Artikel ist Teil der Modibus-Technikserie. Das Industrie-Gateway Modibus MB213 ist als erstklassige Container-Computing-Plattform konzipiert und unterstützt sofort Docker, Podman und leichtgewichtige Kubernetes-Distributionen mit Hardwarebeschleunigung, die über die in Abschnitt 6 beschriebenen Muster für Container-Workloads zugänglich ist. Für technische Diskussionen oder Plattformanfragen wenden Sie sich bitte an [info@modibus.com](mailto:info@modibus.com).