Kubernetes-Fallen und wie du sie vermeidest

Kubernetes ist heute der Standard für die moderne Orchestrierung von Containern. Unternehmen profitieren von Skalierbarkeit, Automatisierung und hoher Flexibilität. Doch genau diese Komplexität führt häufig zu typischen Fehlern im Betrieb. Viele dieser Probleme entstehen nicht durch Kubernetes selbst, sondern durch falsche Konfigurationen, fehlende Best Practices oder mangelndes Monitoring. Wer schon einmal um drei Uhr nachts auf einen abstürzenden Pod gestarrt hat, weiß: Mit der Flexibilität kommt auch eine ordentliche Portion Tücke. Zwar starten viele Teams gut, laufen dann aber irgendwann gegen dieselben Wände – nicht, weil sie schlechte Entwickler sind, sondern weil Kubernetes in seiner Tiefe viele kleine Fallstricke versteckt. In diesem Artikel betrachten wir die häufigsten Kubernetes-Fallen, erklären, warum sie auftreten, und zeigen dir konkret, wie du sie vermeiden kannst.

Warum Kubernetes-Probleme oft erst im Betrieb sichtbar werden

Ein Kubernetes-Cluster funktioniert in Testumgebungen häufig problemlos. Unter realer Last zeigen sich jedoch typische Schwächen:

• Pods starten neu
• Anwendungen reagieren langsam
• Speicher läuft voll
• Deployments schlagen fehl
• Logs verschwinden
• Ressourcen werden falsch verteilt

Gerade in produktiven Umgebungen können kleine Konfigurationsfehler schnell hohe Kosten oder Ausfälle verursachen. Deshalb sind klare Standards und Monitoring essenziell.

Häufige Fallen in Kubernetes

Keine Ressourcenlimits gesetzt

Die Falle:

In den Pod-Spezifikationen werden CPU- und Speicheranforderungen nicht angegeben. Dies geschieht typischerweise, weil Kubernetes diese Felder nicht verlangt und Workloads oft auch ohne sie starten und laufen können. Dadurch wird diese Auslassung bei frühen Konfigurationen oder während schneller Bereitstellungszyklen leicht übersehen.

In Kubernetes sind Ressourcenanforderungen und -beschränkungen jedoch entscheidend für eine effiziente Clusterverwaltung. Ressourcenanforderungen stellen sicher, dass der Scheduler für jeden Pod die angemessene Menge an CPU-Leistung und Arbeitsspeicher reserviert. Dadurch wird gewährleistet, dass der Pod über die für seinen Betrieb erforderlichen Ressourcen verfügt. Ressourcenbeschränkungen begrenzen die Menge an CPU-Leistung und Arbeitsspeicher, die ein Pod nutzen kann. Dadurch wird verhindert, dass ein einzelner Pod übermäßig viele Ressourcen beansprucht und andere Pods möglicherweise unterversorgt werden

Was passiert:

Ein schlecht optimierter Pod zieht den Node in den Ressourcen-Tod. Andere Pods werden umverteilt oder reagieren nicht mehr. Das Cluster beginnt zu stottern.

Das führt zu:

• „Noisy Neighbor“-Problemen
• OOMKills (Out of Memory)
• instabilen Nodes
• schlechter Planbarkeit

So vermeidest du es:

Setze für jeden Container requests (was er braucht) und limits (was er maximal bekommt). Tipp: Starte mit großzügigen Werten, beobachte mit Prometheus oder Grafana, und justiere dann.

Falsch konfigurierte Liveness- und Readiness-Probes

Die Gefahr besteht darin, dass Container bereitgestellt werden, ohne dass explizit festgelegt wird, wie Kubernetes deren Zustand oder Betriebsbereitschaft überprüfen soll. Dies geschieht häufig, da Kubernetes einen Container standardmäßig als „laufend“ einstuft, solange der darin befindliche Prozess nicht beendet wurde. Ohne zusätzliche Signale geht Kubernetes davon aus, dass die Anwendung funktioniert – selbst wenn sie nicht reagiert, sich gerade initialisiert oder hängen geblieben ist.

Liveness-, Readiness- und Startup-Probes sind Mechanismen, die Kubernetes zur Überwachung des Zustands und der Verfügbarkeit von Containern nutzt.

Liveness-Probes stellen fest, ob die Anwendung noch aktiv ist. Wenn eine Liveness-Prüfung fehlschlägt, wird der Container neu gestartet.

Readiness-Probes prüfen, ob ein Container bereit ist, Datenverkehr zu bedienen. Solange die Readiness-Prüfung nicht bestanden ist, wird der Container aus den Service-Endpunkten entfernt.

Start-Probes helfen dabei, zwischen langen Startzeiten und tatsächlichen Ausfällen zu unterscheiden.

Häufige Fehler

• zu aggressive Timeouts
• falsche Endpoints
• fehlende Startverzögerung
• identische Liveness- und Readiness-Probes

Was passiert: Endlos-Restart-Loops, CrashLoopBackOff, oder schlimmer: Anfragen landen bei einem halb initialisierten Service und schlagen still fehl.

So vermeidest du es: Trenne Liveness von Readiness sauber ab. Halte die Probe einfach. Übermäßig komplexe Prüfungen können Fehlalarme und unnötige Neustarts verursachen. Verwende eine Readiness-Probe, um sicherzustellen, dass der Datenverkehr deine App erst erreicht, wenn sie hochgefahren ist.

Logs werden nicht zentral gesammelt

Kubernetes rotiert Logs automatisch. Wer nur kubectl logs kennt, verliert im Ernstfall genau die Logs, die er gerade bräuchte, weil der Pod bereits neu gestartet wurde.

Konsequenzen

• Fehler lassen sich nicht nachvollziehen
• Debugging wird schwierig
• Compliance-Anforderungen werden verletzt

Was passiert: Du hast einen Fehler, der Pod ist weg, die Logs sind weg. Debugging wird zur Detektivarbeit ohne Spuren.

So vermeidest du es:

Nutze einen zentralen Log-Stack. Klassiker ist der EFK-Stack (Elasticsearch, Fluentd, Kibana) oder Loki mit Grafana. NWS bietet dazu Managed Prometheus & Grafana, mit dem du Logs und Metriken bequem kombinieren kannst – ohne selbst einen Logging-Stack betreiben zu müssen.

Best Practice

Nutze zentrale Logging-Lösungen wie:

• Elasticsearch + Kibana
• Loki + Grafana
• OpenSearch
• Fluent Bit oder Fluentd

Wichtige Regeln

• Logs nur temporär lokal speichern und zentralisiert aggregieren
• strukturierte JSON-Logs verwenden
• Log-Retention definieren
• sensible Daten maskieren

Storage falsch geplant – PVCs ohne Strategie

Persistenter Storage in Kubernetes ist kein einfaches Thema. Viele Teams erstellen PersistentVolumeClaims (PVCs) ad hoc, ohne sich über StorageClasses, Zugriffsmodis oder Backup-Strategie Gedanken zu machen.

Typische Fehler

• falsche StorageClasses
• fehlende Backups
• ungeeignete Zugriffsmethoden
• kein Monitoring des Speicherverbrauchs

Was passiert: Ein PVC mit accessMode: ReadWriteOnce kann nur von einem Node gemountet werden. Wenn ein Node abstürzt und ein Umzug nicht möglich ist, wird nur der Pod umgezogen und nicht PVC. Oder noch schlimmer: Daten gehen verloren, weil niemand ein Backup eingerichtet hat.

So vermeidest du es:

Plane Storage von Anfang an:

• Wähle die passende StorageClass für deinen Use Case (SSD vs. HDD, lokal vs. netzwerkbasiert)
• Prüfe den accessMode bewusst: ReadWriteMany für geteilte Volumes, ReadWriteOnce für Single-Node
• Nutze Snapshots und automatisierte Backups

Nachlässiger Umgang mit Sicherheit und RBAC

Die Falle:

Bereitstellung von Workloads mit unsicheren Konfigurationen, z. B. das Ausführen von Containern als Root-Benutzer, die Verwendung von mutable Image-Tags, das Deaktivieren von Sicherheitskontexten oder die Zuweisung zu weit gefasster RBAC-Rollen wie „cluster-admin“. Diese Praktiken halten sich hartnäckig, da Kubernetes standardmäßig nur wenige Sicherheitsvorgaben durchsetzt und die Plattform eher auf Flexibilität als auf starre Vorgaben ausgelegt ist. Ohne explizite Sicherheitsrichtlinien sind Cluster Risiken wie Container-Escapes, unbefugter Privilegieneskalation oder versehentlicher Produktionsänderungen aufgrund von nicht fixierten Images ausgesetzt.

Risiko

Ein kompromittierter Container kann:

• Secrets lesen
• Deployments verändern
• Cluster manipulieren

So vermeidest du es:

Verwende RBAC, um Rollen und Berechtigungen innerhalb von Kubernetes zu definieren. Für komplexere oder externe Richtlinienanforderungen sollten du Lösungen wie OPA Gatekeeper oder benutzerdefinierte Webhooks unter Verwendung von Richtliniensprachen wie CEL in Betracht ziehen.

Best Practice

Nutze konsequent:

• RBAC
• Least-Privilege-Prinzip

Nur exakt benötigte Rechte vergeben.

Zusätzlich:

• separate Service Accounts
• keine Default-Accounts verwenden
• regelmäßige Audits durchführen

Kein Namespace-Konzept

Ein einzelner Namespace für alles – Entwicklung, Staging, Produktion – klingt erstmal einfach. Ist es auch. Und das ist das Problem.

Probleme

• fehlende Trennung
• Sicherheitsrisiken
• unübersichtliche Ressourcen

Konflikte bei Deployments

Was passiert: Ein Entwickler löscht aus Versehen einen Deployment im falschen Namespace.

So vermeidest du es:

Strukturiere mit Namespaces konsequent. Kein Service Account sollte mehr Rechte haben als er braucht:

Least Privilege gilt in Kubernetes genauso wie überall sonst in der IT.

Best Practice

Namespaces nach:

• Teams
• Anwendungen
• Umgebungen

strukturieren.

Keine Pod Disruption Budgets definiert

Kubernetes kann Nodes für Wartung oder Upgrades leeren. Ohne Pod Disruption Budgets (PDBs) macht es das rigoros und deine Applikation ist plötzlich offline.

Was passiert: Cluster-Upgrade, Node-Drain, alle Pods eines Deployments werden gleichzeitig terminiert. Ausfall.

So vermeidest du es: Definiere ein PodDisruptionBudget. Damit legst du fest, wie viele Pods einer Anwendung (z.B. als Mindestanzahl) während freiwilliger Störungen (wie Node-Drain) immer gleichzeitig laufen müssen. 

Images ohne Versionierung – der latest-Fluch

Die Falle: 

Für Container-Images wird standardmäßig :latest genutzt. Kubernetes holt sich (abhängig von der imagePullPolicy) möglicherweise unbemerkt eine neue Version. Ein Rollout bei Pod-Neustarts kann so zu unerwarteten Breaking-Changes führen.

Was passiert: Zwei Nodes ziehen latest zu unterschiedlichen Zeitpunkten und laufen auf verschiedenen Versionen. Rollback? Welches Image war das eigentlich gestern?

So vermeidest du es: Immer konkrete Image-Tags verwenden, idealerweise mit Git-Commit-Hash, Semantic Versioning oder der von der Registry gesetzten Prüfsumme. Das macht Deployments reproduzierbar und Rollbacks beherrschbar.

ConfigMaps und Secrets direkt im Deployment gemountet und nie rotiert

Konfigurationsdaten und Secrets in Kubernetes werden gerne einmal eingebaut und dann vergessen. Das ist ein Sicherheitsrisiko und ein Betriebsproblem in einem.

Was passiert: Secrets rotieren nie, ein altes Datenbankpasswort bleibt jahrelang in Produktion. Oder: Eine ConfigMap ändert sich, aber die Pods merken davon nichts, weil kein Rollout ausgelöst wird.

So vermeidest du es:

• Nutze externe Secret-Manager wie Vault oder den Kubernetes External Secrets Operator
• Für ConfigMap-Änderungen: Trigger einen Rollout explizit mit kubectl rollout restart deployment
• Plane regelmäßige Secret-Rotation von Anfang an ein

Kein Monitoring und kein Alerting

„Das Cluster läuft doch“ – bis es das nicht mehr tut. Ohne Monitoring bist du reaktiv statt proaktiv unterwegs.

Typischer Fehler

Monitoring erst nach dem Go-Live einführen.

Monitoring gehört von Anfang an zur Plattform.

Kritische Kennzahlen

Überwacht werden sollten:

• CPU
• RAM
• Netzwerk
• Pod-Restarts
• API-Server-Latenz
• Node-Zustand
• Storage-Auslastung

Was passiert: Ein Speichervolumen läuft voll, ein Node ist seit Stunden degraded, ein Deployment hat seit dem letzten Rollout eine erhöhte Fehlerrate. Niemand weiß es, bis ein Kunde anruft.

So vermeidest du es:

Der Klassiker im Kubernetes-Umfeld ist der Prometheus + Grafana Stack. Damit sammelst du Metriken aus dem Cluster, baust Dashboards und setzt Alerts. Als Einstieg eignen sich fertige Helm Charts wie kube-prometheus-stack, die direkt sinnvolle Default-Alerts mitbringen.

NWS bietet Managed Prometheus & Grafana als fertigen Service – so nutzt du Monitoring ohne eigenen Betriebsaufwand.

Empfohlene Tools

• Prometheus
• Grafana
• Alertmanager

Fehlende Backup-Strategie

Viele Unternehmen gehen fälschlicherweise davon aus:
„Kubernetes ist hochverfügbar, also brauchen wir keine Backups.“

Was gesichert werden muss

• etcd
• Persistent Volumes
• Konfigurationen
• Secrets
• Helm Releases

Wichtig

Backups regelmäßig testen.

Ein ungetestetes Backup ist kein echtes Backup.

Den Cluster nie getestet – Chaos Engineering vergessen

Du hast alles sauber aufgebaut, Probes gesetzt, Limits definiert, Monitoring läuft. Aber weißt du wirklich, wie sich dein Cluster verhält, wenn ein Node ausfällt? Oder wenn ein Pod abstürzt?

Was passiert: Der erste echte Ausfall ist gleichzeitig der erste Test. Das geht selten gut.

So vermeidest du es:

Führe regelmäßige kontrollierte Chaos-Tests in Nicht-Produktionsumgebungen durch. Tools wie Chaos Monkey, Litmus Chaos oder einfaches manuelles Draining von Nodes helfen dabei, das Verhalten deines Clusters unter Stress zu verstehen, bevor es der echte Ernstfall tut.

Entwicklung und Produktion genau gleich behandeln

Die Falle:

Die Bereitstellung derselben Kubernetes-Manifeste mit identischen Einstellungen in Entwicklungs-, Staging- und Produktionsumgebungen. Dies geschieht oft, wenn Teams auf Konsistenz und Wiederverwendbarkeit abzielen, dabei jedoch übersehen, dass umgebungsspezifische Faktoren erheblich voneinander abweichen können. Ohne Anpassung können für eine Umgebung optimierte Konfigurationen in einer anderen zu Instabilität, schlechter Performance oder Sicherheitslücken führen.

So vermeidest du das:

Verwende Environment Overlays oder Kustomize, um eine gemeinsame Basis beizubehalten und gleichzeitig Ressourcenanforderungen, Replikate oder Konfigurationen für jede Umgebung anzupassen. Lagere umgebungsspezifische Konfigurationen in ConfigMaps und/oder Secrets aus. Zur Verwaltung vertraulicher Daten kannst du spezielle Tools wie „Sealed Secrets“ verwenden.

Checkliste für stabile Kubernetes-Cluster

Infrastruktur

• Ressourcenlimits gesetzt
• Autoscaling konfiguriert
• Storage überwacht

Sicherheit

• RBAC aktiv
• Network Policies definiert
• Images gescannt

Betrieb

• Monitoring vorhanden
• Logging zentralisiert
• Backups getestet

Deployments

• Rollbacks möglich
• CI/CD integriert
• GitOps etabliert

Fazit: Kubernetes-Fallen sind lehrreich, aber vermeidbar

Die meisten dieser Kubernetes-Fallen tauchen nicht einfach so auf. Sie entstehen, wenn Cluster schnell wachsen, Teams unter Zeitdruck stehen oder bewährte Verfahren in der Hektik des Alltags untergehen. Das Gute ist: Wer sie kennt, kann sie von Anfang an umschiffen. Ressourcenlimits, saubere Probes, zentrales Logging und ein durchdachtes Storage-Konzept sind keine Luxusfeatures, sondern die Grundlage für einen Kubernetes-Betrieb, bei dem man auch nachts ruhig schlafen kann.

Wenn du dir nicht sicher bist, ob dein Cluster auf einem soliden Fundament steht, ist ein gemanagtes Kubernetes Cluster wie NETWAYS Managed Kubernetes® eine gute Option: Autohealing, Autoscaling und eine hochverfügbare Architektur sind bereits integriert – du kannst dich auf deine Anwendungen konzentrieren.

Welche dieser Fallen hat dich schon mal erwischt? Schreib es gerne in die Kommentare oder teile den Artikel mit jemandem, der gerade seinen ersten Kubernetes-Cluster aufbaut.