Kubernetes in Produktion: 10 Best Practices aus unserer Projektpraxis

Kubernetes im Lab zu betreiben ist einfach. Es in Produktion zuverlässig, sicher und kosteneffizient zu betreiben, ist eine ganz andere Disziplin. In den vergangenen Jahren haben wir Kubernetes-Cluster in Azure (AKS), AWS (EKS) und Bare-Metal-Umgebungen gehärtet. Dies sind die zehn nicht verhandelbaren Praktiken, die wir in jedem Projekt durchsetzen.

1. Namespace-Strategie mit klaren Grenzen

Namespaces sind nicht nur organisatorische Labels — sie sind Sicherheits- und Ressourcengrenzen. Wir setzen von Tag eins eine strukturierte Namespace-Strategie durch.

Unser Vorgehen:

Ein Namespace pro Anwendung oder Microservice-Domäne (niemals ein gemeinsamer „apps"-Namespace)
Dedizierte Namespaces für Plattform-Belange: monitoring, ingress, cert-manager, external-secrets
ResourceQuotas auf jedem Namespace, um zu verhindern, dass ein einzelnes Team Cluster-Ressourcen erschöpft
LimitRanges für Standard-CPU/Memory-Requests und -Limits bei Pods, die keine eigenen Werte angeben

YAML

apiVersion: v1
kind: ResourceQuota
metadata:
  name: team-alpha-quota
  namespace: team-alpha
spec:
  hard:
    requests.cpu: "8"
    requests.memory: 16Gi
    limits.cpu: "16"
    limits.memory: 32Gi
    pods: "50"

2. RBAC nach dem Least-Privilege-Prinzip

Das Standard-RBAC in Kubernetes ist zu permissiv. Wir bauen RBAC nach dem Zero-Trust-Prinzip auf.

Keine cluster-admin-Bindings außer für Plattform-Operatoren — und diese über PIM oder zeitlich begrenzt
Namespace-scoped RoleBindings an AD-Gruppen gebunden (via Azure-AD-Integration bei AKS)
Entwickler erhalten eine Custom Role mit Get/List/Watch auf den meisten Ressourcen, Exec in Pods nur in Nicht-Produktion und Create/Delete auf Pods nur im eigenen Namespace
Audit-Logging aktiviert, um nachzuvollziehen, wer was getan hat (AKS Diagnostic Settings > kube-audit-admin)

3. Resource Requests und Limits auf jedem Pod

Pods ohne Resource Requests sind nicht sinnvoll schedulbar — der Scheduler kann keine informierten Platzierungsentscheidungen treffen, was zu Noisy-Neighbour-Problemen und Node-Überallokation führt.

Unsere Regel:

Jeder Pod muss requests und limits für CPU und Memory deklarieren
Durchsetzung via OPA Gatekeeper oder Kyverno-Policy, die Pods ohne diese Felder ablehnt
Right-Sizing mit dem Vertical Pod Autoscaler (VPA) im Recommend-Only-Modus, dann Ergebnisse anwenden

Häufiger Fehler: Zu aggressive CPU-Limits verursachen Throttling, das für Anwendungsteams unsichtbar ist. Wir empfehlen, CPU-Limits auf das 2-4-fache des Request-Werts zu setzen und Throttling über container_cpu_cfs_throttled_periods_total zu monitoren.

4. Network Policies als Default-Deny

Standardmäßig kann in einem Kubernetes-Cluster jeder Pod mit jedem anderen Pod kommunizieren. In Produktion ist das nicht akzeptabel.

Default-Deny NetworkPolicy in jedem Namespace deployen
Nur erforderliche Ingress- und Egress-Flows explizit erlauben
Cilium oder Calico als CNI verwenden — Azure CNI mit Network-Policy-Support funktioniert bei AKS
Network Policies im Staging mit Traffic-Mirroring testen, bevor sie in Produktion erzwungen werden

5. Pod Security Standards (nicht Pod Security Policies)

Pod Security Policies wurden in Kubernetes 1.21 deprecated und in 1.25 entfernt. Verwenden Sie Pod Security Standards (via Pod Security Admission) oder OPA Gatekeeper.

Mindestanforderung: das restricted-Profil in Produktions-Namespaces:

Keine privilegierten Container
Kein Host-Namespace-Sharing
Read-Only Root Filesystem
Non-Root User
Keine Privilege Escalation

6. Secrets Management richtig umsetzen

Kubernetes Secrets sind base64-kodiert, aber standardmäßig nicht verschlüsselt gespeichert. Das ist kein Secrets Management.

Unser Ansatz:

etcd-Verschlüsselung at rest aktivieren (Standard bei AKS, muss bei Self-Managed konfiguriert werden)
External Secrets Operator nutzen, um Secrets aus Azure Key Vault, HashiCorp Vault oder AWS Secrets Manager zu synchronisieren
Secrets niemals in Git speichern — auch nicht verschlüsselt (Sealed Secrets nur als letzter Ausweg)
Secrets automatisch rotieren mit einer maximalen Lebensdauer von 90 Tagen
Secrets als Dateien mounten, nicht als Umgebungsvariablen (Umgebungsvariablen erscheinen in Logs und Prozesslisten)

7. GitOps für alle Deployments

Manuelles kubectl apply in Produktion ist ein Incident, der nur auf seine Gelegenheit wartet. Jedes Deployment muss über eine Git-basierte Pipeline laufen.

ArgoCD oder Flux als GitOps-Operator
Alle Manifeste in einem dedizierten Git-Repository (nicht im Anwendungs-Repository)
Pull-basiertes Deployment: Der Cluster zieht den gewünschten Zustand aus Git, nicht umgekehrt
Drift-Detection-Alarme, wenn jemand manuell eine Ressource ändert
Promotion über Umgebungen via Branch-Strategie oder Verzeichnisstruktur, nie durch direkte Manifest-Änderung

8. Observability: Metriken, Logs, Traces

Was man nicht sehen kann, kann man nicht betreiben. Wir deployen einen standardisierten Observability-Stack auf jedem Cluster.

Metriken: Prometheus (oder Azure Monitor Managed Prometheus) + Grafana mit vorgefertigten Dashboards für Cluster-, Node-, Namespace- und Pod-Level
Logs: Fluent Bit mit Weiterleitung an ein zentrales Backend (Azure Monitor, Elasticsearch oder Loki)
Traces: OpenTelemetry Collector mit Export nach Jaeger oder Azure Application Insights
Alerting-Regeln für: Node NotReady, Pod CrashLoopBackOff, PVC nahe Kapazitätsgrenze, Zertifikatsablauf, HPA bei Max-Replicas

Nicht verhandelbar: Jeder Cluster muss ein Dashboard haben, das die Fragen „Ist der Cluster gesund?" und „Ist meine Anwendung gesund?" in unter 30 Sekunden beantwortet.

9. Ingress und TLS-Terminierung

Einen einzelnen Ingress Controller pro Cluster verwenden (NGINX Ingress Controller oder Azure Application Gateway Ingress Controller)
TLS am Ingress terminieren mit Zertifikaten von cert-manager + Let's Encrypt (oder interner CA)
Nur-HTTPS erzwingen — HTTP am Ingress auf HTTPS umleiten
Rate Limiting, Request-Size-Limits und Timeouts am Ingress Controller konfigurieren
Für Multi-Tenant-Cluster: separate Ingress Controller pro Mandanten-Namespace erwägen

10. Cluster-Upgrades und Patch-Management

Kubernetes veröffentlicht drei Minor-Versionen pro Jahr, jede mit einem 14-monatigen Support-Fenster. Bei Upgrades in Rückstand zu geraten, ist ein Sicherheits- und Supportrisiko.

Unser Rhythmus:

Upgrade auf die letzte stabile Minor-Version innerhalb von 60 Tagen nach Release
Upgrades in einem Staging-Cluster testen, der die Produktions-Nodepools und -Workloads spiegelt
Node Surge Upgrades (AKS) oder rollende Node-Ablösungen nutzen, um Downtime zu vermeiden
Deprecation-Notes für jedes Release prüfen — API-Entfernungen brechen Workloads lautlos
Automatisches Node-OS-Patching (z. B. AKS Auto-Upgrade-Channel auf node-image)

Das Gesamtbild

Diese Praktiken sind keine Wunschvorstellungen — sie sind die Baseline. Wir kodifizieren sie als Gatekeeper/Kyverno-Policies, Terraform-Module und ArgoCD ApplicationSets, sodass sie automatisch durchgesetzt werden, nicht per Konvention.

Das Ziel ist ein Cluster, auf dem ein neues Entwicklungsteam ab Tag eins deployen kann — in dem Wissen, dass Sicherheit, Observability und Kostenleitplanken bereits vorhanden sind.

Wie wir unterstützen

Weiterführende Ressourcen

GitOps für Kubernetes mit Flux — Deklarative Bereitstellung für Ihre Kubernetes-Workloads.
DevSecOps-Pipeline-Design — Integrieren Sie Sicherheit in Ihre Container-Build- und Deploy-Pipeline.
Platform Engineering: Aufbau einer internen Entwicklerplattform — Die Plattformschicht, die Kubernetes-Komplexität für Ihre Teams abstrahiert.

CC Conceptualise bietet ein Kubernetes Production Readiness Assessment — ein einwöchiges Review Ihrer bestehenden Cluster gegen diese zehn Praktiken, mit priorisiertem Remediation-Backlog als Ergebnis. Für Greenfield-Deployments liefern wir produktionsgehärtete Cluster im Rahmen unserer Platform-Engineering-Projekte. Sprechen Sie uns an.