Kubernetes Migration: Was du wissen musst, bevor du anfängst

Kubernetes zu migrieren klingt nach einer klaren Infrastrukturaufgabe — besonders wenn man von einer einfacheren Orchestrierung wie Docker Swarm zu Kubernetes wechselt. Du nimmst deine bestehenden Anwendungen, packst sie in Container, schreibst ein paar YAML-Dateien und rollst aus. In der Praxis sieht es selten so aus. Wer ohne Vorbereitung migriert, landet schnell in einem Cluster, der technisch läuft, aber operativ niemanden glücklich macht: instabile Pods, unklare Verantwortlichkeiten und nachts klingelnde Alerts. Dieser Artikel zeigt, wo die echten Probleme entstehen und wie man sie vermeidet.

Kubernetes ist kein Ziel, sondern ein Werkzeug

Ein häufiger Denkfehler: Kubernetes Migration wird als Infrastrukturprojekt behandelt, obwohl es eigentlich ein Architekturprojekt ist. Die Plattform stellt Mechanismen bereit (Scheduling, Self-Healing, Skalierung, Service Discovery), die aber nur dann funktionieren, wenn die Anwendungen darauf ausgelegt sind.

Eine klassische VM-Anwendung, die Konfiguration lokal auf Disk schreibt, Logfiles unter /var/log ablegt und erwartet, dass der Prozess nie neu startet, wird auf Kubernetes zwar starten. Aber sie wird sich falsch verhalten. Pods werden neu gestartet, Logs gehen verloren, Konfiguration ist weg.

Kubernetes lohnt sich nur, wenn Anwendungen ephemeral, zustandslos und beobachtbar sind. Das ist keine Kritik an der Plattform, sondern die Voraussetzung, unter der sie sinnvoll eingesetzt werden kann. Wer das beim Start der Migration versteht, spart sich viel Frust.

Vor der Kubernetes Migration: Was du analysieren musst

Bevor der erste Pod deployed wird, lohnt sich eine ehrliche Bestandsaufnahme. Nicht jede Anwendung ist gleich bereit für Kubernetes, und unterschiedliche Bereitschaftslevel erfordern unterschiedliche Migrationspfade.

Folgende Fragen helfen dabei:

• Welche Services sind stateless, welche haben persistenten Zustand?
• Welche Services haben externe Abhängigkeiten (Datenbanken, Message Queues, Legacy-APIs)?
• Was sind die Ressourcenprofile der Anwendungen: CPU-intensiv, speicherhungrig, IO-bound?
• Wie sehen die aktuellen Deployment-Prozesse aus: Wie wird deployed, wie wird zurückgerollt?
• Gibt es Hardcoded-Konfiguration oder werden Umgebungsvariablen und externe Config-Stores genutzt?

Stateful Services separat behandeln

Datenbanken, Message Queues und ähnliche Systeme brauchen eine eigene Migrationsstrategie. Sie einfach als StatefulSet in den Cluster zu ziehen, ist zumindest am Anfang selten die beste Idee.

Viele Teams fahren gut damit, Datenbanken zunächst außerhalb des Clusters zu lassen, beispielsweise managed auf AWS RDS, Cloud SQL oder ähnlichen Diensten, und nur die Anwendungsschicht zu migrieren. Das reduziert die Angriffsfläche erheblich und ermöglicht es, zuerst Erfahrungen mit Kubernetes zu sammeln, ohne gleichzeitig Datenpersistenz im Cluster managen zu müssen.

Wenn Datenbanken dennoch in den Cluster sollen: StatefulSets mit persistenten Volumes sind der richtige Ansatz, aber PodDisruptionBudgets, StorageClasses, Backup-Strategien und Upgrade-Prozesse müssen verstanden und getestet sein, bevor das produktiv geht.

Ressourcen-Anforderungen erheben

Einer der häufigsten Fehler bei der Kubernetes Migration ist das Deployen ohne resources.requests und resources.limits. Das fühlt sich zunächst einfacher an, weil weder Konfiguration noch tieferes Nachdenken nötig scheinen. Der Preis kommt aber später.

Ohne requests weiß der Kubernetes Scheduler nicht, wie er Pods auf Nodes verteilen soll. Ohne limits kann ein einzelner fehlerhafter Pod die Node destabilisieren. Beides führt in Produktionssystemen zu schwer reproduzierbaren Problemen.

Bevor du migrierst: Mess den aktuellen Memory- und CPU-Verbrauch deiner Services unter Last. Diese Werte sind die Grundlage für sinnvolle requests. limits setzt du dann konservativ darüber, mit etwas Puffer, aber nicht so großzügig, dass ein Bug unbemerkt bleibt.

Die häufigsten Fehler bei der Kubernetes Migration

Manche Probleme tauchen so regelmäßig auf, dass sie fast schon vorhersehbar sind. Hier sind die wichtigsten:

Ressourcen-Limits nicht vergessen

OOMKills sind unangenehm. Der Pod wird stillschweigend beendet, Kubernetes startet ihn neu, und wenn niemand auf die Events achtet, merkt das Team es erst, wenn Nutzer sich beschweren. Die Lösung ist nicht kompliziert, aber sie erfordert, dass man sich einmal hinsetzen und die Werte durchdenken.

resources:
  requests:
    memory: "256Mi"
    cpu: "250m"
  limits:
    memory: "512Mi"
    cpu: "500m"

Das sind Beispielwerte, denn die richtigen Zahlen hängen von deiner Anwendung ab. Wichtig ist, dass du sie setzt und sie auf realen Messwerten basieren, nicht auf Schätzungen.

Secrets sicher verwalten

Kubernetes Secrets sind standardmäßig nur Base64-kodiert, nicht verschlüsselt. Wer sensible Daten wie Datenbankpasswörter, API-Keys und TLS-Zertifikate direkt als Kubernetes Secrets ablegt und dabei auf Cluster-seitige Encryption at Rest verzichtet, hat ein Sicherheitsproblem, das er vielleicht noch nicht sieht.

Die empfohlenen Ansätze:

• External Secrets Operator mit einem externen Secret Store (AWS Secrets Manager, HashiCorp Vault, GCP Secret Manager)
• Sealed Secrets für GitOps-Workflows, bei denen Secrets als verschlüsselte CRDs im Repository liegen
• Vault Agent Injector für direkte Integration mit HashiCorp Vault

Welchen Weg du wählst, hängt von deiner Infrastruktur ab. Aber irgendeinen dieser Wege solltest du gehen, bevor Produktionsdaten im Cluster landen.

Observability einrichten, bevor es brennt

Ohne Metriken, Logs und Traces ist ein Kubernetes-Cluster eine Blackbox. Probleme entstehen, aber es gibt keine Grundlage, um sie schnell zu isolieren.

Das bedeutet nicht, sofort den vollständigen Observability-Stack aufzubauen. Aber mindestens Prometheus für Metriken und ein zentrales Log-Aggregationssystem (Loki, Elasticsearch oder ein Managed Service) sollten laufen, bevor die ersten Services migriert werden. Dashboards in Grafana für die wichtigsten Service-Metriken helfen dabei, Probleme früh zu erkennen.

Die Health Checks livenessProbe und readinessProbe sind dabei kein Nice-to-have. Ohne readinessProbe schickt Kubernetes Traffic an Pods, die noch nicht bereit sind. Ohne livenessProbe bleiben hängende Prozesse unentdeckt.

Kubernetes Migration Schritt für Schritt

Der sicherste Weg zur Kubernetes Migration ist ein inkrementelles Vorgehen, bei dem ein Service nach dem anderen migriert wird.

Das hat mehrere Vorteile:

• Fehler bleiben isoliert und betreffen nur einen Service
• Das Team sammelt mit jedem Service mehr Erfahrung
• Rollbacks sind überschaubar, weil nur ein Teil des Systems betroffen ist

Ein typischer Ablauf sieht so aus:

1. Beginne mit einem nicht-kritischen, zustandslosen Service, idealerweise einem, der gut dokumentiert ist und wenige externe Abhängigkeiten hat.
2. Containerisiere und teste den Service, sofern noch nicht geschehen.
3. Erstelle Kubernetes-Manifeste (oder Helm Chart / Kustomize-Overlay), setze requests und limits und konfiguriere Health Checks.
4. Deploye in einem Staging-Cluster und teste unter realistischer Last.
5. Lege die Rollout-Strategie fest: Rolling Update reicht für die meisten Services, für kritische Pfade bietet sich Canary-Deployment oder Blue-Green an.
6. Validiere die Observability: Kommen Logs an? Zeigen Metriken das erwartete Bild? Schlagen Health Checks korrekt an?
7. Schalte produktiv und deaktiviere die alten Deployments.

Namespace-Strategie und RBAC von Anfang an

Namespaces sind das primäre Mittel zur Isolierung in Kubernetes. Wer alle Services in den default-Namespace deployt, vermischt Verantwortlichkeiten und erschwert RBAC-Konfiguration, Netzwerkpolicies und spätere Governance.

Eine sinnvolle Grundstruktur trennt nach Teams oder Domänen, etwa team-backend, team-platform oder monitoring, und definiert pro Namespace klare Zugriffsrechte über RBAC. Das Prinzip lautet Least Privilege: Jeder Service Account bekommt genau die Rechte, die er braucht, und nicht mehr.

NetworkPolicies ergänzen das: Ohne explizite Richtlinien kommunizieren alle Pods im Cluster miteinander. Das ist selten gewünscht. Einfache Default-Deny-Policies pro Namespace, ergänzt durch explizite Allow-Regeln, reduzieren die Angriffsfläche erheblich.

Observability als Voraussetzung, nicht als Nachgedanke

Der Unterschied zwischen einem gut betreibbaren Kubernetes-Cluster und einem schwer wartbaren liegt oft nicht in der Konfiguration der Workloads, sondern in der Qualität der Observability.

Metriken (Prometheus + Grafana), strukturiertes Logging (JSON-Logs, zentrales Aggregationssystem) und für komplexere Systeme Distributed Tracing (OpenTelemetry + Jaeger oder Tempo) sollten zum Grundgerüst gehören.

Besonders hilfreich sind Alert-Regeln für Pods im CrashLoopBackOff, hohe Restart-Raten und ungewöhnliche Ressourcenauslastung. Diese drei Alerts decken einen Großteil der häufigsten Produktionsprobleme in Kubernetes-Clustern ab.

CI/CD-Pipelines auf Kubernetes ausrichten

Bestehende CI/CD-Pipelines, die für klassische Deployments gebaut wurden, wie direktes SSH, Ansible-Playbooks oder einfache Docker-Deployments, lassen sich meist nicht direkt auf Kubernetes übertragen.

Helm ist für die meisten Teams der pragmatischste Einstieg. Charts erlauben es, Kubernetes-Manifeste zu parametrisieren und wiederverwendbar zu machen. Für mehrere Umgebungen (Dev, Staging, Prod) lassen sich Werte-Dateien pro Umgebung definieren.

helm upgrade --install my-service ./charts/my-service \
  -f values.production.yaml \
  --namespace team-backend

Kustomize ist eine Alternative ohne eigene Templating-Sprache, besonders nützlich wenn du näher an nativen Kubernetes-Manifesten bleiben willst.

GitOps mit Argo CD oder Flux sorgt dafür, dass der Cluster-Zustand immer mit dem Git-Repository übereinstimmt. Änderungen werden nicht manuell angewendet, sondern durch Commits getriggert. Das verbessert Nachvollziehbarkeit und reduziert menschliche Fehler bei Deployments erheblich.

Wann eine PaaS die bessere Wahl ist

Kubernetes ist mächtig, bringt aber operativen Aufwand mit sich. Cluster-Management, Upgrades, Sicherheitspatches, Netzwerkkonfiguration sowie der Aufbau und Betrieb des Observability-Stacks sind ein nicht triviales Paket an Aufgaben, das in vielen Teams neben der eigentlichen Produktentwicklung laufen muss.

Wenn Kubernetes-Infrastruktur nicht zum Kerngeschäft gehört, lohnt sich die Frage, ob eine PaaS-Plattform die bessere Wahl ist. Plattformen wie lowcloud abstrahieren genau diese Schicht: Teams bekommen eine deploybare Kubernetes-Umgebung über eine DevOps-as-a-Service-Plattform, ohne selbst Cluster-Administratoren zu werden. Was ist eine PaaS

Das bedeutet nicht, dass jede Anwendung auf eine PaaS gehört. Wer spezifische Anforderungen an die Cluster-Konfiguration hat oder Kubernetes-Expertise bereits im Team vorhanden ist, fährt oft gut damit, den Cluster selbst zu betreiben. Aber für Teams, die schnell produktiv sein wollen, ohne sich in Kubernetes-Infrastruktur zu verlieren, ist eine PaaS eine legitime und oft unterschätzte Option.

lowcloud ist eine Kubernetes-basierte PaaS-Plattform für Teams, die ihre Anwendungen zuverlässig und mit wenig Overhead betreiben wollen. Wenn du Kubernetes-Komplexität reduzieren möchtest, ohne auf die Kontrolle über deine Deployments zu verzichten, ist lowcloud einen Blick wert.