Workload Automation in Kubernetes: Brückentechnologie für moderne Container-Orchestrierung

Einführung in die Workload Automation und ihre Bedeutung für Unternehmen

Workload Automation (WLA), oder SOAP – System Orchestration and Automation Plattform, wie führende Analysten dieses Segment bezeichnen, ist eine zentrale und unternehmensumspannende Aufgabe. In größeren Unternehmen werden über WLA mehrere hundert Millionen Einzelaktivitäten (sogenannte Jobs) pro Jahr auf den verschiedensten Plattformen der jeweiligen Unternehmens-IT ausgeführt. Systeme wie der IBM Workload Scheduler (IZWS) halten dafür zentral die Definition der Abläufe in diesen Job-Netzen vor. Die fehlerfreie Verfügbarkeit dieser Verarbeitung ist dabei mission critical. Kein Geschäftsprozess funktioniert ohne die Unterstützung der Workload Automation.

Containerisierung verändert die Anforderungen an die IT-Automatisierung

Die Veränderung in der Unternehmens-IT führt auch im WLA zu veränderten bzw. erweiterten Anforderungen. Die Containerisierung der Unternehmens-IT hat im letzten Jahrzehnt die Arbeitsweise in den Rechenzentren grundlegend verändert. Dabei spielt es kaum eine Rolle, ob die Systeme in der Cloud oder im eigenen Rechenzentrum (on-premise) betrieben werden. Nach einer Studie der techconsult aus dem Jahr 2024 setzen bereits rund 80 Prozent aller Unternehmen Container-Technologien ein oder planen, diese zukünftig innerhalb ihrer IT-Infrastrukturen zu integrieren.

Kubernetes als dominierende Plattform in der Container-Orchestrierung

Unter den Plattformen ist Kubernetes in seinen verschiedenen Ausprägungen deutlich führend.Für WLA-Systeme stellt sich daher die Aufgabe, wie Prozessketten, die traditionell über System- und Plattformgrenzen hinweg ablaufen, auch in und auf diesen neuen Container-Umgebungen ausgeführt werden können. Für das Kubernetes Job Scheduling durch etablierte WLA-Systeme müssen verschiedene Herausforderungen gelöst werden. Die meisten Workload-Automation-Systeme wie der marktführende IBM Workload Scheduler steuern ihre Jobs zentral, etwa vom z/OS Mainframe aus. Doch wie gelangt ein Ausführungsbefehl vom zentralen Scheduler in einen Kubernetes-Worker-Node?

Zunächst braucht es einen standardisierten Zugang zur Container-Umgebung. Kubernetes bietet dafür mit Ingress einen Dienst, der HTTP- und HTTPS-Kommunikation von außerhalb in das Cluster steuert. In Verbindung mit den APIs des Kubernetes-Systems können so die Agenten des WLA-Systems Befehle zur Job-Ausführung in die Worker-Nodes und schließlich in die Pods übertragen. Das ist ein zentraler Aspekt der WLA Kubernetes Integration.

Stateless Container und die Frage nach der Job-Definition

Doch hier wartet die nächste Herausforderung: Container sind per Definition stateless. Ihre Stärke liegt im schnellen Auf- und Abbau neuer Instanzen. Der Job selbst benötigt jedoch konkrete Anweisungen, meist in Form von Skripten, häufig in JCL (Job Control Language). Wie gelangen diese Anweisungen in die Kubernetes-Umgebung, ohne sie in die Container-Images einzubetten?

Eine Lösung ist die Übertragung der Job-Definitionen im Kommunikationsstrom. Moderne Erweiterungen wie der Beta Systems Cloud Connector gehen noch einen Schritt weiter. Sie nutzen die Möglichkeit, Inhalte über Persistent Volumes in den Container zu mounten. Auf diese Weise lassen sich Git Job-Definitionen zentral verwalten, beispielsweise in einem Git-Repository, und im Container zur Laufzeit verfügbar machen. Die dafür nötigen Zugangsrechte werden sicher in Kubernetes Secrets abgelegt, um Schwachstellen zu vermeiden.

Laufzeitdynamik: Variablen und Ressourcen im Job-Workflow

Ausgestattet mit Zugriff auf den Worker Node und der beschriebenen Möglichkeit, die Job-Definitionen gescriptet, verpackt oder über Git abzurufen, kann das WLA-System nun die gewünschte Container Automatisierung ausführen. Besonders die Git-Anbindung ist für Entwickler in Kubernetes-Umgebungen von Vorteil. Sie arbeiten in ihrer gewohnten Umgebung, können Änderungen verfolgen und ihre Stages wie Entwicklung, Test und Produktion unabhängig steuern.

Trotz dieser Freiheiten bleibt im WLA-System jederzeit nachvollziehbar, was wann mit welchem Ergebnis ausgeführt wurde. Dabei muss auch dynamisch auf Laufzeitbedingungen reagiert werden. Systeme wie der Cloud Connector ermöglichen es, zur Laufzeit Variablen und Ressourcen der Umgebung in die Job-Definitionen für Container einfließen zu lassen. Das ist ein wichtiges Feature für fortschrittliche IT-Automatisierung in Container-Umgebungen.

Nach der Ausführung eines Jobs ergibt sich für das WLA-System eine weitere Anforderung. Es benötigt detaillierte Protokolle zur Ausführung. Wie gelangen diese Informationen zurück?

Der Cloud Connector setzt hierfür auf sogenannte Sidecar-Container. Diese laufen im gleichen Pod wie der Job, greifen auf Umgebungsdaten zu und sammeln den Output. Über die bekannten Kommunikationspfade via API und Ingress gelangen diese Daten zurück zum WLA-System, das so über alle Ausführungsdetails informiert ist und gegebenenfalls die nachgelagerten Schritte der Job-Kette daran ausrichten kann.

Erfolgreiche Kundenprojekte und Marktresonanz zum Cloud Connector

Die Verfügbarkeit dieser Brückentechnologie zwischen einem etablierten Mainframe-basierten WLA-System wie IZWS und Kubernetes-Umgebungen hat bei Beta Systems Kunden schnell positiven Anklang gefunden. Bereits kurz nach Markteinführung konnte der erste Kunde für den Cloud Connector gewonnen werden, weitere Interessenten bereiten derzeit Pilotprojekte vor. Dieser Ansatz scheint im Verhältnis zwischen notwendigem Aufwand und erreichbarer Automatisierung eine hervorragende Balance für viele Unternehmen zu bieten.

Beta Systems als Wegbereiter plattformunabhängiger Automation

Beta Systems als führender deutscher Anbieter im Bereich Workload Automation beschäftigt sich mit diesen Anforderungen bereits seit Langem. Moderne System Orchestration and Automation Plattformen wie ANOW! Automate wurden von Anfang an für die Prozessautomation in Container-Umgebungen konzipiert. Auf dem Weg zu einer vollständig plattformunabhängigen Automatisierung schlägt der Cloud Connector im doppelten Sinn eine Brücke. Er modernisiert klassische Mainframe-Automation und ermöglicht gleichzeitig die Einbindung in Kubernetes. Das ist ein stabiler und zukunftsweisender Zwischenschritt auf dem Weg zum neuen WLA-System.