Thesis:
Workflow Systeme wie bspw. Apache Airflow, Argo, Luigi, Pachyderm oder auch Kubeflow Pipelines werden zunehmend häufiger auf Kubernetes Plattformen betrieben. Oft wurden diese Workflow Systeme jedoch ursprünglich als Standalone-Systeme konzipiert. Selbst Systeme, die zielgerichtet für Kubernetes entwickelt wurden, wie z.B. Kubeflow, kommen mit einem nennenswerten Ressourcenverbrauch einher, der sich unter anderem aus einer Vielzahl von kontinuierlich laufenden Pods ergibt (Always-On Komponenten), die erforderlich sind, um diese Systeme zu betreiben.
Die Komplexität der Menge an “Moving Parts” (Pods) in diesen Systemen ist somit erstaunlich hoch, obowhl Kubernetes bereits Konzepte bereitstellt, die von Workflow Systemen grundsätzlich genutzt werden könnten, um teure Always-On Komponenten zu vermeiden. Diese Arbeit soll daher untersuchen, ob sich aus dem Zusammenspiel bestehender (auch teilweise vernachlässigter) Kubernetes Ressourcen und Konzepte wie bspw.
ein wesentlich leichtgewichtigeres Workflow System entwickeln lässt, welches sich primär auf die genannten und verlinkten Kubernetes Built-In Primitive abstützt.
Ziel dieser Arbeit ist es, mittels eines Prototyps zu untersuchen, wie ein solch streng Container-fokusiertes Workflow System für Kubernetes zu entwerfen wäre und diesen Prototyp zu evaluieren und mit existierenden Workflow-Systemen zu vergleichen. Der Prototyp sollte idealerweise maximal zwei kontinuierlich laufende und leichtgewichtige Kubernetes-Deployments (inkl. Services) erfordern:
Ansonsten sollte der Prototyp sich rein auf Kubernetes Built-In Primitive abstützen.
Die Implementierung von Web-UI und Controller ist vorzugsweise mittels Python vorzunehmen.
Im Sinne des Open Source Gedankens wäre es schön, wenn die Autor:in anstrebt, die Lösung als Open Source Projekt im Anschluss der Arbeit der Allgemeinheit zur Verfügung zu stellen und über die Abschlussarbeit hinaus als Open Source Produkt fortzuführen.