- Veröffentlicht
- 2. September 2026
- Lesezeit
- 8 Min.
- Autor
- Pino Rovetto
Vom Supercomputer zum eigenen Projekt.
Was eine Kubernetes-Plattform am Schweizerischen Nationalen Supercomputing-Zentrum über Infrastructure as Code, GitOps und Open Source lehrt – und was davon auch ohne Supercomputer nützlich ist.
Die entscheidende Idee
Die wertvollste Lektion ist nicht die Grösse der Infrastruktur. Es ist die Art, wie Komplexität beherrschbar gemacht wird.
Systeme werden beschrieben statt von Hand zusammengeklickt. Änderungen werden versioniert statt nur dokumentiert. Eine Automatisierung gleicht den gewünschten Zustand mit der Wirklichkeit ab. Und offene Schnittstellen halten Entscheidungen revidierbar. Diese Prinzipien funktionieren im Rechenzentrum, in einer Public Cloud, im Homelab – und oft schon in einem einzigen sorgfältig betriebenen Projekt.
Der Ausgangspunkt
Ein Supercomputer braucht mehr als Rechenleistung.
Das CSCS der ETH Zürich betreibt mit Alps eine aussergewöhnlich leistungsfähige Infrastruktur. Gleichzeitig müssen darauf sehr unterschiedliche Dienste verlässlich bereitgestellt werden. Eine Präsentation aus dem Jahr 2024 zeigt, wie das Team dafür Kubernetes-Cluster auf virtuellen Maschinen, gewöhnlicher Hardware und Rechenknoten von Alps zusammenführt.
Damals umfasste die Plattform rund 35 nachgelagerte Cluster, etwa 200 virtuelle Maschinen und 100 physische Knoten. In einem CSCS-Interview von 2026 spricht das Team bereits von ungefähr 60 Kubernetes-Clustern. Es berichtet zudem von rund 80 Prozent kürzerer Bereitstellungszeit für Cluster und etwa 70 Prozent schnellerer Anwendungsbereitstellung. Diese Zahlen beschreiben den konkreten CSCS-Kontext – sie sind kein pauschales Versprechen für andere Projekte.
Spannend ist deshalb weniger die Menge der Maschinen als das wiederkehrende Muster dahinter: Infrastruktur als Code, deklarative Anwendungen, automatische Synchronisierung und gemeinsame Betriebsdienste.
Vier übertragbare Prinzipien
Vom Spezialfall zur allgemeinen Arbeitsweise.
01
Infrastruktur wird beschreibbar
Rechner, Netze und Cluster entstehen aus versionierten Definitionen statt aus einer Folge manueller Klicks. Damit wird ein Aufbau wiederholbar, prüfbar und übertragbar.
02
Git wird zur gemeinsamen Wahrheit
Änderungen werden wie Software behandelt: sichtbar, besprechbar und nachvollziehbar. GitOps ergänzt das um einen laufenden Abgleich zwischen gewünschtem und tatsächlichem Zustand.
03
Gemeinsames wird zur Plattform
Netzwerk, Speicher, Identitäten, Zertifikate, Geheimnisse und Überwachung müssen nicht für jede Anwendung neu erfunden werden. Gut gepflegte Bausteine entlasten Teams.
04
Betrieb ist Teil des Entwurfs
Protokolle, Metriken und Zustandsinformationen werden von Anfang an mitgedacht. Erst dadurch lässt sich beurteilen, ob die Automatisierung auch in der Realität funktioniert.
GitOps in einem Satz
Git sagt, wie es sein soll. Das System prüft, wie es ist.
Bei GitOps liegt der gewünschte Zustand deklarativ und versioniert in Git. Eine Software wie Argo CD liest diese Definitionen, vergleicht sie fortlaufend mit dem laufenden System und korrigiert Abweichungen. Das ist mehr als eine automatische Installation: Es schafft einen prüfbaren Weg von einer besprochenen Änderung bis zum tatsächlichen Zustand der Plattform.
Am CSCS werden damit sowohl gemeinsame Dienste als auch clusterspezifische Anwendungen verteilt. Die Idee lässt sich kleiner anwenden: Schon wenn Konfigurationen nur über geprüfte Änderungen in Git in die Produktion gelangen, werden Ursachen, Verantwortlichkeiten und Rückwege klarer.
Kubernetes in passender Grösse
Klein starten. Portabel bleiben.
Kubernetes gibt es in unterschiedlichen Distributionen und Betriebsformen. Leichtgewichtige Varianten wie K3s bringen die gemeinsamen Kubernetes-Schnittstellen auch auf kleine Systeme. Der Nutzen beginnt dort, wo Anwendungen unabhängig vom aktuellen Betriebsort bleiben sollen.
Ein Dienst
Kubernetes auf einem Knoten
Auch eine kleine Anwendung mit nur einer laufenden Instanz kann von Kubernetes profitieren. Eine leichtgewichtige Distribution wie K3s ermöglicht den Betrieb auf einem einzelnen Knoten. Container-Images und versionierte Kubernetes-Manifeste schaffen dabei von Anfang an eine gemeinsame Grundlage für die Bereitstellung an unterschiedlichen Standorten.
Mehrere Umgebungen
Infrastruktur als Code ergänzen
Wenn Entwicklung, Test und Produktion zuverlässig gleich aufgebaut werden sollen, helfen deklarative Definitionen. Terraform oder dessen Open-Source-Fork OpenTofu können zusammen mit Ansible die nötigen Ressourcen und Konfigurationen reproduzierbar bereitstellen.
Viele Dienste oder Teams
Auf gemeinsamen Standards aufbauen
Dieselben Kubernetes-Grundprinzipien tragen auch eine grössere Plattform. Mit zusätzlichen Diensten oder Teams wachsen die Anforderungen an Kapazität, Zugriffsregeln und gemeinsame Betriebsdienste. GitOps hält deren Bereitstellung nachvollziehbar; die vertrauten Schnittstellen und Abläufe bleiben die gemeinsame Basis.
Portabilität und Hochverfügbarkeit sind unterschiedliche Ziele: Ein Single-Node-Setup kann eine portable Betriebsgrundlage bieten, schützt aber nicht vor dem Ausfall dieses Knotens. Wie viel Redundanz nötig ist, richtet sich nach den Verfügbarkeitsanforderungen der Anwendung.
Warum Open Source zählt
Offenheit hält technische Entscheidungen beweglich.
Kubernetes, Argo CD, Ansible, RKE2, Rancher und die weiteren Bausteine der Plattform sind offen entwickelt. Das macht ihre Funktionsweise überprüfbar, ermöglicht eigene Erweiterungen und reduziert die Abhängigkeit von einem einzelnen Anbieter. Anwendungen werden dadurch nicht automatisch portabel – Daten, Identitäten, Netze und Betriebswissen müssen ebenfalls sauber entkoppelt sein. Aber offene Standards und Schnittstellen schaffen dafür eine wesentlich bessere Ausgangslage.
Eine wichtige Aktualisierung zur Präsentation von 2024: Dort wird Terraform für Infrastructure as Code eingesetzt. Nach dem Lizenzwechsel bei Terraform bietet OpenTofu als gemeinschaftlich entwickelter Open-Source-Fork von Terraform eine Alternative für Projekte mit einer konsequenten Open-Source-Vorgabe. Offen bedeutet allerdings nicht kostenlos im Betrieb: Auch freie Software braucht Pflege, Sicherheitsupdates, Wissen und klare Verantwortung.
Die Essenz
Vier Sätze für das nächste Projekt.
- 01Beschreibe den gewünschten Zustand als Code.
- 02Lass Änderungen prüfen und versionieren.
- 03Automatisiere den Weg von der Absicht zur Realität.
- 04Beobachte, ob das System wirklich hält, was der Code verspricht.
Fazit
Portabilität beginnt bei der ersten Anwendung.
Das CSCS zeigt eindrücklich, wie offene Werkzeuge eine hoch spezialisierte Umgebung vereinheitlichen können. Dieselben Kubernetes-Standards sind auch für eine kleine Anwendung auf einem einzelnen Knoten wertvoll. Wer Container-Images, Manifeste und Konfigurationen übertragbar hält und Daten, Speicher sowie externe Dienste bewusst einplant, schafft eine Grundlage für Standortwechsel: vom Homelab oder On-Premises in eine Cloud, wieder zurück oder von einem Cloud-Anbieter zum anderen.
Kubernetes verbindet diese Betriebswelten durch gemeinsame Schnittstellen. Die konkrete Umgebung darf sich ändern – die Anwendung und ihre Bereitstellung sollen möglichst wenig davon abhängig sein.
Weiterführende Informationen
Quellen und Hintergründe.
- 01CSCS: Kubernetes Infrastructure at CSCS (Präsentation, 28. Mai 2024)
- 02CSCS: We built a system to run HPC services in a cloud-native way (2026)
- 03Kubernetes: Überblick und Grundprinzipien
- 04K3s: Single-Node-Betrieb und Hochverfügbarkeit
- 05OpenGitOps: vier Grundprinzipien
- 06Argo CD: deklaratives GitOps für Kubernetes
- 07OpenTofu: Open-Source-Fork von Terraform
- 08Ansible Community: Automatisierung und gewünschter Zustand
Vom Prinzip zur Praxis
Welche dieser Ideen würde Ihr Projekt wirklich einfacher machen?
In einer Beratung oder Schulung erarbeiten wir, wie Ihre Anwendungen portabel und zuverlässig betrieben werden können – vom einzelnen Kubernetes-Knoten bis zur gemeinsamen Plattform.
Coaching ansehen