Eine Bare-Metal-Kubernetes-Plattform betreibbar machen

Die Aufgabe dahinter

Bei jaraco begann die Plattformarbeit mit einer praktischen Frage: Wie lässt sich eine Bare-Metal-Kubernetes-Umgebung verlässlich genug für Unternehmensanwendungen betreiben, ohne die betrieblichen Details zu verstecken, die bei Fehlern entscheidend sind?

Ich arbeite dort seit Februar 2025 als Werkstudent Platform & Data in Münster. Meine Rolle umfasst die Clusterbasis und die Dienste darum herum: Storage, Observability, Networking, Identitäten, Secrets, Zertifikate, Qualitätschecks, Scans und Deployment-Automatisierung.

Was zusammenspielen musste

Der Cluster selbst ist nur ein Teil des Systems. Ein Workload hängt auch von Speicher, Netzwerkerreichbarkeit, Zertifikaten, Secrets, Identität, Logs, Metriken und dem Weg vom Source Control bis zur laufenden Anwendung ab.

Deshalb war die Aufgabe nicht nur „Kubernetes aufsetzen“. Ich arbeitete an einer lokalen Bare-Metal-Kubernetes-Plattform mit 12 Knoten, die über 10 Unternehmensanwendungen hostet, und verband sie mit den Diensten, die für den Betrieb notwendig sind:

Ceph für Storage.
Grafana, Grafana Alloy, Prometheus und Loki für Observability.
Flannel und Cilium als Teil der Netzwerkintegrationen.
Keycloak, SonarQube, HashiCorp Vault, cert-manager mit Let’s Encrypt und Trivy für Identitäten, Qualität, Secrets, Zertifikate und Scans.
FluxCD und GitHub Actions, um Deployments wiederholbarer zu machen und manuelle Deployment-Arbeit zu reduzieren.

Plattformübersicht

Das Diagramm zeigt die Zuständigkeitsbereiche der Plattform auf logischer Ebene. Es ist keine physische Netzwerk- oder interne Sicherheitstopologie.

Was die Kennzahlen bedeuten

Die 12 Knoten sind nicht als Zahl allein interessant. Sie zeigen, dass die Plattform groß genug ist, damit manuelle Sonderwege schnell schwer nachvollziehbar würden. Auch die über 10 Unternehmensanwendungen machen wiederholbare Delivery- und Betriebsprüfungen wichtig.

Zu den berichteten Ergebnissen gehören 99 % Uptime und eine Reduktion der manuellen Deployment-Zeit um 40 % durch automatisierte Workflows. Ich behandle diese Angaben als Projektergebnisse, nicht als Live-Status. Die Deployment-Kennzahl bezieht sich auf manuelle Deployment-Arbeit, nicht auf die gesamte Lead Time, Release-Häufigkeit oder Anwendungsperformance.

Welche Arbeitsweise das geprägt hat

GitOps ist nützlich, weil die Plattform einen gewünschten Zustand bekommt. Gleichzeitig verändert es die Fehlersuche. Ein erfolgreicher CI-Lauf ist nur ein Teil der Geschichte. Die Quellrevision muss abgeholt werden, der Controller muss sie reconciliieren, der Workload muss ready werden und die Anwendung braucht weiterhin gesunde Signale.

Diese Denkweise prägt meine Plattformarbeit: den Deployment-Pfad prüfbar machen, nicht auf manuelle Erinnerung angewiesen sein und eine Analyse erst abschließen, wenn die gewünschte Revision und der Runtime-Zustand zusammenpassen.

Aktuelle Arbeit rund um die Plattform

Parallel zur Plattform entwickle ich ein KI-integriertes Data-Mesh-System. Diese Arbeit läuft und ist nicht Teil der oben genannten abgeschlossenen Deployment-Ergebnisse.