Schwachstellen im laufenden Betrieb

Die meisten Unternehmen im deutschsprachigen Raum haben Docker längst eingeführt und betreiben eigene Kubernetes-Cluster. Die operativen Probleme bleiben trotzdem dieselben: undokumentierte Cluster-Provisionierung, ungeprüfte Helm-Charts, fehlende Ressourcenlimits und Ingress-Regeln, die niemand mehr reguliert. Diese Lücken werden erst sichtbar, wenn unter Last etwas ausfällt, meistens an einem Freitagabend, wenn niemand mehr im Büro sitzt. Der Cluster läuft bis dahin scheinbar stabil, jede der vier Lücken wartet einfach auf den passenden Auslöser.

Mehr als Dokumentation

Ein internes Wiki mit Architekturdiagrammen und Betriebsanleitungen fühlt sich nach Kontrolle an. Nur was Kubernetes tatsächlich ausführt, zählt aber im laufenden Cluster. Im Ernstfall hält nur das, was Kubernetes technisch erzwingt - Zugriffsrechte über Rollen, ergänzt um Netzwerkregeln und Vorgaben für die Pod-Sicherheit. Der Rest bleibt Theorie. Eine Ingress-Regel, die irgendwann einmal für einen Testfall freigeschaltet und nie wieder entfernt wurde, bleibt im Cluster aktiv, ganz gleich, was im Wiki dazu vermerkt ist, und genau dort entscheidet sie im Zweifel über einen Vorfall.

Governance-Lücken im gewachsenen Cluster

Docker und Kubernetes laufen bei dir bereits im Alltag. Das wirkt wie ein erledigtes Kapitel, obwohl viele Unternehmen genau an diesem Punkt die größten Governance-Lücken aufbauen: Der Cluster wächst mit jedem neuen Service schneller, als Verantwortlichkeiten und Dokumentation mitwachsen.

Genau das ist einem deutschen B2B-Marktplatz für Restposten und Liquidationsware passiert. Das ursprüngliche Entwicklungsteam hatte sich nach über zehn Jahren als Marktführer vollständig ausgetauscht, die Verantwortung für den Code war zersplittert, und schon kleine Änderungen lösten unvorhersehbare Ausfälle aus. Die API-Latenz in den zentralen Workflows sank nach der Containerisierung des Backends in klar abgegrenzte Services und einer Bereinigung der Infrastruktur-Berechtigungen um 70 Prozent. Der Kunde verdoppelte danach sowohl den Auftragsumfang bei uns als auch die eigene Teamgröße.

Container-Strategie und Image-Standards

Jedes Deployment beginnt beim Image. Wir legen Build-Standards fest und wählen geeignete Base-Images aus. Multi-Stage-Patterns halten die Images dabei klein und nachvollziehbar. Sicherheits-Scans laufen direkt in der Pipeline, mit Tagging-Konventionen und Registry-Governance sorgen wir dafür, dass jede Version eindeutig zurückverfolgbar bleibt.

Kubernetes-Cluster-Management

Cluster entstehen reproduzierbar über Terraform oder Pulumi, auf AWS EKS, Azure AKS, Google GKE oder On-Premises, je nachdem, wo deine Systeme laufen. Namespace-Isolation, RBAC, Netzwerkrichtlinien und Pod-Security-Standards sind dabei von Anfang an Teil der Provisionierung und direkt in jedem neuen Cluster verankert.

Helm-Charts und Release-Management

Eine saubere Chart-Architektur mit durchdachten Werte-Hierarchien macht den Unterschied zwischen einem Release, das sich erklärt, und einem, das man erst im Cluster versteht. Wir entwickeln umgebungsspezifische Overrides und Release-Prozesse, bei denen jede Änderung nachvollziehbar bleibt, von der Entwicklungsumgebung bis in die Produktion.

Service Mesh und Observability

Wir setzen für Service Mesh auf Istio oder Linkerd. Metriken laufen über Prometheus und Grafana, Logs über Loki oder den ELK-Stack, Traces über Jaeger oder Tempo. Ein Ausfall lässt sich so bis zum betroffenen Request-Pfad zurückverfolgen, noch während er passiert.

GitOps-basierte Bereitstellung

Deployments laufen deklarativ und pull-basiert, mit ArgoCD oder Flux als Werkzeug. Abweichungen zwischen Git-Zustand und Cluster-Zustand fallen automatisch auf, ein Rollback ist dann nur noch ein einzelner Git-Commit.

Unterstützung für Entwicklerinnen und Entwickler

Platform Engineering sorgt dafür, dass nicht jedes Team tiefes Kubernetes-Wissen braucht, um produktiv zu deployen. Deine Entwicklerinnen und Entwickler bekommen einen einfachen Einstiegspunkt über interne Entwicklerplattformen mit Self-Service-Zugang und Portalen im Stil von Backstage, während die Cluster-Komplexität dahinter verwaltet bleibt.

Der Weg von VM-basiertem Docker zu Kubernetes

Nicht jedes Unternehmen startet mit einem sauberen Kubernetes-Cluster. Viele arbeiten seit Jahren mit einer VM-basierten Docker-Umgebung, in der gewachsene Skripte und Ad-hoc-Regeln den Betrieb zusammenhalten, und wollen jetzt zu einer Kubernetes-Cluster-Architektur wechseln, und zwar so, dass der laufende Betrieb währenddessen stabil bleibt. Der Umstieg ist bei uns kein einmaliger Cutover, sondern eine begleitete Migration mit klaren Zwischenschritten, in der die alte und die neue Umgebung eine Zeit lang parallel laufen.

Fünf Referenzen aus unterschiedlichen Branchen

HomeToGo, eine vietnamesische Kaffeehauskette, ein B2B-Marktplatz für Restposten, commercetools und ein Schweizer Banktechnologie-Anbieter setzen auf genau diesen Betrieb:

HomeToGo: über 50 Produktiv-Deployments, 99,99 Prozent Verfügbarkeit, mehr als 100 gleichzeitig laufende A/B-Tests.

Vietnamesische Kaffeehauskette: Migration von einer VM-basierten Docker-Umgebung zu einer Kubernetes-Cluster-Architektur.

B2B-Marktplatz für Restposten und Liquidationsware: API-Latenz in den zentralen Workflows um 70 Prozent gesenkt, 99,9 Prozent Verfügbarkeit nach der Wiederherstellung, Liefergeschwindigkeit um 25 Prozent gestiegen, Auftragsumfang und Teamgröße beim Ausbau verdoppelt.

commercetools: durchgehender 24/7-Betrieb über drei Zeitzonen (USA, Deutschland, Vietnam), mehr als 75 Milliarden US-Dollar jährliches GMV geschützt.

Schweizer Banktechnologie-Anbieter: über 300 Bankanwendungen auf Cloud-Kompatibilität geprüft, durchgehender Betrieb während der gesamten Transformation, Weg zu Instant Payments bis November 2026 festgelegt.