Kubernetes Architektur Review: 15 Red Flags die 50.000 Euro kosten koennen

TL;DR

• Die drei teuersten Fehler sind: fehlende Resource Requests/Limits, zu weit gefasste RBAC-Regeln und fehlende NetworkPolicies
• Ein systematisches Review prueft fuenf Bereiche: Ressourceneffizienz, Sicherheit, Netzwerk, Storage und Betriebsprozesse
• Die meisten Optimierungen lassen sich ohne Downtime umsetzen, wenn Sie mit den Low-Hanging-Fruits anfangen
• Automatisierte Tools (Trivy, Polaris, kube-score) finden 60-70% der Probleme; die restlichen 30-40% erfordern manuelles Review durch erfahrene Engineers

Warum Architektur-Reviews notwendig sind

Kubernetes-Cluster sind lebende Systeme. Sie werden ueber Monate und Jahre aufgebaut, erweitert und veraendert -- oft von wechselnden Teams mit unterschiedlichem Wissensstand. Das Ergebnis: Konfigurationsdrift, veraltete Patterns und Fehlkonfigurationen, die sich schleichend ansammeln.

Ein einziger uebergrosser PersistentVolumeClaim, der seit sechs Monaten ungenutzt laeuft, kann 200 Euro pro Monat kosten. Fehlende Resource Limits auf einem Deployment fuehren dazu, dass ein Memory Leak einen ganzen Node lahmlegt. Eine RBAC-Rolle mit cluster-admin fuer ein Team, das eigentlich nur Logs lesen soll, ist ein Sicherheitsrisiko, das bei einem Audit teuer wird.

Architektur-Reviews sind kein einmaliges Ereignis. Sie sollten mindestens einmal pro Jahr durchgefuehrt werden, idealerweise halbjaehrlich. Der Aufwand liegt typischerweise bei 3-5 Tagen fuer einen mittelgrossen Cluster.

Die 15 haeufigsten Red Flags

Kategorie 1: Ressourceneffizienz

Red Flag 1: Fehlende oder unrealistische Resource Requests und Limits. Das ist der haeufigste Fehler. Ohne Requests kann der Scheduler Pods nicht sinnvoll platzieren. Ohne Limits kann ein einzelner Pod einen ganzen Node destabilisieren. Zu hohe Requests fuehren zu Verschwendung, weil Kapazitaet reserviert aber nicht genutzt wird.

# Schlecht: Keine Resources definiert
spec:
  containers:
    - name: api
      image: api:v1.2.0

# Besser: Realistische Werte basierend auf Monitoring-Daten
spec:
  containers:
    - name: api
      image: api:v1.2.0
      resources:
        requests:
          cpu: "100m"
          memory: "128Mi"
        limits:
          cpu: "500m"
          memory: "256Mi"

Woher kommen die richtigen Werte? Aus Prometheus-Metriken. Schauen Sie sich container_memory_working_set_bytes und container_cpu_usage_seconds_total ueber mindestens eine Woche an. Setzen Sie Requests auf den P95-Wert und Limits auf das 2-3-fache davon. Details dazu finden Sie in unserem Artikel zu Kubernetes Capacity Planning.

Red Flag 2: Kein Horizontal Pod Autoscaler (HPA). Wenn Ihre Anwendung variable Last hat (und welche hat das nicht?), verschwenden Sie ohne HPA entweder Ressourcen in Zeiten niedriger Last oder haben Performance-Probleme bei Lastspitzen.

Red Flag 3: Ueberdimensionierte Nodes. Ein Cluster mit drei m5.4xlarge-Nodes (jeweils 16 vCPU, 64 GB RAM), die zu 20% ausgelastet sind, verbrennt Geld. Kleinere Nodes mit Cluster Autoscaler sind fast immer kosteneffizienter. Mehr dazu unter Kubernetes Cluster Autoscaler.

Kategorie 2: Sicherheit

Red Flag 4: RBAC-Rollen mit zu breiten Berechtigungen. cluster-admin fuer Entwickler, Wildcards in Verbs oder Resources, fehlende Namespace-Scoping. Pruefen Sie mit:

# Alle ClusterRoleBindings mit cluster-admin finden
kubectl get clusterrolebindings -o json | \
  jq -r '.items[] | select(.roleRef.name=="cluster-admin") |
  "\(.metadata.name): \(.subjects[].name) (\(.subjects[].kind))"'

# Alle Rollen mit Wildcard-Verbs finden
kubectl get clusterroles -o json | \
  jq -r '.items[] | select(.rules[]?.verbs[]? == "*") | .metadata.name'

Red Flag 5: Fehlende NetworkPolicies. Ohne NetworkPolicies kann jeder Pod mit jedem anderen Pod kommunizieren, ueber Namespace-Grenzen hinweg. Das ist das Kubernetes-Aequivalent einer flachen Netzwerkarchitektur ohne Firewalls. Lesen Sie dazu auch unseren Beitrag zur Kubernetes Network Security.

Red Flag 6: Secrets im Klartext in ConfigMaps oder Umgebungsvariablen. Es kommt haeufiger vor, als man denkt. Datenbankpasswoerter in einer ConfigMap, API-Keys als Umgebungsvariable im Deployment-Manifest, das in einem oeffentlichen Repository liegt.

Red Flag 7: Container laufen als Root. Wenn kein SecurityContext definiert ist, laufen Container standardmaessig als Root. Ein Container-Escape bei einem Root-Container bedeutet Root auf dem Node.

Red Flag 8: Keine Pod Security Standards oder Admission Controller. Ohne Kyverno, OPA Gatekeeper oder Pod Security Admission gibt es nichts, das die Einhaltung von Sicherheitsrichtlinien erzwingt. Alles haengt davon ab, dass Entwickler sich an Konventionen halten.

Kategorie 3: Netzwerk

Red Flag 9: Kein Ingress Controller oder falsch konfigurierter Ingress. Services direkt als LoadBalancer exponieren ist teuer (jeder Service bekommt einen eigenen Cloud-Load-Balancer) und unuebersichtlich. Ein zentraler Ingress Controller mit TLS-Terminierung ist der Standard.

Red Flag 10: Fehlende TLS-Terminierung oder abgelaufene Zertifikate. cert-manager mit Let's Encrypt loest das Problem dauerhaft. Kein Grund, Zertifikate manuell zu verwalten.

Kategorie 4: Storage

Red Flag 11: Falsche StorageClass oder Access Modes. ReadWriteMany (RWX) ist verlockend, aber nicht jeder CSI-Treiber unterstuetzt es performant. Oft wird RWX verwendet, obwohl ReadWriteOnce (RWO) reichen wuerde, was zu unnoetig teuren NFS-Setups fuehrt.

Red Flag 12: Kein Backup fuer PersistentVolumes. Velero oder ein cloud-nativer Backup-Service sollte alle wichtigen PVs regelmaessig sichern. Testen Sie auch regelmaessig den Restore.

Kategorie 5: Betriebsprozesse

Red Flag 13: Kein Monitoring oder ungenutztes Monitoring. Ein Prometheus, der laeuft aber dessen Alerts niemand konfiguriert hat, ist so nuetzlich wie eine Brandmeldeanlage ohne Kabel. Lesen Sie dazu Kubernetes Monitoring.

Red Flag 14: Kein GitOps oder manuelles kubectl apply. Jeder manuelle Eingriff ist ein potenzieller Konfigurationsdrift. GitOps mit Argo CD oder Flux stellt sicher, dass der Cluster-Zustand immer dem Repository-Zustand entspricht. Mehr dazu unter GitOps mit Argo CD.

Red Flag 15: Keine Upgrade-Strategie. Kubernetes-Versionen haben einen Support-Zeitraum von etwa 14 Monaten. Cluster, die zwei oder mehr Minor-Versionen hinter der aktuellen Version liegen, verpassen Sicherheitspatches und riskieren, dass der Upgrade-Pfad kompliziert wird.

Systematisches Review in fuenf Schritten

Schritt 1: Automatisierte Scans

Beginnen Sie mit automatisierten Tools, die die offensichtlichen Probleme finden:

# kube-score bewertet Manifeste nach Best Practices
kubectl get all -A -o yaml | kube-score score -

# Polaris prueft Deployments auf Security und Reliability
polaris audit --format=pretty

# Trivy scannt den gesamten Cluster auf Schwachstellen
trivy k8s --report=summary cluster

# Pluto findet deprecated API-Versionen
pluto detect-all-in-cluster

Diese Tools liefern einen guten Ueberblick, aber sie koennen keine Architektur-Entscheidungen bewerten. Sie finden fehlende Probes, aber nicht, ob die Probe-Konfiguration zum Anwendungsverhalten passt.

Schritt 2: Ressourcenauslastung analysieren

Schauen Sie sich die tatsaechliche Ressourcennutzung an, nicht die angeforderten Werte. Prometheus-Queries wie diese sind aufschlussreich:

• CPU-Overcommitment: sum(kube_pod_container_resource_requests{resource="cpu"}) / sum(kube_node_status_allocatable{resource="cpu"})
• Memory-Overcommitment: Gleiche Formel mit memory
• Ungenutzte PVCs: kubelet_volume_stats_used_bytes / kubelet_volume_stats_capacity_bytes (alles unter 10% ist verdaechtig)

Schritt 3: RBAC-Audit

RBAC ist einer der Bereiche, die am staerksten von Entropy betroffen sind. Rollen werden angelegt, aber selten entfernt. Service Accounts bekommen Berechtigungen "fuer den Moment" und behalten sie fuer immer.

Pruefen Sie insbesondere: Wer hat cluster-admin? Welche Service Accounts haben Zugriff auf Secrets in anderen Namespaces? Gibt es Rollen mit * als Verb oder Resource?

Schritt 4: Netzwerk-Review

Testen Sie, ob Ihre NetworkPolicies tatsaechlich greifen. Deployen Sie einen Debug-Pod in einem Namespace und versuchen Sie, andere Services zu erreichen. Wenn das gelingt und es nicht sollte, fehlen Policies.

Schritt 5: Disaster-Recovery-Test

Der beste Architektur-Review ist ein Disaster-Recovery-Test. Koennen Sie den Cluster aus Ihrem GitOps-Repository wiederherstellen? Sind alle Secrets extern gespeichert (Vault, Cloud KMS)? Wie lange dauert es, bis die Anwendungen wieder laufen?

Bewertungsmatrix fuer Findings

Nicht jedes Finding ist gleich kritisch. Nutzen Sie eine einfache Matrix zur Priorisierung:

Was ein Review typischerweise findet

Aus der Erfahrung mit dutzenden Cluster-Reviews hier eine realistische Einschaetzung, was zu erwarten ist:

Kostenoptimierung: Die meisten Cluster sind 20-40% ueberprovisioniert. Das liegt an zu grosszuegigen Resource Requests, ungenutzten PVCs und ueberdimensionierten Nodes. Die Einsparungen nach einem Review liegen typischerweise bei 15-30% der monatlichen Infrastrukturkosten.

Sicherheit: Fast jeder Cluster hat mindestens ein RBAC-Problem (zu breite Berechtigungen) und fehlende NetworkPolicies. In etwa der Haelfte der Faelle laufen Container als Root oder haben keine Security Contexts definiert.

Stabilitaet: Fehlende Liveness/Readiness Probes, zu aggressive Probes (die gesunde Pods killen), fehlende PodDisruptionBudgets und nicht konfiguriertes Pod-Anti-Affinity sind die haeufigsten Stabilitaetsprobleme.

DSGVO-relevante Aspekte im Review

Kubernetes-Cluster verarbeiten haeufig personenbezogene Daten. Ein Architektur-Review sollte deshalb auch DSGVO-relevante Aspekte pruefen:

• Datenlokalitaet: Wo laufen die Nodes? Wo liegen die PersistentVolumes physisch? Werden Daten unbeabsichtigt in Regionen ausserhalb der EU repliziert?
• Zugriffskontrolle: Ist RBAC so konfiguriert, dass nur berechtigte Personen auf Namespaces mit personenbezogenen Daten zugreifen koennen?
• Logging: Werden personenbezogene Daten versehentlich in Logs geschrieben? Gibt es eine Retention-Policy fuer Logs?
• Verschluesselung: Ist etcd-Encryption-at-Rest aktiviert? Laeuft die Cluster-interne Kommunikation verschluesselt (mTLS)?

Der Ablauf eines professionellen Reviews

Ein typisches Review fuer einen mittelgrossen Cluster (5-20 Nodes, 50-200 Workloads) dauert 3-5 Tage:

Tag 1: Kickoff und Datenerhebung. Ziele abstimmen, Cluster-Zugang einrichten (read-only ServiceAccount), automatisierte Scans laufen lassen, erste Interviews mit dem Operations-Team fuehren.

Tag 2-3: Analyse. Automatisierte Scan-Ergebnisse auswerten, manuelle Tiefenanalyse der Bereiche Sicherheit, Ressourcen, Netzwerk und Storage. Prometheus-Metriken auswerten, RBAC-Konfiguration pruefen, NetworkPolicies testen.

Tag 4: Bericht und Empfehlungen. Findings dokumentieren, priorisieren und konkrete Handlungsempfehlungen formulieren. Jedes Finding bekommt eine Prioritaet, eine Beschreibung des Risikos und einen konkreten Fix.

Tag 5: Praesentation und Workshop. Ergebnisse vorstellen, Fragen klaeren, gemeinsam die Umsetzungsreihenfolge festlegen.

Quick Wins nach dem Review

Diese Massnahmen lassen sich meist innerhalb einer Woche umsetzen und bringen sofortigen Mehrwert:

1. Resource Requests/Limits setzen fuer alle Deployments ohne definierte Werte
2. Default-Deny NetworkPolicies in allen Namespaces einrichten
3. Ungenutzte PVCs und LoadBalancer identifizieren und loeschen
4. Security Contexts erzwingen via Pod Security Admission oder Kyverno
5. cert-manager installieren fuer automatische TLS-Zertifikate

Fuer komplexere Massnahmen wie die Einfuehrung von GitOps oder die Umstellung auf eine neue Storage-Strategie empfehlen wir eine schrittweise Umsetzung ueber 4-8 Wochen. Einen Einstieg in GitOps bietet unser Argo CD Tutorial.

Fazit

Ein Kubernetes Architektur Review ist kein Misstrauensvotum gegen Ihr Team. Es ist eine Investition in die Qualitaet und Wirtschaftlichkeit Ihrer Infrastruktur. Die meisten Teams sind ueberrascht, wie viel Optimierungspotenzial in ihrem Cluster steckt, insbesondere bei den Kosten.

Der beste Zeitpunkt fuer ein Review ist jetzt, nicht wenn die naechste Rechnung oder der naechste Sicherheitsvorfall kommt. Fangen Sie mit den automatisierten Tools an und eskalieren Sie zu einem professionellen Review, wenn die Ergebnisse Fragen aufwerfen.

Bei Interesse an einem Review oder Fragen zur Vorgehensweise koennen Sie uns unter /kontakt erreichen.