Kubernetes kann alles ausführen. Das ist seine Stärke und sein Problem. Ohne eine klare Produktionscheckliste wird der Container-Orchestrator zum Incident-Generator. Dieser Artikel umfasst 15 Punkte, die wir bei jedem Cluster prüfen, bevor wir ihn als produktionsreif markieren. Keine Theorie — konkrete Konfigurationen, YAML-Snippets und Erklärungen, warum jeder Punkt wichtig ist.
Warum Kubernetes-Deployments in Produktion scheitern¶
Die meisten K8s-Incidents, die wir behandeln, hängen nicht mit Bugs in Kubernetes selbst zusammen. Das Problem liegt fast immer in der Konfiguration — in dem, was das Team übersprungen hat, weil es „für die Dev-Umgebung nicht nötig war.” Drei Gründe dominieren unsere Incident-Statistik.
Fehlende Resource Limits und Requests¶
Ein einzelner Pod ohne Limits kann den gesamten Speicher eines Nodes verbrauchen und andere Workloads zum Absturz bringen. In der Entwicklung spielt das keine Rolle — in Produktion bedeutet es einen PagerDuty-Alert um 3 Uhr morgens. Ohne Resource Requests kann der Scheduler Pods nicht sinnvoll platzieren und der Cluster wird unberechenbar. Dies ist die häufigste Ursache für OOM Kills, die wir bei Kunden sehen.
Keine Health Checks¶
Kubernetes ohne Liveness- und Readiness-Probes weiß nicht, ob Ihre Anwendung läuft oder nur Platz belegt. Ein Pod kann in einem Deadlock hängen, keine Requests zurückgeben, aber Kubernetes hält ihn für gesund, weil der Prozess noch existiert. Ergebnis: Benutzer erhalten 502-Fehler und Sie wissen nicht warum — schließlich sind alle Pods „Running.”
Flaches Netzwerk ohne Policies¶
Standardmäßig kann in Kubernetes jeder Pod mit jedem anderen Pod kommunizieren. Das ist bequem für die Entwicklung und katastrophal für die Sicherheit. Ein kompromittierter Pod in einem Namespace hat freien Zugriff auf eine Datenbank in einem anderen Namespace. Ohne Network Policies ist der gesamte Cluster ein großes flaches Netzwerk ohne jegliche Segmentierung.
Diese drei Probleme haben einen gemeinsamen Nenner: Sie entstehen, weil Konfiguration, die in der Entwicklung funktioniert, ohne Anpassungen in die Produktion kopiert wird. Unsere Checkliste existiert, um diese Lücke systematisch zu schließen.
Cluster-Setup¶
4 Punkte
1
Multi-Node Control Plane¶
Ein einzelner Control-Plane-Node bedeutet einen Single Point of Failure für den gesamten Cluster. In Produktion betreiben wir mindestens 3 Master-Nodes verteilt über Availability Zones. Etcd-Quorum erfordert eine ungerade Anzahl von Mitgliedern — 3 Nodes tolerieren einen Ausfall, 5 Nodes tolerieren zwei. Bei Managed Services (EKS, AKS, GKE) übernimmt das der Provider, aber bei selbstverwalteten Clustern ist dies das Erste, was wir prüfen.
2
Node-Auto-Scaling mit definierten Limits¶
Der Cluster-Autoscaler muss sowohl Mindest- als auch Maximal-Nodezahlen haben. Ohne Obergrenze kann ein außer Kontrolle geratenes Deployment Dutzende von Nodes hochfahren und eine astronomische Cloud-Rechnung verursachen. Ohne Untergrenze kann der Autoscaler den Cluster so stark verkleinern, dass die verbleibenden Nodes nicht einmal den Baseline-Traffic bewältigen. Wir definieren beides und fügen Billing-Alerts hinzu.
3
Etcd-Backup und -Wiederherstellung¶
Etcd ist das Gehirn des Clusters — es enthält den gesamten Zustand. Regelmäßige Etcd-Datenbank-Snapshots sind unverzichtbar. Wir automatisieren Backups alle 30 Minuten auf externen Speicher (S3, GCS) und testen jedes Quartal die Wiederherstellungsprozedur. Ein Backup, das niemand getestet hat, ist kein Backup — es ist ein Wunsch.
4
Cluster-Upgrade-Strategie¶
Kubernetes veröffentlicht alle 4 Monate eine Minor-Version und unterstützt die letzten 3 Versionen. Wer zwei Versionen überspringt, dem steht ein schmerzhaftes Upgrade mit Breaking Changes bevor. Wir halten Cluster maximal eine Version hinter der aktuellen Stable, upgraden mit Rolling-Strategie Node für Node und immer erst Staging, dann Produktion.
Workload-Konfiguration¶
4 Punkte
5
Resource Requests und Limits auf jedem Pod¶
Jeder Container muss deklarieren, wie viel CPU und Speicher er benötigt (Request) und wie viel er maximal verbrauchen darf (Limit). Request bestimmt das Scheduling — Kubernetes platziert den Pod auf einem Node mit genügend freien Ressourcen. Limit schützt andere Workloads — das Überschreiten des Speicherlimits führt zu einem OOM Kill, nicht zum Absturz der Nachbarn.
`# Resource requests & limits — realistic values
resources:
requests:
cpu: "250m"
memory: "256Mi"
limits:
cpu: "1000m"
memory: "512Mi"`
6
Liveness-, Readiness- und Startup-Probes¶
Drei Arten von Probes, drei verschiedene Zwecke. Liveness erkennt Deadlocks — wenn sie fehlschlägt, startet Kubernetes den Container neu. Readiness steuert den Traffic — wenn sie fehlschlägt, wird der Pod von den Service-Endpoints entfernt. Startup schützt langsame Anwendungen beim Start. Ohne sie kann Kubernetes nicht zwischen einem gesunden und einem toten Pod unterscheiden.
`# Probes — HTTP check with reasonable timeouts
livenessProbe:
httpGet:
path: /healthz
port: 8080
initialDelaySeconds: 15
periodSeconds: 10
failureThreshold: 3
readinessProbe:
httpGet:
path: /ready
port: 8080
periodSeconds: 5
failureThreshold: 2
startupProbe:
httpGet:
path: /healthz
port: 8080
failureThreshold: 30
periodSeconds: 5`
7
Pod Disruption Budgets¶
PDB definiert, wie viele Pods während freiwilliger Disruptions (Node Drain, Cluster-Upgrade, Autoscaling) verfügbar bleiben müssen. Ohne PDB kann ein Upgrade alle Replicas gleichzeitig abschalten. Für kritische Dienste setzen wir minAvailable: 50% oder maxUnavailable: 1 — so bedient mindestens die Hälfte der Pods den Traffic auch während der Wartung.
8
Anti-Affinity und Topology Spread¶
Alle Replicas auf einem Node = ein Hardwareausfall legt den gesamten Dienst lahm. Pod-Anti-Affinity-Regeln verteilen Replicas über Nodes, Topology-Spread-Constraints verteilen sie über Zonen. Das ist eine Versicherung gegen korrelierte Ausfälle — und kostet genau null extra.
Observability¶
4 Punkte
9
Metrics-Pipeline (Prometheus + Grafana)¶
Ohne Metriken fliegen Sie blind. Prometheus sammelt Metriken von kubelet, kube-state-metrics und Ihren Anwendungen. Grafana visualisiert sie. Mindest-Dashboard: CPU/Speicher pro Node und Pod, Request Rate, Error Rate, Latenz (RED-Metriken). Kube-prometheus-stack liefert das mit einem einzigen Helm-Install — es gibt keinen Grund, es nicht zu haben.
10
Zentralisiertes Logging¶
kubectl logs funktioniert nicht, wenn der Pod nicht existiert. In Produktion brauchen Logs eine längere Lebensdauer als der Pod — wir senden sie an ein zentrales System (Loki, Elasticsearch, CloudWatch). Strukturierte Logs (JSON) mit Correlation IDs ermöglichen das Tracing eines Requests über Services hinweg. Ohne das ist das Debugging einer verteilten Anwendung Detektivarbeit ohne Beweise.
11
Distributed Tracing¶
In einer Microservices-Architektur durchläuft ein einzelner Request Dutzende von Services. Wenn die Latenz steigt, müssen Sie wissen wo. OpenTelemetry ist heute der Standard — Sie instrumentieren Anwendungen einmal und senden Traces an Jaeger, Tempo oder Datadog. Die Verknüpfung von Traces mit Logs und Metriken (drei Säulen der Observability) macht den Unterschied zwischen „es ist wahrscheinlich langsam” und „ich weiß genau warum.”
12
Alerting mit Runbooks¶
Ein Alert ohne Runbook ist Rauschen. Jeder Alert im Alertmanager muss einen Link zu einem Runbook haben — einem Dokument, das sagt, was der Alert bedeutet, wie man die Ursache verifiziert und wie man das Problem behebt. Wir alerten auf Symptome (Fehlerrate > 1 %), nicht auf Ursachen (CPU > 80 %). Und wir haben drei Severity-Level: critical (Leute wecken), warning (bis zum Morgen lösen), info (während der Geschäftszeiten prüfen).
Sicherheit¶
3 Punkte
13
Network Policies¶
Default-Deny für eingehenden Traffic und explizit nur die benötigte Kommunikation erlauben. Die Datenbank sollte nur Verbindungen von Backend-Pods akzeptieren, nicht von allem im Cluster. Network Policies sind die Kubernetes-Version von Firewall-Regeln — und sollten genauso strikt sein.
`# Network Policy — default deny + allow for backend
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: db-allow-backend-only
namespace: production
spec:
podSelector:
matchLabels:
app: postgres
policyTypes:
- Ingress
ingress:
- from:
- podSelector:
matchLabels:
app: backend
ports:
- port: 5432`
14
RBAC und Least Privilege¶
Jede Anwendung läuft unter einem eigenen ServiceAccount mit minimalen Berechtigungen. Kein cluster-admin für CI/CD-Pipelines, keine Wildcard-Berechtigungen. Wir definieren Roles und ClusterRoles granular — eine Anwendung, die ConfigMaps liest, braucht nicht das Recht, Secrets zu löschen. Wir auditieren regelmäßig Berechtigungen mit kubectl auth can-i --list und entfernen ungenutzte Rollen.
15
Pod Security Standards und Image Scanning¶
Container laufen nicht als Root, haben keinen privilegierten Modus und können keine Privilegien eskalieren. Pod Security Admission (Nachfolger von PodSecurityPolicy) erzwingt diese Standards auf Namespace-Ebene. Dazu Image Scanning in CI/CD — Trivy oder Grype prüfen CVEs in Base Images vor dem Deploy, nicht nach einem Incident. Supply Chain Security beginnt beim Image.
Anti-Patterns, die wir immer wieder sehen¶
Die Checkliste sagt, was zu tun ist. Ebenso wichtig ist zu wissen, was man nicht tun sollte. Diese Anti-Patterns sehen wir bei Kunden wiederholt — und sie kosten immer Zeit, Geld oder beides.
„latest”-Tag in Produktion¶
Das :latest-Tag ist veränderlich — das heutige latest ist anders als das morgige. Ergebnis: zwei Pods mit dem gleichen Deployment-Manifest laufen verschiedene Code-Versionen. Verwenden Sie immer unveränderliche Tags — SHA-Digests oder semantische Versionen.
kubectl apply vom Laptop¶
Manuelle Deploys umgehen Code Review, Audit Trails und Rollback-Mechanismen. Alles in Produktion geht über GitOps (ArgoCD, Flux) — Git ist die Single Source of Truth, niemand deployt über CLI.
Secrets in Umgebungsvariablen¶
Env Vars sind sichtbar in kubectl describe pod, in Logs und in Crash Dumps. Secrets gehören in Kubernetes Secrets (mindestens), idealerweise in einen externen Secrets Manager (Vault, AWS Secrets Manager) mit Rotation.
Ein Namespace für alles¶
Ein Namespace ist eine Sicherheits- und Organisationsgrenze. Produktion, Staging und Entwicklung in einem Namespace bedeutet geteilte RBAC, Resource Quotas und Network Policies. Trennen Sie Umgebungen, trennen Sie Teams, trennen Sie Risiken.
Wie wir es bei CORE SYSTEMS machen¶
Wir betreiben Kubernetes für Kunden in Banken, Logistik und Einzelhandel — Umgebungen, in denen Ausfallzeiten echtes Geld kosten und der Regulator nach Nachweisen fragt. Unser Ansatz für K8s Production Readiness hat drei Phasen.
Audit. Wir beginnen mit einem automatisierten Scan der bestehenden Konfiguration mit einem Tool, das alle 15 Punkte dieser Checkliste plus weitere 30+ branchenspezifische Regeln prüft. Das Ergebnis ist ein Bericht mit einer priorisierten Liste von Befunden — kein generisches PDF, sondern konkrete YAML-Patches, die Sie direkt anwenden können.
Implementierung. Wir implementieren Korrekturen als Merge Requests in das GitOps-Repository des Kunden. Jede Änderung durchläuft Code Review, wird auf dem Staging-Cluster getestet und über ArgoCD mit automatischem Rollback bei Health-Check-Fehlern deployt. Keine manuellen Eingriffe, volle Nachvollziehbarkeit.
Betrieb. Nach der Hardening-Phase bieten wir kontinuierliches Monitoring — Dashboards, Alerting und monatliche Compliance-Reports. Cluster-Drift (Abweichung vom definierten Zustand) wird automatisch erkannt und behoben, bevor er sich als Incident manifestiert. Denn der günstigste Incident ist der, der nie passiert.
Fazit: Production Readiness ist keine einmalige Aufgabe¶
Die 15 Punkte in dieser Checkliste sind keine einmalige Aufgabe, die Sie abhaken und vergessen. Es ist ein lebendiger Standard, der sich mit Ihrer Anwendung, Ihrem Team und Ihrer Infrastruktur weiterentwickelt. Ein Cluster, der vor einem Jahr produktionsreif war, muss es heute nicht mehr sein — ein neuer Dienst wurde hinzugefügt, Traffic-Muster haben sich geändert, eine neue K8s-Version wurde veröffentlicht.
Der Schlüssel ist Automatisierung. Prüfungen in der CI/CD-Pipeline, Policy Enforcement über OPA/Kyverno, automatische Alerts bei Drift von der Baseline. Menschen sollten nicht manuell prüfen, ob ein Deployment Resource Limits hat — das ist eine Aufgabe für Maschinen. Menschen sollten über Architektur nachdenken, Kapazitätsplanung und wie man das System auf die nächste Größenordnung skaliert.
Brauchen Sie Hilfe bei der Implementierung?
Unsere Experten helfen Ihnen bei Design, Implementierung und Betrieb. Von der Architektur bis zur Produktion.
Kontaktieren Sie uns