Der erste Teil dieses Beitrags behandelte, worum es sich bei Containern und Kubernetes handelt und warum sie sich gegenseitig ergänzen. In diesem zweiten Teil geht es darum, wie Unternehmen dies in der Fertigungspraxis umsetzen können: Wie unterscheidet sich eine Cloud-Native-Architektur von der Standard-IT? Wer übernimmt welche Verantwortlichkeiten, und welche technischen Entscheidungen sind am wichtigsten, wenn Kubernetes neben einer Produktionslinie statt in einem Rechenzentrum läuft?

Die Umstellung auf Kubernetes in industriellen Umgebungen ist nicht nur ein IT-Modernisierungsprojekt. Es ist ein Schritt in Richtung Software-Defined Automation, also die Entkopplung der Steuerungslogik von proprietärer Hardware, sodass dieselben Orchestrierungsmuster, die in der Cloud-Infrastruktur verwendet werden, Workloads am Edge, in der Fertigung und über Hunderte von Standorten hinweg verwalten können.

Herausforderungen für global agierende Fertigungsunternehmen

Fertigungsunternehmen stehen vor einer spezifischen Kombination aus Anforderungen: Sie benötigen Rechenleistung für Analyse- und Steuerungsaufgaben direkt an der Produktionslinie, müssen ihre Standorte gegen externe Bedrohungen wie Cyberangriffe absichern und gleichzeitig eine standortübergreifende Vernetzung ermöglichen, auch über Ländergrenzen hinweg.

Anders als betriebswirtschaftliche Software wird Fertigungssoftware nicht auf Standard-IT betrieben und stammt in der Regel nicht aus der Cloud-Native-Ära. Stattdessen handelt es sich um ältere Software mit teils jahrzehntelanger Wartungshistorie, die nicht mit Endnutzern, sondern mit Maschinen kommuniziert. Sie läuft in separaten, streng geschützten Netzwerken, die jederzeit stabil und betriebsbereit sein müssen. Jede Modernisierungsinitiative muss daher sowohl die Sicherheitsanforderungen der OT-Umgebung (Operational Technology) als auch die internen Compliance-Vorgaben berücksichtigen.

Kubernetes hat sich als Technologie etabliert, wenn eine einheitliche Schnittstelle zur Verwaltung aller erforderlichen Ressourcen über mehrere Standorte und Cloud-Anbieter hinweg benötigt wird. Fertigungsunternehmen benötigen eine Self-Service-Plattform, auf der sie Rechenleistung dort bereitstellen können, wo sie erforderlich ist, und die gleichzeitig eine einheitliche Ebene über alle Umgebungen bietet, während das Unternehmen eigene Rechenzentren an unterschiedlichen Standorten nutzt.

Praxisorientierter Architekturansatz: Edge-Native

Das folgende Architekturmuster zeigt, wie Unternehmen eine Cloud-native Lösung für die Fertigung aufbauen können, die auch bei Internetausfällen betriebsbereit bleibt. Grundlegende Infrastrukturdienste wie DHCP und DNS werden containerisiert und lokal vorgehalten, sodass der Cluster auch dann funktionsfähig bleibt, wenn die Verbindung zur Außenwelt unterbrochen ist.

Autonomie der lokalen Infrastruktur

Das Architekturdesign muss ‚Edge-Native‘ sein, das bedeutet: Die Cloud wird als optionale Erweiterung betrachtet, nicht als Betriebsvoraussetzung. Um einen Internetausfall oder eine sicherheitsbedingte Netzwerktrennung (etwa als Reaktion auf einen Cyberangriff) zu überstehen, muss der lokale Cluster seine Kerndienste eigenständig hosten. Dazu gehören neben CoreDNS (dem Kubernetes-Standard-DNS-Dienst) auch lokale Container-Registries, über die Images ohne externe Verbindung bezogen werden können. Wenn ein Fabrikstandort seine Verbindung verliert, muss die interne Orchestrierung weiterhin funktionieren und Workloads lokal neu bereitstellen können.

Hardware-Abstraktion in heterogenen Umgebungen

Industrielle Umgebungen sind herstellerübergreifend. Der beschriebene Architekturansatz nutzt ‚KubeVirt‘, um ältere Windows-basierte Automatisierungstools als virtuelle Maschinen neben modernen Linux-Containern auszuführen. KubeVirt ist ein CNCF-Projekt (Cloud Native Computing Foundation; Stand Ende des Jahres 2025: Incubating-Status mit beantragtem Graduation-Status und 41 dokumentierten Produktiv-Adoptern), das VMs (Virtuelle Maschinen) als Kubernetes-Ressourcen verwaltet und damit einen einheitlichen Betrieb von Container- und VM-Workloads auf derselben Plattform ermöglicht.

Darüber hinaus ermöglichen Kubernetes Device Plugins, physische Hardware, zum Beispiel PCIe-Feldbuskarten oder GPUs für die visuelle Inspektion, direkt in Container zu übergeben, ohne dass ein vollständiger Treiber-Stack im Container-Image enthalten sein muss.

Hinsichtlich Echtzeit-Anforderungen ist zu beachten: Für zeitkritische Workloads wie Soft-PLCs oder Feldbuskommunikation mit Anforderungen im Submillisekunden-Bereich bietet Standard-Kubernetes auf einem Standard-Linux-Kernel keine harten Echtzeit-Garantien. Hierfür ist entweder ein PREEMPT_RT-gepatchter Kernel oder eine spezialisierte industrielle Linux-Distribution erforderlich. Kubernetes übernimmt in solchen Architekturen die Orchestrierung und das Lifecycle-Management, die eigentliche Echtzeit-Ausführung erfolgt auf Kernel-Ebene.

GitOps für die globale Flotte

Die Verwaltung von Hunderten von weltweit verteilten Standorten erfordert ein Pull-basiertes GitOps-Modell, beispielsweise mit ArgoCD oder Flux (beide CNCF-Graduate-Projekte). Anstatt dass eine zentrale Instanz Updates aktiv auf Edge-Cluster überträgt, was bei Verbindungsausfällen fehlschlägt, ‚pullt‘ jeder Edge-Cluster seinen gewünschten Zustand eigenständig, sobald eine Verbindung verfügbar ist. Dieses Modell gewährleistet ‚eventual consistency‘ über eine globale Flotte von Standorten hinweg, ohne manuelle Eingriffe vor Ort.

Netzwerksicherheit: eBPF-basiertes Zero-Trust

Für die Netzwerksegmentierung innerhalb des Clusters haben sich eBPF-basierte Lösungen wie Cilium oder KubeArmor etabliert. Sie ermöglichen Zero-Trust-Richtlinien auf Kernel-Ebene: Jeder Container und jede VM kann nur mit explizit erlaubten Diensten kommunizieren, unabhängig davon, ob sie sich im selben Netzwerksegment befinden.

Dabei gilt ein wichtiger technischer Vorbehalt: eBPF ist Linux-spezifisch. Da in gemischten Umgebungen (Linux-Container + Windows-VMs via KubeVirt) nicht alle Workloads eBPF-fähig sind, muss die OT-Netzwerksegmentierung in der Praxis durch zusätzliche Schichten ergänzt werden, zum Beispiel durch VLAN-Trennung auf Switching-Ebene und klassische Firewall-Regeln zwischen OT- und IT-Netzwerken.

Converged Networking: Industrieprotokolle im Container-Umfeld

Viele Fertigungsumgebungen nutzen industrielle Echtzeit-Feldbusprotokolle wie Profinet oder Ethercat. Diese Protokolle haben strenge Latenzvorgaben: Ethercat arbeitet mit Mindestzykluszeiten von 100 Mikrosekunden, Profinet IRT mit unter einer Millisekunde.

Containerisierte Protokoll-Konverter eignen sich in diesem Kontext für die Daten-Gateway-Funktion, also die Übersetzung zwischen Feldbus-Protokollen und IT-seitigen Standards wie OPC UA oder MQTT. Sie sind nicht als Ersatz für den eigentlichen Echtzeit-Stack gedacht, der weiterhin spezialisierter Hardware und Kernel-Unterstützung bedarf.

Rollen und Verantwortlichkeiten

In einem auf Kubernetes basierenden Fertigungsmodell werden die Verantwortlichkeiten klar zwischen drei Rollen aufgeteilt.

• Platform Engineer (IT/OT-Architekt): Der Platform Engineer entwirft die digitale Fabrikinfrastruktur und betreut den Cluster-Lifecycle, vom automatisierten Rollout des Betriebssystems bis zur Kubernetes-Installation an mehreren hundert Standorten weltweit, ohne physisch vor Ort sein zu müssen.
  Zu seinen Aufgaben gehört das Setzen von Leitplanken per Policy-as-Code. Mit Tools wie Kyverno (CNCF-Graduate-Projekt) lassen sich Richtlinien als Kubernetes-native YAML-Ressourcen definieren. Zum Beispiel kann eine Policy verhindern, dass ein Automatisierungs-Pod unbegrenzt RAM anfordert und damit den Knoten destabilisiert. Kyverno agiert als dynamischer Admission Controller, das heißt: Jede Ressource wird beim Eingang in den Cluster gegen die definierten Regeln geprüft.
  Ebenfalls in diese Rolle fällt die Sicherheitsarchitektur: Zero-Trust-Netzwerkpolicies, Image-Signaturprüfung für die Software-Supply-Chain und die Segmentierung zwischen OT- und IT-Workloads.
• Automation Engineer (Entwickler): Der Automation Engineer entwickelt die Automatisierungslogik und verpackt sie in portable, reproduzierbare Einheiten. Helm-Charts ermöglichen es, dass dieselbe Qualitätskontrollanwendung in einer Fabrik in Deutschland und in den USA identisch ausgerollt wird, mit standortspezifischen Konfigurationsunterschieden über Values-Dateien, ohne dass der Chart selbst angepasst werden muss.
  Das Ressourcenmanagement liegt ebenfalls in dieser Rolle: Der Entwickler definiert CPU- und GPU-Anforderungen seiner Anwendung explizit als Kubernetes-Resource- Requests und -Limits. Das gibt dem Scheduler die Grundlage, Workloads auf geeigneter Hardware zu platzieren.
• Maintenance-Techniker (Site Ops): Der Maintenance-Techniker verwaltet die physische Realität am Standort. Node-Labels in Kubernetes müssen mit der realen Topologie übereinstimmen, beispielsweise location: assembly-line-4, damit der Scheduler Workloads gezielt auf die zugehörige Hardware platzieren kann.
  Im ‚Plug-and-Produce‘-Szenario bedeutet Disaster Recovery: Fällt ein Industrie-PC aus, wird die Hardware getauscht. Die Plattform erkennt den neuen Node und schiebt automatisch die korrekte Software darauf, ohne manuellen Eingriff in die Konfiguration.

Lokale Dashboards, etwa auf Basis von Grafana und Prometheus, zeigen dem Techniker, ob ein Container aufgrund eines fehlerhaften Sensors oder Kabels wiederholt neu startet, mit direktem Bezug zu physischen Geräten über die Node-Labels.

Datensouveränität und Persistenz

Neben den Rollen und Verantwortlichkeiten ist das zunehmend an Bedeutung gewinnende Thema Datensouveränität zu beachten. Lokale, persistente Volumes ermöglichen es hierbei, Telemetriedaten zunächst am Standort zu puffern. Die Synchronisation in die Cloud erfolgt nur bei Einhaltung von Compliance-Vorgaben und unter Berücksichtigung von Bandbreitenbeschränkungen, zum Beispiel in Niedriglastphasen oder bei expliziter Freigabe durch die Sicherheitsrichtlinie. Dieses Modell ist besonders in Jurisdiktionen relevant, die Datenlokalisierungsvorschriften unterliegen.

Fazit

Kubernetes im Fertigungsumfeld bedeutet nicht, die Cloud in die Fabrik zu verlegen. Es bedeutet, die Orchestrierungsprinzipien der Cloud, nämlich deklarative Konfiguration, Self-Healing, GitOps und Policy-as-Code, in eine Umgebung zu bringen, die offlinefähig, gehärtet und auf industrielle Hardware ausgerichtet ist.

Der Autor: Tobias Schneck ist Principal Architect bei Kubermatic. © Kubermatic

Die wichtigsten Eigenschaften einer solchen Architektur:

• Autonomiefähigkeit: Der Cluster funktioniert ohne Verbindung zur Außenwelt. Infrastrukturdienste laufen lokal, GitOps stellt ‚eventual consistency‘ sicher, sobald eine Verbindung wiederhergestellt ist.
• Klare Rollentrennung: Platform Engineers definieren die Leitplanken. Automation Engineers liefern die Logik. Maintenance-Techniker verantworten die physische Realität und werden durch Automatisierung entlastet.
• Technische Ehrlichkeit bei Echtzeit: Kubernetes ist ein Orchestrierungs- und Lifecycle-Management-System. Harte Echtzeit-Anforderungen für Feldbus-Protokolle oder Soft-PLCs erfordern ergänzend einen RT-fähigen Kernel und entsprechende Hardwareunterstützung.
• Schrittweise Migration: KubeVirt erlaubt es, Legacy-VMs und moderne Container auf derselben Plattform zu betreiben, ohne Big-Bang-Migration. Das reduziert Risiken und ermöglicht eine schrittweise Containerisierung bestehender Workloads.

Cloud-native Ansätze im Fertigungsumfeld unterstützen die Durchgängigkeit von der Sensorik im Shopfloor bis zur Unternehmensplanung, unter anderem durch standardisierte Schnittstellen, Automatisierung, Observability und iterative Updates. Der Weg dahin ist schrittweise, und die technischen Einschränkungen müssen klar benannt werden, die grundlegende Richtung ist jedoch etabliert. 

Redaktion: Andrea Gillhuber