Ein Rückblick auf den Vortrag von Lena Becker (RWTH Aachen) und Martin Mai (Universität Bamberg) beim SCS Summit 2026 von Lisa Seifert.

Auf dem diesjährigen SCS Summit gab es einen Vortrag, der mich länger beschäftigt hat als gedacht. Nicht weil er besonders laut war oder mit großen Zahlen aufwartete – sondern weil er ein Problem beschrieb, das in unserer Community selten so offen ausgesprochen wird: Wie viele Organisationen bauen gerade parallel dieselbe Infrastruktur auf, jede für sich, jede von vorn?

Lena Becker von der RWTH Aachen und Martin Mai von der Universität Bamberg haben beim Summit das Projekt Kube3 vorgestellt. Und während ich zuhörte, wurde mir klar: Was die beiden beschreiben, ist eigentlich eine sehr konsequente Anwendung von Dingen, über die wir in der SCS Community viel reden – föderale Infrastruktur, gemeinsame Standards, digitale Souveränität. Nur eben für eine Zielgruppe, die in unserer Community bisher wenig sichtbar war: Hochschulen.

Ein strukturelles Problem, keine individuelle Schwäche

Der Ausgangspunkt von Kube3 ist ein strukturelles Dilemma. Kubernetes ist für viele Anwendungsfälle an Hochschulen das richtige Werkzeug – skalierbare Forschungsworkloads, Mehrmandantenfähigkeit, moderne CI/CD-Pipelines. Aber Kubernetes zu betreiben bedeutet echtes Fachwissen: Netzwerk, Storage, Linux, IAM, Backup, Zertifikatsmanagement. Das ist für ein großes Rechenzentrum handhabbar. Für eine kleinere Hochschule mit zwei bis drei Leuten im Betrieb und einer Nutzergruppe, die vielleicht noch nicht mal eine kritische Masse für einen Business Case erreicht, ist es das nicht.

Das Ergebnis: Viele Hochschulen sind, wie es im Vortrag formuliert wurde, eine „Kubernetes-freie Zone“. Nicht aus Unwissenheit – sondern weil die Kosten-Nutzen-Rechnung nicht aufgeht, wenn man es alleine machen muss.

Die Antwort: Föderiert und bewusst heterogen

Kube3 ist eine Initiative aus drei Bundesländern: In Baden-Württemberg sind das Karlsruher Institut für Technologie (KIT), die Universität Heidelberg und die Universität Tübingen; in Bayern das Leibniz-Rechenzentrum (LRZ) und die Universität Bamberg; in Nordrhein-Westfalen die RWTH Aachen University, die Universität Münster und die Universität zu Köln. Das Ziel: An mehreren Hochschulstandorten KaaS-Systeme (Kubernetes-as-a-Service) aufbauen, die andere Hochschulen und Landesdienste im B2B-Modell nutzen können.

Was mich bei der technischen Beschreibung aufgehorcht hat, war die bewusste Entscheidung zur Heterogenität. Jeder Standort betreibt seine eigene Virtualisierungsschicht – OpenStack hier, KubeVirt dort, Cozystack woanders. Das entspricht der Realität: Hochschulrechenzentren haben gewachsene Infrastrukturen, die man nicht einfach vereinheitlichen kann. Die Einheitlichkeit, auf die es ankommt, liegt eine Ebene höher – in der KaaS-Schicht, die die Nutzenden sehen.

Das Ziel, so wurde es beim Summit formuliert: Diese Ebene soll sich für alle gleich anfühlen – egal was darunter eigentlich läuft. Das klingt simpel, ist aber technisch und organisatorisch alles andere als trivial.

Jeder Dienst bekommt ein dediziertes Kubernetes-Cluster, vollständig isoliert mit eigenem virtuellen Netzwerk. Monitoring, Logging, Support und Dokumentation sind standardisiert. Wer Kubernetes nutzen will, muss es nicht betreiben.

Die Vision, die nicht ganz ausgesprochen wurde

Martin Mai beschrieb im Vortrag, halb im Scherz, die Fernziel-Vision des Projekts: Man klickt an der eigenen Hochschule einen Dienst an. Der startet irgendwo – vielleicht in München, weil da gerade Kapazität ist, vielleicht anderswo. Man merkt es nicht. Abgerechnet wird zwischen den Bundesländern nicht in Geld, sondern in Rechenzeit-Guthaben, um steuerliche Komplikationen zu vermeiden.

Das ist noch weit weg. Aber die Richtung ist klar, und sie deckt sich mit dem, was viele in der SCS Community als Ideal einer souveränen, föderalen Cloud-Infrastruktur vor Augen haben – nur eben nicht für kommerzielle Kunden, sondern für Hochschulen.

Für den Moment konzentriert sich das Projekt auf konkrete Use Cases: GitLab Runner, die keine feste Heimat brauchen; das Open-Source-Bibliothekssystem Folio, das mehrere Bundesländer gemeinsam betreiben wollen; KI-Workloads; und eine persistente, portable Projektcloud für Forschungsverbünde.

Der DSGVO-Elefant im Raum

Ein Abschnitt des Vortrags war besonders ehrlich – und deshalb besonders wertvoll. Martin Mai beschrieb eine Absurdität, die viele aus dem Hochschulalltag kennen dürften: Microsoft Copilot darf man nutzen, weil es dafür einen Landesrahmenvertrag gibt, der die datenschutzrechtlichen Fragen bereits auf höherer Ebene geklärt hat. Daten mit der Nachbaruniversität zu teilen – die faktisch ein viel geringeres Datenschutzrisiko darstellt – erfordert dagegen oft Einzelfallprüfungen, Formulare und stockt an Zuständigkeitsfragen.

Nicht das tatsächliche Risiko entscheidet also darüber, ob eine Kooperation praktisch funktioniert, sondern ob die Verantwortung bereits irgendwo oberhalb der Einzelinstitution geregelt ist. Ein Verbund wie Kube3, der formal von den beteiligten Bundesländern anerkannt ist, kann genau diesen Effekt erzeugen: Hochschulen können miteinander kooperieren, ohne dass jede Datenschutzbeauftragte das Rad neu erfinden muss.

Eine offene Frage an die Community

Nebenbei – fast beiläufig – brachte Martin Mai noch einen Gedanken ein, der mich nicht loslässt. Im Projektalltag ist es bereits passiert, dass ein Setup in München lief und in Erlangen nicht – nicht weil etwas kaputt war, sondern weil Kubernetes eben ein Standardbaukasten ist, kein Standard. Wer welche Komponenten in welcher Konfiguration einsetzt, ist offen.

Das Projekt sondiert deshalb, ob es ähnlich wie die SCS-Flavor-Definitionen für virtuelle Maschinen standardisierte Kubernetes-Flavors geben sollte – verbindliche Konformitätsprofile, die sicherstellen, dass ein Cluster in München und eines in Aachen wirklich dasselbe liefern, wenn beide einen Conformance Test bestehen.

Feedback dazu ist ausdrücklich erwünscht. Und ich finde, das wäre eine Aufgabe, die gut in die SCS Community passt.

Den vollständigen Vortrag von Lena Becker und Martin Mai gibt es auf YouTube.