Von Janis Kemper, Gründer und COO Syself GmbH

Beim SCS Summit habe ich einen Vortrag über unsere Kubernetes-Plattform gehalten – über die Architektur, die Entscheidungen dahinter und was wir in 2,5 Jahren Betrieb gelernt haben. An diesem Tag haben wir die SCS-compatible KaaS-Zertifizierung erhalten. Das ist ein guter Moment, um die Kernpunkte aus dem Vortrag nochmal aufzuschreiben – für alle, die nicht dabei waren, und als Ergänzung für alle, die es waren.

Zur Einordnung: Syself ist seit 2020 aktiv, wir haben von Anfang an mit der Cluster API gearbeitet und dabei den Cluster API Provider Hetzner entwickelt, der mittlerweile der meistgenutzte CAPI-Provider ist – auch beliebter als die der drei großen Hyperscaler. Im SCS-Kontext sind wir seit 2022 dabei, haben den KaaS-Tender mitgemacht und das Cluster Stacks Framework entwickelt. Wir sind außerdem Gründungsmitglied des Forum SCS Standards.

Der Cluster ist mehr als Kubernetes

Das erste und wichtigste Learning: Ein Kubernetes-Cluster besteht nicht nur aus Kubernetes. Er besteht aus Node Images, aus der Kubernetes-Konfiguration und aus einer Reihe von Addons – Applikationen, die im Cluster laufen müssen, damit er wirklich nutzbar ist. Diese drei Schichten werden in der Praxis häufig unabhängig voneinander verwaltet. Das rächt sich spätestens beim Upgrade.

Unsere Antwort darauf sind die Cluster Stacks: Wir betrachten, bauen, testen und releasen diese Schichten gemeinsam als eine Einheit. Nichts wird im laufenden System nachgeladen oder automatisch aktualisiert. Upgrade-Pfade werden vorab getestet, sodass garantiert ist, dass Node Images, Addons und Kubernetes-Konfiguration nach einem Upgrade zusammenpassen. Cluster lassen sich damit reproduzierbar erstellen – und auf verschiedenen Infrastruktur-Providern mit identischem Verhalten betreiben.

Genau das ist auch die Grundlage für die SCS-Zertifizierung: Die Cluster Stacks sind der Mechanismus, über den wir sicherstellen können, dass unsere Cluster die definierten SCS-Standards konsistent erfüllen – nicht nur einmalig, sondern über Upgrades und Provider-Wechsel hinweg.

Dedizierte Control Planes: mehr Aufwand, mehr Souveränität

Im Vortrag habe ich das als wahrscheinlich kontrovers angekündigt – und das war es auch. Viele Plattformen hosten die Control Planes ihrer Kunden in einem zentralen Cluster. Das spart Ressourcen. Wir machen das nicht.

Jeder Kunde bekommt seine eigenen Control Planes. Selbst wenn unsere Plattform ausfallen sollte, laufen die Cluster des Kunden weiter. Er kann in diesem Moment keine Upgrades fahren oder skalieren – aber seine Workloads laufen. Das ist ein wesentlicher Unterschied in der Frage, wer die Kontrolle hat.

Souveränität ist im SCS-Kontext kein Buzzword, sondern ein konkretes Designziel. Dedizierte Control Planes sind eine direkte Umsetzung dieses Ziels auf Plattformebene.

Für sehr große Cluster oder Setups mit strikten Isolation-Anforderungen – Stichwort Confidential Computing – lassen wir auch die Control Planes auf Bare-Metal-Maschinen laufen. Das ist ungewöhnlich, aber technisch möglich und in manchen Szenarien die konsequente Fortsetzung desselben Gedankens.

GitOps für Cluster funktioniert – wenn die API deklarativ ist

Durch die Cluster API haben wir eine vollständig deklarative API zur Cluster-Verwaltung. Das ermöglicht echtes GitOps auch für die Cluster selbst: Alle Konfigurationen liegen im Git-Repository, Änderungen laufen über Pull Requests und Review-Prozesse. Bei Hyperscalern mit ihrer imperativen API braucht man dafür erheblichen Zusatzaufwand. Bei uns ist es der Standardfall.

Das ist vor allem im Compliance-Kontext relevant – und damit auch für die SCS-Zertifizierung: Wer BSI C5 oder ISO 27001 anstrebt, braucht nachvollziehbare Änderungshistorien. GitOps löst das für die Cluster-Ebene direkt.

Datenbanken auf Bare Metal in Kubernetes: es funktioniert

Im Vortrag habe ich eeinen Kunden erwähnt, der, der jeden Monat sehr viel Geld für ein PostgreSQL-Cluster außerhalb von Kubernetes ausgegeben hat. Mit CloudNativePG lässt sich das deutlich kosteneffizienter lösen – und ohne das tiefste PostgreSQL-Expertenwissen.

Wir betreiben PostgreSQL-Cluster auf dem lokalen Storage der Bare-Metal-Server – direkt, ohne zusätzliche Netzwerkschicht. Was CloudNativePG konkret bietet:

• Hochverfügbarkeit durch Streaming-Replikation des Write-Ahead Logs auf Replikas 
• WAL-Archivierung in S3, was Point-in-Time Recovery ermöglicht 
• Georedundanz mit aktivem System in einer Region und Standby in einer anderen 

Die eigentliche Herausforderung bei lokalem Storage ist der Lifecycle: Der Storage ist nicht repliziert und über verschiedene Server verteilt. Das muss man in den Cluster-Lifecycle integrieren. Es gibt dafür heute gute Lösungen – aber man muss wissen, dass es ein eigenständiges Problem ist.

Dasselbe Modell nutzen wir u.a. analog für MariaDB, MySQL und ClickHouse.

Konfiguration hat Grenzen – Code ist testbarer

Das Cluster Stacks Framework – das wir im Rahmen des SCS-Projekts entwickelt haben – setzt stark auf Konfiguration statt Code. Das hat Vorteile: Man muss nicht programmieren können, um Cluster-Stacks zu verwalten. Aus Sicht des SCS-Projekts war dieser Ansatz deswegen der richtige, denn er ermöglicht einfachere Teilhabe. Der Nachteil ist allerdings, dass Konfiguration schwieriger zu testen ist.

Wenn man Code schreibt, hat man Unit-Tests. Wenn man konfiguriert, muss man sich selbst ein Test-Framework bauen, Pipelines aufsetzen, Rollout-Strategien definieren. Der Entwicklungszyklus ist langsamer und fehleranfälliger.

Wir bewegen uns deshalb in Richtung „Code, nicht Konfiguration“: mehr programmatische Kontrolle, bessere Testbarkeit, schnellere Iterationen. Das setzt voraus, dass man Entwickler hat, die das umsetzen können – die haben wir jetzt.

Was als nächstes kommt

Drei Punkte, die ich im Vortrag als Roadmap genannt habe:

Die Cluster API selbst ist aus Nutzerperspektive nicht besonders angenehm – sie ist ein generisches Projekt, und das sieht man ihr an. Wir wrappen sie mit mit einer eigenen API, die auf unsere Anforderungen zugeschnitten ist, und gewinnen damit einen kontrollierten Einstiegspunkt für deutlich mehr Automatisierung.

Wir setzen stärker auf Bare Metal. Kubernetes ist selbst eine Virtualisierungsschicht. Eine zusätzliche darunter, die nicht auf Kubernetes zugeschnitten ist, bringt aus unserer Sicht keinen Mehrwert. Der direktere Weg ist der bessere.

Und wir wollen auf weiteren SCS-Clouds und europäischen Providern verfügbar sein – und ja, auch auf Hyperscalern. Nicht um Kunden dort hinzubringen, sondern weil die Einstiegshürde für einen Wechsel von AWS zu einem europäischen Anbieter deutlich niedriger ist, wenn man die Plattform vorher auf der bekannten Infrastruktur ausprobieren konnte. Dafür braucht es die Möglichkeit, es dort überhaupt zum Laufen zu bringen.

Fazit

2,5 Jahre Plattformbetrieb verdichten sich am Ende auf ein paar einfache Erkenntnisse: Reproduzierbarkeit ist wichtiger als Features. Souveränität muss architektonisch verankert sein, nicht nur versprochen. Und Konfiguration skaliert schlechter als Code.

Die SCS-compatible KaaS-Zertifizierung ist für uns keine Ziellinie, sondern eine Bestätigung, dass die Grundlagen stimmen. Die interessanten Probleme – schlankere Images, bessere API-Ergonomie, mehr Bare Metal – kommen danach.

Den Vortrag vom SCS Summit gibt es als Aufzeichnung bei YouTube. Wer Fragen hat oder tiefer einsteigen will kann sich jederzeit bei uns melden: Janis Kemper, janis.kemper@syself.com.