18 Kubernetes-Komponenten die Ihr Admin nicht alleine stemmen kann

TL;DR

• Ein produktionsreifer Kubernetes-Cluster besteht nicht nur aus der Control Plane und Worker Nodes. Mindestens 18 zusaetzliche Komponenten muessen installiert, konfiguriert, gewartet und aktualisiert werden.
• Jede Komponente hat eigene Release-Zyklen, Konfigurationssprache, Debugging-Werkzeuge und Breaking Changes. Das Gesamtsystem zu beherrschen erfordert Wissen aus Netzwerk, Storage, Security, Observability und CI/CD.
• Ein einzelner Admin kann diesen Stack aufbauen. Ihn dauerhaft auf Enterprise-Level betreiben -- mit Security-Patches, Upgrades, Incident Response und Dokumentation -- ist fuer eine Person nicht realistisch.
• Die Loesung ist nicht, auf Kubernetes zu verzichten, sondern den Betrieb in ein Modell zu bringen, das die Komplexitaet verteilt: Entweder durch ein internes Platform Team oder durch einen Managed Service Partner.

Der Unterschied zwischen "laeuft" und "produktionsreif"

Einen Kubernetes-Cluster aufzusetzen ist nicht schwer. kubeadm init, drei Worker Nodes joinen, fertig. Oder ein Managed Control Plane bei einem Cloud-Provider buchen und Nodes starten. Das dauert einen Nachmittag.

Das Problem beginnt danach. Ein Cluster, der nur aus Control Plane und Worker Nodes besteht, kann nichts Sinnvolles: Kein externer Traffic kommt rein. Es gibt kein Monitoring. Kein Backup. Kein Alerting. Keine TLS-Zertifikate. Kein vernuenftiges Logging.

Zwischen "Cluster laeuft" und "Cluster ist produktionsreif" liegen 18 Komponenten, Wochen an Konfigurationsarbeit und jahrelange Erfahrung im Betrieb. Dieser Artikel listet jede einzelne Komponente auf und zeigt, warum die Gesamtkomplexitaet eine Person ueberfordert.

Die 18 Komponenten im Ueberblick

Produktionsreifer Kubernetes-Stack:

Core Platform (4 Komponenten):
  1. Container Runtime (containerd)
  2. Container Network Interface / CNI (Cilium, Calico)
  3. DNS (CoreDNS)
  4. Container Storage Interface / CSI (Cloud-Provider oder Longhorn/Rook)

Networking und Traffic (3 Komponenten):
  5. Ingress Controller (nginx, Traefik, HAProxy)
  6. Certificate Manager (cert-manager)
  7. External DNS (external-dns)

Observability (3 Komponenten):
  8. Metrics und Alerting (Prometheus + Alertmanager)
  9. Dashboards (Grafana)
 10. Log-Aggregation (Loki, Fluentd/Fluent Bit)

Security (4 Komponenten):
 11. Image Scanning (Trivy)
 12. Runtime Security (Falco)
 13. Policy Engine (Kyverno, OPA/Gatekeeper)
 14. Secrets Management (External Secrets Operator, Vault)

Operations (4 Komponenten):
 15. Backup und Disaster Recovery (Velero)
 16. GitOps (ArgoCD, Flux)
 17. Autoscaling (Cluster Autoscaler, Karpenter)
 18. Cost Monitoring (kubecost, OpenCost)

Das sind 18 Komponenten. Jede einzelne hat Konfiguration, Updates, Debugging-Bedarf und eigene Dokumentation. Im Folgenden gehen wir durch jede Kategorie im Detail.

Kategorie 1: Core Platform

1. Container Runtime (containerd)

Die Container Runtime fuehrt die Container aus. Seit Docker als Runtime deprecated wurde, ist containerd der Standard. Die Runtime muss auf jedem Node installiert sein und wird bei Kubernetes-Upgrades manchmal mitaktualisiert.

Wartungsaufwand: Gering, aber bei CVEs muss schnell gepatcht werden. containerd hatte in den letzten Jahren mehrere Security-relevante Updates.

2. CNI -- Container Network Interface

Das CNI-Plugin ist die Netzwerk-Schicht des Clusters. Ohne CNI koennen Pods nicht miteinander kommunizieren. Die Wahl des CNI-Plugins ist eine der folgenreichsten Architektur-Entscheidungen.

Eine typische Cilium-Konfiguration zeigt die Komplexitaet:

# cilium-values.yaml (Auszug -- die vollstaendige Datei hat oft 200+ Zeilen)
apiVersion: cilium.io/v2alpha1
kind: CiliumClusterWideNetworkPolicy
metadata:
  name: default-deny-ingress
spec:
  description: "Default deny all ingress traffic"
  endpointSelector: {}
  ingress:
    - fromEntities:
        - kube-apiserver
    - fromEndpoints:
        - matchLabels:
            io.kubernetes.pod.namespace: kube-system
---
apiVersion: cilium.io/v2alpha1
kind: CiliumNetworkPolicy
metadata:
  name: allow-frontend-to-api
  namespace: production
spec:
  endpointSelector:
    matchLabels:
      app: api-server
  ingress:
    - fromEndpoints:
        - matchLabels:
            app: frontend
      toPorts:
        - ports:
            - port: "8080"
              protocol: TCP

Wer dieses YAML versteht und debuggen kann, braucht Erfahrung mit Netzwerk-Konzepten (L3/L4-Filtering, eBPF), Kubernetes-Labels und dem spezifischen CRD-Schema von Cilium. Mehr zu Network Policies finden Sie in unserem Network Security Guide.

3. DNS (CoreDNS)

CoreDNS ist die interne DNS-Loesung des Clusters. Services werden ueber DNS-Namen aufgeloest (my-service.my-namespace.svc.cluster.local). CoreDNS ist meist stabil, aber DNS-Probleme sind eine der haeufigsten Ursachen fuer schwer zu debuggende Fehler.

4. CSI -- Container Storage Interface

Persistent Storage in Kubernetes laeuft ueber CSI-Treiber. Jeder Cloud-Provider hat eigene Treiber. On-Premises kommt haeufig Longhorn, Rook-Ceph oder OpenEBS zum Einsatz.

Wartungsaufwand: Mittel. Storage-Probleme sind besonders kritisch, weil sie zu Datenverlust fuehren koennen. CSI-Treiber-Updates muessen sorgfaeltig getestet werden.

Kategorie 2: Networking und Traffic

5. Ingress Controller

Der Ingress Controller ist das Tor zum Cluster. Ohne ihn kommt kein externer HTTP/HTTPS-Traffic an die Anwendungen. Die Konfiguration umfasst TLS-Terminierung, Rate Limiting, Header-Manipulation und Routing-Regeln.

6. Certificate Manager (cert-manager)

TLS-Zertifikate muessen automatisiert ausgestellt und erneuert werden. cert-manager ist der De-facto-Standard. Er integriert mit Let's Encrypt, aber auch mit internen CAs.

Typisches Problem: Zertifikat laeuft ab, weil die DNS-Challenge fehlschlaegt, und niemand hat den Alert konfiguriert. Ergebnis: HTTPS-Ausfall in der Produktion.

7. External DNS

External DNS synchronisiert Kubernetes Ingress-Ressourcen automatisch mit dem externen DNS-Provider (Route53, Cloudflare, Azure DNS). Ohne External DNS muessen DNS-Eintraege manuell gepflegt werden -- eine fehleranfaellige Aufgabe.

Kategorie 3: Observability

8. Prometheus und Alertmanager

Prometheus sammelt Metriken, Alertmanager verarbeitet Alerts. Zusammen bilden sie das Rueckgrat des Kubernetes-Monitorings. Die Konfiguration ist maechtig, aber komplex.

# Beispiel: PrometheusRule fuer Pod-Restart-Alert
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: pod-restart-alert
  namespace: monitoring
  labels:
    release: kube-prometheus-stack
spec:
  groups:
    - name: pod-health
      rules:
        - alert: PodRestartingTooOften
          expr: |
            increase(
              kube_pod_container_status_restarts_total[1h]
            ) > 5
          for: 10m
          labels:
            severity: warning
          annotations:
            summary: >-
              Pod {{ $labels.namespace }}/{{ $labels.pod }}
              hat {{ $value }} Restarts in der letzten Stunde
            description: >-
              Moeglicherweise OOMKill, CrashLoopBackOff oder
              fehlerhafte Liveness-Probe. Pruefen Sie die Pod-Logs.
            runbook_url: "https://wiki.intern/runbooks/pod-restarts"

Allein der kube-prometheus-stack Helm Chart hat ueber 3.000 Zeilen an Default-Values. Sinnvoll anpassen und betreiben erfordert tiefes Verstaendnis von PromQL, Alerting-Routing und Grafana-Dashboarding.

Unser Guide zu Kubernetes Monitoring Kosten senken zeigt, wie der Observability-Stack wirtschaftlich betrieben werden kann.

9. Grafana

Grafana visualisiert die Prometheus-Metriken. Enterprise-faehiges Monitoring bedeutet nicht nur "ein Dashboard installieren", sondern: sinnvolle Dashboards fuer verschiedene Zielgruppen (Ops, Dev, Management), Alerting-Integration, und RBAC fuer Dashboard-Zugriff.

10. Log-Aggregation (Loki / EFK-Stack)

Logs muessen zentral gesammelt, durchsuchbar und retentiert werden. Der klassische EFK-Stack (Elasticsearch, Fluentd, Kibana) wird zunehmend von Loki mit Fluent Bit abgeloest.

Wartungsaufwand: Hoch. Log-Aggregation ist ressourcenhungrig und erzeugt eigene Betriebsprobleme (Storage wachsend, Index-Management, Retention-Policies).

Kategorie 4: Security

11. Image Scanning (Trivy)

Container Images muessen vor dem Deployment auf bekannte Schwachstellen gescannt werden. Trivy ist Open Source und gut in CI/CD-Pipelines integrierbar.

Wartungsaufwand: Niedrig fuer das Tool selbst, aber die Vulnerability-Reports muessen ausgewertet und Findings priorisiert werden. Das ist eine laufende Aufgabe.

12. Runtime Security (Falco)

Falco ueberwacht zur Laufzeit, was Container tun: unerwartete Prozesse, Dateizugriffe, Netzwerkverbindungen. Es erkennt Anomalien, die statisches Image-Scanning nicht finden kann.

Wartungsaufwand: Mittel bis hoch. Falco erzeugt viele False Positives, die manuell getuned werden muessen. Ohne Tuning wird der Alert-Kanal schnell unbrauchbar.

13. Policy Engine (Kyverno / OPA Gatekeeper)

Policy Engines setzen organisatorische Regeln technisch durch: Keine Container mit Root-Rechten, Resource Limits muessen gesetzt sein, Images nur aus zugelassenen Registries.

Detaillierte Informationen zur Absicherung finden Sie in der Security Hardening Checkliste.

14. Secrets Management

Kubernetes Secrets sind per Default nur Base64-kodiert, nicht verschluesselt. Ein produktionsreifer Cluster braucht entweder Encryption at Rest, einen External Secrets Operator oder eine Integration mit HashiCorp Vault.

Unser Vault-Integrationsguide zeigt die Einrichtung im Detail.

Kategorie 5: Operations

15. Backup und Disaster Recovery (Velero)

Ohne getestetes Backup ist jeder Cluster ein Risiko. Velero sichert Kubernetes-Ressourcen und Persistent Volumes. Die Konfiguration ist nicht trivial, besonders bei Cloud-uebergreifenden Restore-Szenarien.

16. GitOps (ArgoCD / Flux)

GitOps macht Cluster-Konfiguration reproduzierbar und auditierbar. ArgoCD oder Flux synchronisieren den gewuenschten Zustand aus Git-Repositories in den Cluster.

Wartungsaufwand: Mittel. ArgoCD selbst muss gewartet und aktualisiert werden. Application Sets, RBAC und Multi-Cluster-Konfiguration erhoehen die Komplexitaet.

17. Autoscaling (Cluster Autoscaler / Karpenter)

Autoscaling sorgt dafuer, dass Nodes automatisch hinzugefuegt oder entfernt werden. Ohne Autoscaling zahlen Sie fuer ungenutzte Kapazitaet oder haben nicht genug Kapazitaet bei Lastspitzen.

18. Cost Monitoring (kubecost / OpenCost)

Kosten pro Namespace, Team oder Anwendung sichtbar machen. Ohne Cost Monitoring gibt es keine Grundlage fuer Optimierung. Kubecost oder OpenCost aggregieren Cloud-Provider-Kosten und ordnen sie Kubernetes-Workloads zu.

Die Verantwortungsmatrix: Wer muss was koennen?

Jede Komponente erfordert spezifisches Wissen. Die folgende Tabelle zeigt, welches Expertisefeld betroffen ist:

Das ergibt konservativ geschaetzt 50-70 Upgrade-Vorgaenge pro Jahr, allein fuer die Plattform-Komponenten -- ohne die eigentlichen Anwendungen.

Warum eine Person das nicht stemmen kann

Es geht nicht um Kompetenz. Es gibt Einzelpersonen, die all diese Tools kennen und konfigurieren koennen. Das Problem ist die Kombination aus:

Breite: 18 Komponenten erfordern Wissen in mindestens 6 verschiedenen Fachgebieten (Netzwerk, Storage, Security, Observability, CI/CD, Cloud-Provider). Kein einzelner Mensch ist in allen gleich stark.

Tiefe: Wenn Cilium ein Breaking Change hat, muss jemand die Release Notes lesen, die Migration planen und testen. Wenn gleichzeitig Prometheus ein Major-Upgrade hat und Velero einen Bug-Fix braucht, entstehen Priorisierungskonflikte.

Verfuegbarkeit: 50-70 Updates pro Jahr, dazu Incidents, dazu Feature-Requests vom Entwicklerteam, dazu Dokumentation. Bei 220 Arbeitstagen bleiben pro Komponente knapp 3 Tage im Jahr fuer alles -- Updates, Troubleshooting, Weiterbildung.

Ausfallzeiten: Urlaub, Krankheit, Weiterbildung. In diesen Zeiten passieren trotzdem Incidents, trotzdem laufen Zertifikate ab, trotzdem gibt es CVEs.

Das ist keine theoretische Ueberlegung. In der Praxis sehen wir bei Unternehmen mit einem einzelnen Kubernetes-Admin immer dasselbe Muster: Die Core-Infrastruktur laeuft, aber Security Scanning ist "geplant", Backup-Restore wurde "noch nicht getestet", Network Policies sind "auf der Roadmap", und Cost Monitoring "kommt als naechstes".

Was die Alternativen sind

Option 1: Managed Kubernetes Service

Ein Managed Service Provider uebernimmt den Betrieb des gesamten Stacks. Ihr internes Team fokussiert sich auf Anwendungs-Entwicklung und -Deployment.

Geeignet fuer: Unternehmen mit 300-1000 Mitarbeitern, 1-3 Clustern, ohne eigenes Platform Team.

Option 2: Internes Platform Team (ab 3 Personen)

Ein dediziertes Team kann die Komplexitaet beherrschen, wenn Wissen verteilt ist und On-Call-Rotation funktioniert.

Geeignet fuer: Unternehmen, bei denen Kubernetes-Betrieb zur Kernkompetenz gehoert und die Groesse ein eigenes Team rechtfertigt.

Option 3: Hybrid-Modell

Ein interner Engineer oder Architect verantwortet Strategie und Anwendungsnaehe. Ein externer Partner uebernimmt den operativen Betrieb (Monitoring, Patching, Incident Response). Beide arbeiten eng zusammen.

Geeignet fuer: Mittelstaendler, die internes Know-how aufbauen wollen, aber die operative Last nicht alleine tragen koennen. Mehr zum Vergleich dieser Optionen lesen Sie im Managed Service vs. Inhouse Vergleich.

Wie Sie die Komplexitaet fuer sich einschaetzen

Beantworten Sie diese Fragen fuer Ihren aktuellen Cluster:

1. Koennen Sie innerhalb von 30 Minuten eine Liste aller installierten Cluster-Komponenten und deren Versionen erstellen?
2. Wann wurde zuletzt ein Restore aus dem Velero-Backup getestet?
3. Haben Sie Network Policies aktiv oder laeuft der Cluster mit Default-Allow?
4. Wie viele offene CVEs haben Ihre aktuell laufenden Container Images?
5. Wer wird benachrichtigt, wenn nachts um 3 Uhr ein Node ausfaellt?

Wenn Sie bei mehr als zwei Fragen unsicher sind, tragen Sie ein Risiko, das mit einem Audit schnell behoben werden kann.

Fazit: Komplexitaet anerkennen, nicht ignorieren

18 Komponenten sind kein Argument gegen Kubernetes. Sie sind ein Argument gegen den Versuch, einen produktionsreifen Cluster mit einer einzelnen Person zu betreiben. Die Technologie ist maechtig und fuer viele Unternehmen die richtige Wahl. Aber sie erfordert einen Betrieb, der der Komplexitaet angemessen ist.

Wenn Sie wissen moechten, wie Ihr aktueller Stack im Vergleich zu einem produktionsreifen Setup abschneidet, fuehren wir Cluster-Assessments durch. In einem halben Tag identifizieren wir Luecken, bewerten Risiken und geben eine klare Handlungsempfehlung. Sprechen Sie uns an.