Private Cloud & Kubernetes

Plattformen, die ohne mich weiterlaufen

Kubernetes, Identity, Secrets, Registry, CI/CD, GitOps, Observability, Storage und Netzwerk als ein Stück: reproduzierbar ausgerollt, automatisiert betreibbar und so übergeben, dass das interne Team danach ohne mich weiterarbeitet. On-Premises auf Bare-Metal ebenso wie bei europäischen Anbietern und Hyperscalern.

Ausgangslage

Drei Sätze, die ich regelmäßig höre

Die einzelnen Komponenten sind selten das Problem. Schwierig wird der Teil dazwischen — dass sie zusammenpassen, sich reproduzieren lassen und Entwickler damit ohne Ticket-Umweg arbeiten können.

Cluster ja, Plattform nein

„Kubernetes läuft. Aber jeder Cluster ist anders, und keiner weiß mehr, warum.“

Handgebaute Cluster, undokumentierte Sonderwege, Upgrades, die niemand anfassen will. Was fehlt, ist nicht ein weiteres Werkzeug, sondern ein automatisierter Lebenszyklus vom Bootstrap bis zum Upgrade — und die Schichten darüber, die aus einem Cluster eine Plattform machen.

Plattform ja, Betrieb nein

„Der Kollege, der das gebaut hat, ist weg.“

Die Plattform läuft, aber das Wissen darüber steckt in ein bis zwei Köpfen. Kein Betriebsprozess, keine nachvollziehbaren Änderungen, keine Übergabe. Hier geht es um GitOps als Betriebsmodell statt als Werkzeug, um Dokumentation, die dem Zustand entspricht, und um die Verankerung im Team.

Anforderungen von außen

„Das muss im Haus bleiben, und es muss nachweisbar sein.“

Datenklassen, die das Rechenzentrum nicht verlassen dürfen, Prüfungen, die Nachvollziehbarkeit verlangen, Lieferketten, die belegt werden müssen. Das entscheidet über Architektur: Identity, erzwungene Richtlinien statt vereinbarter, Protokollierung und Supply-Chain-Prüfung gehören dann von Anfang an hinein.

Umfang

Was zu einer vollständigen Plattform gehört

Nicht jedes Vorhaben braucht alle Schichten auf einmal. Aber jede fehlende Schicht taucht später als Ticket, als Sonderweg oder als Prüfungsfeststellung wieder auf.

Cluster-Lifecycle
RKE2, OpenShift, Kubespray — Bootstrap, Skalierung und Upgrade vollständig mit Ansible automatisiert, ohne manuellen Eingriff
Identity und SSO
Keycloak, OIDC-Anbindung von Cluster, Registry, CI/CD und Observability an dieselbe Quelle
Secrets
Vault beziehungsweise OpenBao, Rotation, Zustellung in Workloads ohne Secrets im Repository
Container Registry
Harbor, Spiegelung für abgeschottete Netze, Signaturen und Schwachstellenprüfung
CI/CD und GitOps
Argo CD oder Flux als Betriebsmodell — der Zustand des Clusters steht im Repository, nicht im Gedächtnis
Policy Enforcement
Kyverno clusterweit — Richtlinien, die erzwungen werden, statt Richtlinien, die vereinbart sind
Observability
Prometheus, Grafana, Loki, Tempo, Elasticsearch — Metriken, Logs und Traces als ein Stück, nicht als drei Insellösungen
Netzwerk und Ingress
MetalLB für Bare-Metal, Ingress-Architektur, Zertifikate, Netzwerksegmentierung
Storage und Backup
Persistenz für zustandsbehaftete Workloads, Sicherung und geprobte Wiederherstellung
Automatisierung
Ansible und Terraform — geschrieben, versioniert und wiederholbar, nicht zusammengeklickt

Zusammenarbeit

Zwei Arten, mit mir zu arbeiten

Beratungstage

Ein Tag mit einer Entscheidung am Ende. Typische Anlässe:

  • Bestandsaufnahme einer gewachsenen Cluster-Landschaft
  • Review einer geplanten Plattformarchitektur
  • Zweitmeinung vor einer Distributions- oder Anbieterentscheidung
  • Bewertung des Betriebsrisikos: Was passiert, wenn der Einzige geht?
  • Aufwandsschätzung für einen Plattformaufbau

Aufbauprojekte

Die Plattform bauen und übergeben. Umfang nach Ausgangslage, in aller Regel:

  • Automatisierter Cluster-Lifecycle statt handgebauter Cluster
  • Identity, Secrets und Registry als gemeinsame Grundlage
  • GitOps-Auslieferung für Plattform und Anwendungen
  • Observability-Stack und Alarmierung
  • Betriebsdokumentation und Einarbeitung des internen Teams

Das Ziel eines Aufbauprojekts ist, dass Sie mich danach nicht mehr brauchen. Deshalb ist die Automatisierung geschrieben und nicht zusammengeklickt, deshalb steht der Zustand im Repository, und deshalb gehören Übergabe und Einarbeitung zum Projekt und nicht in ein Folgeangebot.

Das ist auch der Grund, warum in einem meiner Projekte Workshops zur Verankerung des Betriebswissens Teil der Leistung waren: Eine Plattform, die nur der Externe bedienen kann, hat das Problem nicht gelöst, sondern verschoben.

Belege

Wo ich das gebaut habe

Umfelder
Banken, Behörden, Sicherheitstechnologie, Logistik — überwiegend reguliert, mehrfach im Hochsicherheits- und sicherheitssensitiven Umfeld
On-Premises
Bare-Metal und virtualisierte Infrastruktur: RKE2 mit vollständig automatisiertem Cluster-Lifecycle, OpenShift auf virtualisierter Infrastruktur, hochverfügbare Cluster mit Kubespray und MetalLB
Cloud
Open Telekom Cloud, IONOS Cloud, AWS, Azure, Google Cloud — als Deployment-Target, nicht als eigene Disziplin
Zertifikate
CKS, CKA, CKAD
Hintergrund
Über 20 Jahre IT, davor Software-Engineering — unter anderem fünf Jahre bei SAP an C/C++-Laufzeitsystemen

Die einzelnen Projekte mit Zeitraum, Auftraggeber und Inhalt stehen auf der Startseite unter Referenzen.

Kontakt

Wo stehen Sie gerade?

Wenn Sie sich in einer der drei Ausgangslagen wiedererkennen: Schreiben Sie mir, in welcher. Das erspart uns beiden das halbe Erstgespräch.