Kubernetes hat ein Imageproblem: Die eine Hälfte der Branche trägt es wie ein Abzeichen, die andere empfindet es als Kostenaufschlag. Für mich ist es ein Werkzeug mit einem klaren Einsatzpunkt. Eine Marketingseite oder ein MVP läuft problemlos auf einem einzelnen Server mit Prozessmanager und CI-Job – genau so wird diese Website bereitgestellt. Kubernetes lohnt sich, wenn es mehrere Dienste, schwankende Last und mehr als ein Team gibt, das dieselbe Infrastruktur beliefert.
Alles beginnt mit dem Container. Multi-Stage-Dockerfiles, ein kleines Laufzeit-Image ohne Entwicklungsabhängigkeiten, ein Nicht-root-Benutzer und ein Prozess pro Container. Eine Next.js-Anwendung wird im Standalone-Modus gebaut; für eine NestJS-API werden nur dist und die Produktionsabhängigkeiten in node_modules ausgeliefert. Dasselbe Image wandert von CI über Staging nach Produktion. Nur die Konfiguration ändert sich – über Umgebungsvariablen, ConfigMaps und Secrets, niemals durch einen Neubau pro Umgebung.
Die Objekte, die ich täglich verwende, sind überschaubar: ein Deployment pro Dienst, ein Service davor, ein Ingress mit TLS für öffentlichen Traffic und ein HorizontalPodAutoscaler für Komponenten mit echten Lastspitzen. Jeder Container erhält Ressourcenanforderungen und -limits – ohne sie muss der Scheduler raten. Readiness- und Liveness-Probes sind bewusst getrennt: Readiness sagt „Schick mir noch keinen Traffic“, Liveness „Starte mich neu“. Wer beides verwechselt, macht aus einer langsamen Datenbank einen Neusturm. Jeder Node.js-Dienst verarbeitet außerdem SIGTERM und beendet laufende Anfragen, damit ein Rolling Update keine Zahlung mittendrin abbricht.
Nicht alles ist ein Webserver. Queue-Worker laufen in eigenen Deployments und skalieren anhand des Rückstaus, nicht der CPU. Geplante Aufgaben – Berichte, Bereinigungen, Abgleiche mit einem Zahlungsanbieter – laufen als CronJobs mit concurrencyPolicy: Forbid, damit ein langsamer Lauf nicht mit dem nächsten überlappt. Datenbankmigrationen werden vor dem Rollout als Job ausgeführt, nicht beim App-Start: Fünf gleichzeitig startende Replikate sollen nicht alle versuchen, das Schema zu migrieren. PostgreSQL nutze ich lieber als verwalteten Dienst wie RDS statt als StatefulSet – der Cluster ist für zustandslose Dienste da.
Manifeste liegen in Git und werden wie Code geprüft. Ausgerollt wird über eine CI-Pipeline mit Helm oder Kustomize oder per GitOps mit Argo CD – ein Rollback ist dann ein Revert und keine nächtliche kubectl-Sitzung. kubectl apply vom Laptop ist zum Lernen da, nicht für Produktion. Logs gehen an stdout und in einen zentralen Speicher, Metriken an Prometheus und Grafana; den Rollout überwache ich mit kubectl rollout status, statt auf das Beste zu hoffen. Auf AWS bedeutet das meist EKS mit verwalteten Node-Gruppen, damit sich das Team auf das Produkt und nicht auf die Control Plane konzentriert.
Was ich ablehne: Kubernetes für eine Website mit zwei Seiten, ein Service Mesh bevor es mehrere Services gibt, Secrets als Klartext-YAML im Repository und Pods ohne Limits, weil „es im Staging funktioniert hat“. Wenn du nicht weißt, ob du einen Cluster brauchst, schick mir deine Dienste, den Traffic und die Teamgröße. Ich sage dir ehrlich, ob Kubernetes, ein paar Container auf einem Host oder eine Plattform wie Vercel passt – und was die jeweiligen Varianten ungefähr im Monat kosten.
Geben Sie dem nächsten Produkt jemanden, der bleibt.
Bereit für den Start? Schreiben Sie mir – ich kann sofort beginnen und bleiben. Langfristige Mandate statt Übergabe nach zwei Wochen. Lassen Sie uns über Ihr Projekt, die Anforderungen und den besten Weg nach vorn sprechen.