1. Zielbild

Dieses Dokument erklärt die zentralen Kubernetes-Konzepte so, dass du Kubernetes nicht nur bedienen, sondern fachlich einordnen kannst. Es ergänzt die Architektur-, Best-Practices- und Kommandoreferenz: Hier geht es um Begriffe, Zusammenhänge, Verantwortungsgrenzen und typische Denkfehler.

Nach diesem Kapitel sollst du Folgendes können:

• du kannst erklären, was Kubernetes als Plattform leistet und was bewusst außerhalb von Kubernetes liegt;
• du verstehst den Unterschied zwischen gewünschtem Zustand, aktuellem Zustand und beobachtetem Status;
• du kannst ein Manifest lesen und die Bedeutung von apiVersion, kind, metadata, spec und status erklären;
• du kannst Pods, Deployments, StatefulSets, DaemonSets, Jobs und CronJobs fachlich voneinander abgrenzen;
• du kannst Services, DNS, Ingress, Gateway API und NetworkPolicies als Netzwerkbausteine einordnen;
• du verstehst Storage über Volumes, PVCs, PVs, StorageClasses und CSI;
• du erkennst, warum Requests, Limits, Scheduling-Regeln, Quotas und Autoscaling für stabilen Betrieb notwendig sind;
• du kannst RBAC, ServiceAccounts, Pod Security Standards und Admission Control als Security-Schichten erklären;
• du kannst typische Fehlerbilder einem Konzeptbereich zuordnen.

Der rote Faden lautet: Kubernetes ist kein einzelnes Tool, sondern ein API-zentriertes Steuerungssystem für verteilte Workloads.

flowchart LR
  user[Du beschreibst Zielzustand] --> api[Kubernetes API]
  api --> store[(etcd speichert Zustand)]
  api --> controllers[Controller beobachten Objekte]
  controllers --> nodes[Nodes führen Pods aus]
  nodes --> status[Status, Events, Logs, Metriken]
  status --> api
  api --> user

2. Was Kubernetes ist

Kubernetes ist eine portable, erweiterbare Plattform für containerisierte Workloads und Services. Der wichtigste Unterschied zu einem reinen Container-Starter ist: Kubernetes verwaltet nicht nur Prozesse, sondern API-Objekte, Beziehungen, Policies und Kontrollschleifen.

Kubernetes bietet dir vor allem diese Fähigkeiten:

Wichtig: Kubernetes verwaltet Container über Pods. Du arbeitest in Kubernetes in der Regel nicht direkt mit einzelnen Containern, sondern mit Ressourcen, die Pods erzeugen, überwachen und ersetzen.

3. Was Kubernetes nicht ist

Kubernetes ist mächtig, aber keine vollständige Anwendungsplattform ohne zusätzliche Entscheidungen. Viele Missverständnisse entstehen, weil Kubernetes mit angrenzenden Werkzeugen verwechselt wird.

Merksatz: Kubernetes stellt die Steuerungsebene bereit. Produktionsreife entsteht erst durch Architekturentscheidungen, Betriebsprozesse, Sicherheitsgrenzen und Beobachtbarkeit.

4. Das mentale Modell

Wenn du Kubernetes verstehst, solltest du nicht zuerst an YAML denken. YAML ist nur eine Darstellung. Das eigentliche Modell besteht aus API-Objekten, Controllern, Status und Ereignissen.

flowchart TD
  manifest[Manifest in YAML oder JSON] --> request[API-Request]
  request --> admission[Admission: validieren und mutieren]
  admission --> storage[(etcd)]
  storage --> watch[Watch-Streams]
  watch --> controller[Controller]
  controller --> action[Aktion: Pod erstellen, Service aktualisieren, Volume binden]
  action --> runtime[Laufzeit auf Nodes]
  runtime --> observed[Beobachteter Zustand]
  observed --> status[Status im API-Objekt]

Die wichtigsten Ebenen sind:

1. Absicht: Du formulierst den gewünschten Zustand in spec.
2. Persistenz: Der API Server speichert das Objekt in etcd.
3. Beobachtung: Controller beobachten Objektänderungen über Watches.
4. Abgleich: Controller vergleichen Soll und Ist.
5. Aktion: Controller erzeugen, ändern oder löschen abhängige Objekte.
6. Rückmeldung: Komponenten schreiben Status, Conditions und Events.

Daraus folgen drei Grundregeln:

• Du debugst Kubernetes immer über Objekte, Beziehungen und Status.
• Ein erfolgreiches apply bedeutet nur, dass der API Server das Objekt akzeptiert hat; es bedeutet nicht automatisch, dass der Workload läuft.
• Wenn Kubernetes „nichts tut“, fehlt meist ein Controller, eine Berechtigung, eine passende Infrastruktur oder ein erfüllbarer Zielzustand.

5. Clusterarchitektur

Ein Kubernetes-Cluster besteht aus einer Control Plane und einem oder mehreren Worker Nodes. Die Control Plane trifft globale Entscheidungen und verwaltet den Clusterzustand. Worker Nodes führen Workloads aus.

flowchart TB
  subgraph cp[Control Plane]
    apiserver[kube-apiserver]
    etcd[(etcd)]
    scheduler[kube-scheduler]
    cm[kube-controller-manager]
    ccm[cloud-controller-manager]
  end

  subgraph node1[Worker Node]
    kubelet1[kubelet]
    runtime1[Container Runtime]
    proxy1[kube-proxy oder eBPF]
    cni1[CNI]
    pods1[Pods]
  end

  subgraph node2[Worker Node]
    kubelet2[kubelet]
    runtime2[Container Runtime]
    proxy2[kube-proxy oder eBPF]
    cni2[CNI]
    pods2[Pods]
  end

  apiserver <--> etcd
  apiserver --> scheduler
  apiserver --> cm
  apiserver --> ccm
  kubelet1 <--> apiserver
  kubelet2 <--> apiserver
  kubelet1 --> runtime1 --> pods1
  kubelet2 --> runtime2 --> pods2

5.1 Control Plane

Die Control Plane ist die Steuerungsebene des Clusters. Diese Steuerungsebene sollte in produktiven Umgebungen hochverfügbar betrieben, überwacht und kontrolliert aktualisiert werden.

Der API Server ist die Frontdoor. Er authentifiziert Clients, autorisiert Aktionen, führt Admission-Schritte aus, validiert Objekte und persistiert akzeptierte Änderungen.

etcd ist kein beliebiger Cache. Es ist der autoritative Datenspeicher der Kubernetes API. Ein etcd-Backup ohne Restore-Test ist im Betrieb nur eine Vermutung.

Der Scheduler startet keine Container. Er schreibt eine Node-Zuweisung in das Pod-Objekt. Danach übernimmt das kubelet auf dem ausgewählten Node.

Controller führen die eigentliche Reconciliation aus. Ein Deployment-Controller sorgt zum Beispiel dafür, dass ReplicaSets und Pods zur gewünschten Deployment-Spezifikation passen.

5.2 Worker Nodes

Worker Nodes führen deine Workloads aus. Auf jedem Node laufen Komponenten, die Pods starten, überwachen, vernetzen und an die Control Plane zurückmelden.

Das kubelet ist kein allgemeiner Prozessmanager für den ganzen Server. Es verwaltet nur Pods, die ihm von der Kubernetes API zugewiesen wurden oder als Static Pods lokal definiert sind.

5.3 Add-ons und Plattformdienste

Viele Funktionen, die im Alltag selbstverständlich wirken, kommen aus Add-ons:

Kubernetes definiert Schnittstellen. Add-ons liefern konkrete Implementierungen. Deshalb kann ein Manifest auf zwei Clustern unterschiedlich wirken, wenn CNI, Ingress Controller, CSI-Treiber oder Admission-Policies unterschiedlich sind.

5.4 Hochverfügbarkeit

In Lernumgebungen besteht ein Cluster oft aus einem Node oder einer kleinen lokalen Simulation. In Produktion musst du andere Fragen stellen:

• Gibt es mehrere API-Server-Instanzen?
• Läuft etcd redundant und wird regelmäßig gesichert?
• Gibt es mehrere Worker Nodes über Ausfallzonen hinweg?
• Sind kritische Add-ons mehrfach repliziert?
• Sind PodDisruptionBudgets definiert, damit Wartung nicht zu viele Pods gleichzeitig entfernt?
• Sind Ingress-, DNS-, Zertifikats- und Storage-Komponenten selbst hochverfügbar?
• Ist klar, welche Komponente bei einem Zonen-, Node- oder Netzwerkfehler verantwortlich ist?

Hochverfügbarkeit ist nicht nur eine Einstellung. Belastbare Verfügbarkeit entsteht aus Redundanz, Scheduling-Regeln, Datenhaltung, Netzwerkdesign, Upgrades, Tests und Betriebsdisziplin.

6. API- und Objektmodell

Kubernetes ist API-zentriert. Alles, was du im Cluster verwaltest, ist entweder ein API-Objekt oder hängt direkt an API-Objekten.

6.1 Ressourcen, Kinds und API-Gruppen

Die Kubernetes API ist ressourcenbasiert. Du arbeitest mit Ressourcentypen wie pods, deployments, services oder secrets. Jedes Objekt hat einen kind, zum Beispiel Pod, Deployment, Service oder Secret.

Beispiel:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: shop-api
  namespace: workshop
spec:
  replicas: 3
  selector:
    matchLabels:
      app.kubernetes.io/name: shop-api
  template:
    metadata:
      labels:
        app.kubernetes.io/name: shop-api
    spec:
      containers:
        - name: app
          image: registry.example.com/platform/shop-api:1.4.2

Hier bedeutet apps/v1, dass das Objekt zur API-Gruppe apps in Version v1 gehört. Der kind ist Deployment. In der API würdest du dieses Objekt als Ressource deployments im Namespace workshop finden.

6.2 apiVersion, kind, metadata, spec, status

Fast jedes Kubernetes-Objekt folgt einer ähnlichen Grundstruktur.

Der wichtigste Unterschied ist spec gegen status:

• spec beschreibt, was du willst.
• status beschreibt, was Kubernetes beobachtet.

Beispiel:

spec:
  replicas: 3
status:
  replicas: 3
  availableReplicas: 2
  unavailableReplicas: 1

Dieses Objekt sagt: Du möchtest drei Replikate. Kubernetes sieht aber nur zwei verfügbare Replikate. Der Unterschied ist kein YAML-Fehler, sondern ein Betriebszustand, den du untersuchen musst.

6.3 Namespaces und clusterweite Ressourcen

Namespaces gruppieren namespaced Ressourcen. Ein Namespace ist ein Organisations- und Isolationsmechanismus, aber keine vollständige Sicherheitsgrenze.

Typische namespaced Ressourcen:

• Pod
• Deployment
• StatefulSet
• DaemonSet
• Job
• CronJob
• Service
• ConfigMap
• Secret
• Role
• RoleBinding
• ResourceQuota
• LimitRange
• NetworkPolicy

Typische clusterweite Ressourcen:

• Node
• Namespace
• PersistentVolume
• StorageClass
• ClusterRole
• ClusterRoleBinding
• CustomResourceDefinition
• PriorityClass
• MutatingWebhookConfiguration
• ValidatingWebhookConfiguration

Regel: Ressourcenname plus Kind müssen innerhalb eines Namespace eindeutig sein. Clusterweite Ressourcen haben keinen Namespace.

Namespaces lösen nicht automatisch diese Themen:

• Netzwerkisolation: Dafür brauchst du NetworkPolicies und ein CNI mit Policy-Unterstützung.
• Ressourcenbegrenzung: Dafür brauchst du ResourceQuotas und LimitRanges.
• Rechtebegrenzung: Dafür brauchst du RBAC.
• Sicherheitsprofile: Dafür brauchst du Pod Security Admission oder andere Admission-Policies.
• Kostenstellen: Dafür brauchst du Labels, Quotas, Reporting und Governance.

6.4 Namen, UIDs und Generierung

Jedes Objekt hat einen Namen und eine UID.

Wichtig: Ein neues Objekt mit gleichem Namen nach dem Löschen hat eine neue UID. Für Controller und Garbage Collection zählt deshalb nicht nur der Name, sondern die Identität des Objekts.

6.5 Labels, Selectors und empfohlene Labels

Labels sind Schlüssel-Wert-Paare, mit denen du Objekte organisierst und auswählst. Labels sind maschinenlesbare Identitäts- und Gruppierungsmerkmale.

Beispiel:

metadata:
  labels:
    app.kubernetes.io/name: shop-api
    app.kubernetes.io/instance: shop-api-prod
    app.kubernetes.io/version: "1.4.2"
    app.kubernetes.io/component: backend
    app.kubernetes.io/part-of: shop
    environment: prod
    team: platform

Selectors wählen Objekte anhand von Labels aus:

selector:
  matchLabels:
    app.kubernetes.io/name: shop-api

Labels sind entscheidend für:

• Services, die passende Pods finden;
• Deployments und ReplicaSets, die ihre Pods verwalten;
• NetworkPolicies, die Traffic-Regeln auf Pod-Gruppen anwenden;
• Observability, Kostenrechnung und Inventarisierung;
• Wartungs- und Plattformprozesse.

Gute Label-Strategie:

Denkfehler: Labels sind nicht nur Dekoration. Falsche Labels können dazu führen, dass Services keine Endpoints haben, ReplicaSets fremde Pods übernehmen oder NetworkPolicies nicht greifen.

6.6 Annotations

Annotations sind ebenfalls Schlüssel-Wert-Paare, aber sie dienen nicht zur Auswahl von Objekten. Du nutzt sie für zusätzliche Metadaten, Tool-Konfigurationen oder Integrationshinweise.

Beispiele:

metadata:
  annotations:
    description: "Backend API für den Shop"
    owner: "team-platform"
    checksum/config: "sha256:..."

Typische Einsätze:

• Prüfsummen von ConfigMaps oder Secrets, um Rollouts auszulösen;
• Tool-spezifische Hinweise für Ingress Controller, Service Meshes oder Backup-Systeme;
• Dokumentations- und Eigentümerinformationen;
• Policy-Ausnahmen, sofern dein Governance-Modell das erlaubt.

Regel: Was selektiert, filtert oder gruppiert werden soll, gehört in Labels. Was nur zusätzliche Information ist, gehört in Annotations.

6.7 Owner References, Garbage Collection und Finalizers

Owner References beschreiben Besitzbeziehungen zwischen Objekten. Ein Deployment besitzt ReplicaSets, ein ReplicaSet besitzt Pods. Diese Beziehungen ermöglichen Garbage Collection.

flowchart TD
  deployment[Deployment] --> rs1[ReplicaSet Version A]
  deployment --> rs2[ReplicaSet Version B]
  rs1 --> pod1[Pod]
  rs1 --> pod2[Pod]
  rs2 --> pod3[Pod]

Wenn ein Owner gelöscht wird, kann Kubernetes abhängige Objekte mitlöschen. Das hängt von der Löschstrategie ab:

Finalizers verhindern, dass ein Objekt sofort vollständig gelöscht wird. Dieser Mechanismus gibt Controllern Zeit, externe Ressourcen aufzuräumen.

Typische Beispiele:

• Storage-Controller entfernt ein externes Volume;
• Cloud Controller entfernt einen externen Load Balancer;
• Operator löscht abhängige Datenbankressourcen;
• Backup- oder Policy-Controller erzwingt Abschlussarbeit vor Löschung.

Wenn ein Objekt lange in Terminating bleibt, ist häufig ein Finalizer betroffen. Entferne Finalizers nicht blind. Prüfe zuerst, welcher Controller nicht fertig wird und welche externe Ressource betroffen ist.

6.8 Conditions, Events und Status

Status ist nicht nur ein Textfeld. Viele Ressourcen verwenden Conditions, um den Zustand strukturiert auszudrücken.

Beispielhafte Condition:

status:
  conditions:
    - type: Available
      status: "False"
      reason: MinimumReplicasUnavailable
      message: Deployment does not have minimum availability.

Events sind zeitliche Hinweise zu Entscheidungen und Fehlern. Besonders wichtig sind Events bei Scheduling, Image Pull, Volume Mounts und Probe-Fehlern.

Regel für Troubleshooting: Lies nicht nur kubectl get. Prüfe describe, Conditions, Events und Logs.

7. Deklaratives Modell und Reconciliation

7.1 Desired State und Actual State

Kubernetes arbeitet mit gewünschtem Zustand und beobachtetem Zustand.

Beispiel:

spec:
  replicas: 3

Wenn ein Node ausfällt und ein Pod verschwindet, erkennt ein Controller die Abweichung und erzeugt Ersatz. Kubernetes „repariert“ aber nicht die Anwendung selbst. Wenn dein Prozess wegen falscher Konfiguration crasht, startet Kubernetes ihn zwar neu, aber die Ursache bleibt bestehen.

7.2 Controller Loop

Ein Controller ist eine Kontrollschleife:

1. Beobachte API-Objekte.
2. Ermittle den gewünschten Zustand.
3. Ermittle den aktuellen Zustand.
4. Entscheide, welche Änderung nötig ist.
5. Führe die Änderung aus.
6. Schreibe Status zurück.
7. Wiederhole den Vorgang.

flowchart LR
  watch[Objekte beobachten] --> compare[Soll und Ist vergleichen]
  compare --> decide[Aktion entscheiden]
  decide --> act[abhängige Objekte oder Infrastruktur ändern]
  act --> status[Status aktualisieren]
  status --> watch

Controller sollten idempotent sein. Das bedeutet: Wenn sie dieselbe Situation mehrfach sehen, erzeugen sie nicht mehrfach denselben Effekt, sondern nähern den Zustand stabil an.

7.3 Imperativ, deklarativ und GitOps

Du kannst Kubernetes imperativ oder deklarativ bedienen.

Im Workshop ist imperatives Arbeiten nützlich, weil du schnelle Feedback-Schleifen bekommst. Für reproduzierbare Umgebungen solltest du jedoch deklarativ arbeiten.

GitOps bedeutet nicht nur „YAML in Git“. GitOps bedeutet:

• Git enthält den gewünschten Zustand;
• ein Controller synchronisiert diesen Zustand in den Cluster;
• Änderungen laufen über Review, Commit und Audit Trail;
• Drift wird erkannt oder korrigiert;
• Rollbacks erfolgen über Git-Historie und kontrollierte Synchronisierung.

7.4 Server-side Apply und Feldbesitz

Bei deklarativer Arbeit ist wichtig, wer welches Feld verwaltet. Server-side Apply speichert sogenannten Field Ownership. Dadurch kann Kubernetes erkennen, welches Tool oder welcher Manager ein Feld gesetzt hat.

Das ist relevant, wenn mehrere Akteure dasselbe Objekt ändern:

• GitOps-Controller verwaltet das Deployment;
• HPA verwaltet die Replica-Anzahl über die scale-Subresource;
• ein Admission Webhook ergänzt Defaults;
• ein Operator setzt Status oder abhängige Felder.

Konflikte entstehen, wenn zwei Manager dasselbe Feld autoritativ verwalten wollen. Das Konzept schützt vor unbemerktem Überschreiben.

8. Pods

8.1 Pod als logischer Host

Ein Pod ist die kleinste deploybare Einheit in Kubernetes. Er ist kein einzelner Container, sondern eine Laufzeitumgebung für einen oder mehrere Container.

Container in einem Pod teilen sich:

• Netzwerk-Namespace;
• IP-Adresse;
• Port-Raum;
• optional gemeinsame Volumes;
• Lebenszyklus auf demselben Node.

Ein Pod modelliert einen logischen Host. Innerhalb eines Pods kommunizieren Container über localhost. Von außen wird der Pod über seine Pod-IP erreicht, solange er existiert.

Wichtig: Pods sind grundsätzlich kurzlebig. Du solltest nicht erwarten, dass ein konkreter Pod dauerhaft existiert. Workload-Controller erzeugen Ersatz, wenn Pods verschwinden.

8.2 Container im Pod

Der häufigste Fall ist ein Pod mit genau einem Anwendungscontainer:

apiVersion: v1
kind: Pod
metadata:
  name: web
  namespace: workshop
spec:
  containers:
    - name: nginx
      image: nginx:1.27
      ports:
        - containerPort: 80

Mehrere Container in einem Pod sind sinnvoll, wenn sie eng gekoppelt sind und gemeinsam geplant werden müssen. Beispiele:

• Sidecar sammelt Logs oder exportiert Metriken;
• Proxy vermittelt Traffic für die Hauptanwendung;
• Hilfscontainer aktualisiert Dateien in einem gemeinsamen Volume;
• Adapter übersetzt Protokolle.

Denkfehler: Mehrere Container in einem Pod sind kein Ersatz für Skalierung. Wenn du mehr Kapazität brauchst, erhöhst du üblicherweise die Anzahl der Pods, nicht die Anzahl gleicher Container in einem Pod.

8.3 Init Containers, Sidecars und Ephemeral Containers

Init Container eignen sich für Aufgaben wie:

• Warten auf abhängige Dienste;
• einmalige Initialisierung von Dateien;
• Migrations- oder Setup-Prüfungen;
• Trennung von Werkzeugen, die nicht im App-Image liegen sollen.

Ephemeral Containers sind für Debugging wertvoll, wenn dein App-Image bewusst minimal ist und keine Shell oder Diagnosewerkzeuge enthält.

8.4 Pod-Lebenszyklus

Pods durchlaufen Phasen. Die Phase ist eine grobe Zusammenfassung, kein vollständiger Fehlerbericht.

Zusätzlich gibt es Container-Zustände:

Typische Waiting-Reasons:

• ContainerCreating
• ErrImagePull
• ImagePullBackOff
• CrashLoopBackOff
• CreateContainerConfigError
• CreateContainerError

8.5 Restart Policies

Die restartPolicy beschreibt, wann Container in einem Pod neu gestartet werden.

Bei Deployments ist Always üblich. Jobs verwenden meist OnFailure oder Never, weil sie terminierende Aufgaben abbilden.

8.6 Probes

Probes sind Diagnosen, die das kubelet periodisch ausführt.

Beispiel:

readinessProbe:
  httpGet:
    path: /ready
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 10
livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 30
  periodSeconds: 10

Gute Probe-Regeln:

• Readiness prüft Abhängigkeiten, die für Traffic relevant sind.
• Liveness prüft nur, ob ein Neustart den Zustand wahrscheinlich verbessert.
• Startup Probe schützt langsam startende Anwendungen vor verfrühten Liveness-Neustarts.
• Probes dürfen nicht zu teuer sein.
• Eine kaputte Datenbankverbindung ist nicht automatisch ein Liveness-Fehler; sonst startest du die Anwendung in einer externen Störung ständig neu.

8.7 Graceful Shutdown

Wenn ein Pod beendet wird, setzt Kubernetes eine Termination Grace Period. Das kubelet sendet ein Terminierungssignal an den Containerprozess. Die Anwendung sollte dieses Signal behandeln und sauber herunterfahren.

Wichtige Punkte:

• Die Anwendung sollte keine neuen Requests mehr annehmen.
• Offene Requests sollten abgeschlossen oder kontrolliert abgebrochen werden.
• Readiness sollte früh auf False wechseln.
• Hintergrundjobs sollten Checkpoints oder sichere Abbruchpunkte haben.
• Die Grace Period muss zur Anwendung passen.
• preStop Hooks können helfen, ersetzen aber kein sauberes Signalhandling.

Denkfehler: Kubernetes kann einen Prozess beenden, aber nicht automatisch transaktionale Anwendungskonsistenz herstellen.

8.8 Häufige Pod-Fehlerbilder

9. Workloads und Controller

Pods werden selten direkt erstellt. Du verwendest Workload-Ressourcen, damit Kubernetes Pods replizieren, ersetzen, aktualisieren und überwachen kann.

flowchart TD
  deployment[Deployment] --> replicaset[ReplicaSet]
  replicaset --> pods[Pods]
  statefulset[StatefulSet] --> spods[Pods mit stabiler Identität]
  daemonset[DaemonSet] --> dpods[Pod pro geeignetem Node]
  cronjob[CronJob] --> job[Job]
  job --> jpods[Pods bis Abschluss]

9.1 ReplicaSet

Ein ReplicaSet hält eine stabile Anzahl identischer Pods bereit. Es nutzt Selector und Pod Template.

Du erstellst ReplicaSets in der Praxis selten direkt. Meist erzeugt ein Deployment ReplicaSets für dich.

Wichtig:

• Ein ReplicaSet steuert Replikation.
• Es kennt keine komplexe Rollout-Historie wie ein Deployment.
• Es kann Pods anhand von Labels auswählen.
• Falsch gewählte Selectors können fremde Pods erfassen.

9.2 Deployment

Ein Deployment ist die Standardressource für zustandslose Anwendungen. Es verwaltet ReplicaSets und ermöglicht deklarative Rollouts.

Ein Deployment eignet sich, wenn:

• Pods austauschbar sind;
• Zustand außerhalb des Pods liegt;
• horizontale Skalierung möglich ist;
• Rolling Updates und Rollbacks benötigt werden;
• der Service Traffic auf beliebige gesunde Replikate verteilen kann.

Beispiel:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: shop-api
  namespace: workshop
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 1
  selector:
    matchLabels:
      app.kubernetes.io/name: shop-api
  template:
    metadata:
      labels:
        app.kubernetes.io/name: shop-api
    spec:
      containers:
        - name: app
          image: registry.example.com/platform/shop-api:1.4.2
          ports:
            - name: http
              containerPort: 8080
          readinessProbe:
            httpGet:
              path: /ready
              port: http
          resources:
            requests:
              cpu: 100m
              memory: 128Mi
            limits:
              memory: 256Mi

Wichtige Felder:

Denkfehler: Ein Deployment ist nicht für jeden zustandsbehafteten Workload geeignet. Wenn Pod-Identität oder Volume-Zuordnung stabil sein muss, prüfe ein StatefulSet.

9.3 StatefulSet

Ein StatefulSet verwaltet Pods mit stabiler Identität. Die Pods sind nicht vollständig austauschbar.

StatefulSets eignen sich für Anwendungen mit:

• stabilen Namen;
• stabiler Netzwerkidentität;
• stabiler Volume-Zuordnung;
• geordneter Erstellung und Skalierung;
• zustandsbehafteten Rollen.

Beispielhafte Pod-Namen:

postgres-0
postgres-1
postgres-2

Bei einem StatefulSet bleibt postgres-0 als Identität erhalten, auch wenn der Pod neu geplant wird. Ein Deployment würde dagegen austauschbare Pod-Namen erzeugen.

Wichtige Konzepte:

Denkfehler: StatefulSet bedeutet nicht automatisch Datenbanksicherheit. Backup, Restore, Replikation, Quorum, Datenmigration und Storage-Klassen bleiben Anwendungs- und Plattformthemen.

9.4 DaemonSet

Ein DaemonSet stellt sicher, dass auf allen oder ausgewählten Nodes ein Pod läuft.

Typische Einsätze:

• Log-Agent auf jedem Node;
• Monitoring-Agent;
• CNI-Komponente;
• Storage-Node-Plugin;
• Security-Agent;
• Node-lokaler Proxy.

DaemonSets reagieren auf Node-Zugänge und Node-Entfernungen. Wenn ein neuer geeigneter Node hinzukommt, erzeugt der DaemonSet-Controller dort einen Pod.

Wichtig:

• DaemonSet-Pods sind oft infrastrukturell kritisch.
• DaemonSet-Pods brauchen häufig besondere Rechte oder Host-Zugriffe.
• DaemonSet-Pods sollten gesondert reviewed und gehärtet werden.
• Beim Node-Drain musst du beachten, dass DaemonSet-Pods üblicherweise nicht wie normale Workload-Pods evakuiert werden.

9.5 Job

Ein Job führt eine Aufgabe bis zum Abschluss aus. Ein Job erzeugt Pods und verfolgt erfolgreiche Abschlüsse.

Typische Einsätze:

• Datenmigration;
• Batch-Verarbeitung;
• einmaliger Import;
• Report-Erzeugung;
• Cleanup-Aufgabe;
• Testlauf im Cluster.

Wichtige Felder:

Denkfehler: Ein Job ist nicht automatisch idempotent. Deine Aufgabe muss selbst damit umgehen können, dass Pods neu gestartet oder Jobs erneut ausgeführt werden.

9.6 CronJob

Ein CronJob erzeugt Jobs nach einem Zeitplan. Die Syntax orientiert sich an Cron.

Typische Einsätze:

• regelmäßige Backups;
• periodische Reports;
• geplante Synchronisation;
• Cleanup alter Daten;
• Health- oder Konsistenzprüfungen.

Wichtige Felder:

Denkfehler: CronJob-Zeitplanung ersetzt keine Geschäftslogik. Aufgaben müssen mit doppelten Starts, fehlgeschlagenen Teilschritten und externen Abhängigkeiten umgehen können.

9.7 HorizontalPodAutoscaler

Der HorizontalPodAutoscaler skaliert die Anzahl der Pods eines Workloads anhand von Metriken.

Typische Quellen:

• CPU-Auslastung;
• Memory-Auslastung;
• Custom Metrics;
• External Metrics.

Voraussetzungen:

• Requests müssen sinnvoll gesetzt sein;
• Metrics API oder passende Metrikquelle muss verfügbar sein;
• die Anwendung muss horizontal skalierbar sein;
• Startzeit, Warm-up und Lastverteilung müssen berücksichtigt werden.

Denkfehler: HPA löst kein Kapazitätsproblem, wenn der Cluster keine freien Ressourcen hat. Dann brauchst du Cluster Autoscaling, größere Nodes oder weniger Last.

9.8 PodDisruptionBudget

Ein PodDisruptionBudget begrenzt freiwillige Unterbrechungen. Es schützt zum Beispiel bei Node-Drain, Upgrades oder geplanter Wartung.

Beispiel:

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: shop-api
  namespace: workshop
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app.kubernetes.io/name: shop-api

Wichtig:

• PDB schützt nicht vor Node-Crashs oder Hardwarefehlern.
• Zu strenge PDBs können Wartung blockieren.
• PDBs brauchen genug Replikate, damit sie sinnvoll wirken.
• PDBs müssen zu Rollout-Strategie und Verfügbarkeitszielen passen.

10. Netzwerk, Services und Zugriff

Kubernetes-Netzwerk besteht aus mehreren Ebenen. Du musst unterscheiden, ob du über Pod-zu-Pod-Kommunikation, Service Discovery, externen Zugriff oder Policy-Isolation sprichst.

flowchart LR
  client[Client außerhalb] --> lb[Load Balancer]
  lb --> ingress[Ingress Controller oder Gateway]
  ingress --> service[Service]
  service --> eps[EndpointSlices]
  eps --> pod1[Pod A]
  eps --> pod2[Pod B]
  pod1 <--> pod2

10.1 Pod-Netzwerk

Grundannahmen des Kubernetes-Netzwerks:

• Jeder Pod erhält eine eigene IP-Adresse.
• Pods können grundsätzlich Pod-zu-Pod kommunizieren, sofern Netzwerk und Policies es erlauben.
• Container im selben Pod teilen sich eine IP und erreichen sich über localhost.
• Services stellen stabile virtuelle Erreichbarkeit bereit.

Die Pod-IP ist nicht stabil. Wenn ein Pod ersetzt wird, bekommt der neue Pod typischerweise eine andere IP. Deshalb sollten Anwendungen nicht dauerhaft auf Pod-IPs vertrauen.

10.2 CNI

CNI steht für Container Network Interface. Kubernetes verwendet CNI-Plugins, um Pod-Netzwerk einzurichten.

Typische Aufgaben eines CNI-Plugins:

• Pod-IP vergeben;
• Netzwerkinterface im Pod-Namespace erstellen;
• Routing oder Overlay bereitstellen;
• NetworkPolicies umsetzen;
• optional eBPF-Dataplane bereitstellen;
• optional Verschlüsselung, Observability oder Service Mesh Integration unterstützen.

Wichtig: NetworkPolicy-Objekte wirken nur, wenn dein Netzwerk-Plugin sie durchsetzt. Ein Cluster kann NetworkPolicies akzeptieren, ohne sie tatsächlich zu erzwingen, wenn das CNI das nicht unterstützt.

10.3 Service

Ein Service entkoppelt Clients von kurzlebigen Pods. Er wählt passende Pods typischerweise über Labels aus und stellt eine stabile Adresse bereit.

Beispiel:

apiVersion: v1
kind: Service
metadata:
  name: shop-api
  namespace: workshop
spec:
  type: ClusterIP
  selector:
    app.kubernetes.io/name: shop-api
  ports:
    - name: http
      port: 80
      targetPort: http

Begriffe:

Denkfehler: Ein Service startet keine Pods. Wenn ein Service keine Endpoints hat, liegt das meist an Labels, Selectors, Readiness oder fehlenden Pods.

10.4 EndpointSlices

EndpointSlices beschreiben die tatsächlichen Backends eines Services. EndpointSlices ersetzen beziehungsweise ergänzen klassische Endpoints für Skalierung und moderne Funktionalität.

EndpointSlices enthalten Informationen wie:

• Zieladressen;
• Ports;
• Protokolle;
• Ready-Zustand;
• Node- und Zonenhinweise.

Wenn du Service-Probleme debugst, ist die Kette wichtig:

Service selector -> Pod labels -> Pod readiness -> EndpointSlice -> Traffic

10.5 Service-Typen

LoadBalancer funktioniert nicht magisch. Es braucht eine Implementierung: Cloud Controller, MetalLB, Cilium, kube-vip oder eine andere Plattformkomponente.

10.6 DNS

CoreDNS stellt in vielen Clustern DNS-Service-Discovery bereit. Typische Service-Namen:

shop-api
shop-api.workshop
shop-api.workshop.svc
shop-api.workshop.svc.cluster.local

Pods erhalten normalerweise DNS-Konfiguration, um Services im Cluster aufzulösen.

Typische DNS-Probleme:

• CoreDNS-Pods laufen nicht;
• Netzwerk zwischen Pods und CoreDNS ist blockiert;
• NetworkPolicy blockiert DNS-Traffic;
• Node-DNS oder Upstream-DNS ist defekt;
• falscher Namespace wird angenommen;
• Service hat keine Endpoints;
• Anwendung cached DNS zu aggressiv.

10.7 Ingress

Ingress beschreibt HTTP/HTTPS-Routing in den Cluster. Ein Ingress-Objekt allein reicht nicht; du brauchst einen Ingress Controller.

Ingress eignet sich für:

• Host-basiertes Routing;
• Pfad-basiertes Routing;
• TLS-Terminierung;
• zentrale HTTP-Eingangspunkte;
• einfache Web-Workloads.

Beispielkonzept:

Client -> Load Balancer -> Ingress Controller -> Ingress-Regel -> Service -> Pods

Denkfehler: Ingress ist kein Service-Typ. Ingress ist eine eigene Ressource, die von einem Controller interpretiert wird.

10.8 Gateway API

Gateway API ist eine modernere, rollenorientierte API-Familie für Netzwerkzugriff und Routing. Die API-Familie wird über CRDs und Controller implementiert.

Wichtige Ressourcen:

Gateway API trennt Verantwortungen besser:

• Infrastrukturteam verwaltet GatewayClasses und Gateways;
• Plattformteam setzt globale Policies;
• Anwendungsteam verwaltet Routes für eigene Services.

Das ist besonders nützlich in größeren Organisationen, weil nicht jede Anwendung direkt Infrastrukturdetails kontrollieren soll.

10.9 NetworkPolicies

NetworkPolicies beschreiben erlaubten Traffic auf Layer 3 und Layer 4. Diese Policies sind anwendungszentriert und wählen Pods über Labels aus.

Standardverhalten ohne NetworkPolicy ist typischerweise offen: Pods sind nicht isoliert. Sobald eine NetworkPolicy einen Pod für Ingress oder Egress auswählt, gelten nur noch die erlaubten Verbindungen für diese Richtung.

Beispiel: Default-Deny für Ingress in einem Namespace:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: workshop
spec:
  podSelector: {}
  policyTypes:
    - Ingress

Beispiel: Erlaube Frontend zu Backend:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-api
  namespace: workshop
spec:
  podSelector:
    matchLabels:
      app.kubernetes.io/name: shop-api
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app.kubernetes.io/name: shop-frontend
      ports:
        - protocol: TCP
          port: 8080

Wichtige Regeln:

• NetworkPolicies wirken nur mit unterstützendem CNI.
• Policies sind additiv: Mehrere Policies können zusammen erlauben.
• Es gibt keine explizite Deny-Regel im Standardmodell; du modellierst Deny über fehlende Allow-Regeln nach Isolation.
• DNS muss bei Egress-Restriktionen bewusst erlaubt werden.
• Node-Traffic und manche Infrastrukturpfade können besondere Ausnahmen haben.

10.10 Häufige Netzwerk-Fehlerbilder

11. Konfiguration und Secrets

Konfiguration sollte vom Image getrennt werden. Ein Container-Image beschreibt Artefakt und Standardverhalten. Umgebungsspezifische Werte gehören in Kubernetes-Objekte oder externe Konfigurationssysteme.

11.1 ConfigMap

Eine ConfigMap speichert nicht geheime Konfiguration.

Beispiel:

apiVersion: v1
kind: ConfigMap
metadata:
  name: shop-api-config
  namespace: workshop
data:
  LOG_LEVEL: "info"
  FEATURE_CHECKOUT_V2: "true"
  application.yaml: |
    server:
      port: 8080
    cache:
      ttlSeconds: 300

ConfigMaps eignen sich für:

• Feature Flags ohne Geheimnisse;
• Log-Level;
• URLs interner Dienste;
• Konfigurationsdateien;
• nicht sensible Parameter.

ConfigMaps eignen sich nicht für:

• Passwörter;
• Tokens;
• private Schlüssel;
• Kundendaten;
• vertrauliche Konfiguration.

11.2 Secret

Ein Secret speichert sensible Daten als Kubernetes-Objekt. Standardmäßig sind Werte base64-kodiert, nicht automatisch stark geschützt. Base64 ist keine Verschlüsselung.

Beispiel:

apiVersion: v1
kind: Secret
metadata:
  name: shop-api-secret
  namespace: workshop
type: Opaque
stringData:
  DB_USER: shop
  DB_PASSWORD: replace-me

Gute Secret-Regeln:

• echte Secrets nicht in Git committen;
• RBAC auf Secrets streng begrenzen;
• Encryption at Rest für Secret-Daten aktivieren;
• externe Secret-Systeme prüfen, zum Beispiel Vault, cloud-native Secret Manager oder External Secrets Operator;
• Secret-Rotation planen;
• Secrets nicht in Logs ausgeben;
• Secrets nicht über Umgebungsvariablen exponieren, wenn Prozesslisten, Dumps oder Debugging das Risiko erhöhen.

11.3 Environment Variables und Volumes

ConfigMaps und Secrets können als Environment Variables oder als Dateien gemountet werden.

Environment Variables:

envFrom:
  - configMapRef:
      name: shop-api-config
  - secretRef:
      name: shop-api-secret

Volume Mount:

volumes:
  - name: config
    configMap:
      name: shop-api-config
containers:
  - name: app
    volumeMounts:
      - name: config
        mountPath: /etc/shop
        readOnly: true

Unterschied:

11.4 Konfigurationsänderungen und Rollouts

Eine Änderung an ConfigMap oder Secret startet nicht automatisch jeden Deployment-Pod neu. Viele Teams nutzen Prüfsummen-Annotations im Pod Template, damit eine Änderung am Config-Objekt einen neuen ReplicaSet-Rollout auslöst.

Konzept:

metadata:
  annotations:
    checksum/config: "sha256-of-rendered-config"

Wenn sich die Annotation im Pod Template ändert, ändert sich das Template. Das Deployment erzeugt ein neues ReplicaSet.

Denkfehler: Konfigurationsänderung ist ein Release-Ereignis. Jede Konfigurationsänderung braucht Validierung, Rollout-Strategie und Rollback-Pfad wie Code.

12. Storage

Container-Dateisysteme sind kurzlebig. Wenn ein Container oder Pod ersetzt wird, ist lokaler Zustand nicht zuverlässig dauerhaft. Kubernetes trennt deshalb Workload-Lebenszyklus und Storage-Lebenszyklus.

12.1 Ephemerer Speicher

Ephemerer Speicher lebt mit dem Pod oder Node.

Beispiele:

Wichtig: Memory-basierte emptyDir-Volumes können zum Speicherverbrauch des Pods beitragen. Ohne sinnvolle Limits kann das zu Node- oder Pod-Problemen führen.

12.2 Volumes

Volumes stellen einem Pod Dateisystembereiche bereit. Es gibt viele Volume-Typen, zum Beispiel:

• emptyDir;
• configMap;
• secret;
• projected;
• persistentVolumeClaim;
• CSI-basierte Volumes.

Volume Mounts erfolgen in Container:

volumes:
  - name: data
    persistentVolumeClaim:
      claimName: shop-data
containers:
  - name: app
    volumeMounts:
      - name: data
        mountPath: /var/lib/shop

Trenne im Design:

• Konfigurationsdaten;
• geheime Daten;
• temporäre Arbeitsdaten;
• persistente Anwendungsdaten;
• Logs und Telemetrie;
• Backups.

12.3 PersistentVolume, PersistentVolumeClaim und StorageClass

Das PersistentVolume-Subsystem abstrahiert Speicherbereitstellung von Speichernutzung.

Ablauf:

flowchart LR
  pvc[PVC fordert Speicher an] --> sc[StorageClass]
  sc --> csi[CSI Provisioner]
  csi --> pv[PV wird erstellt]
  pv --> pod[Pod mountet Volume über PVC]

Beispiel-PVC:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: shop-data
  namespace: workshop
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: fast-ssd
  resources:
    requests:
      storage: 20Gi

Wichtige Storage-Fragen:

• Welcher accessMode wird benötigt?
• Ist das Volume an einen Node oder eine Zone gebunden?
• Welche Performance garantiert die StorageClass?
• Was passiert bei Löschung des PVC?
• Gibt es Snapshots?
• Ist Restore getestet?
• Unterstützt der Treiber Expansion?
• Wie werden Daten verschlüsselt?

12.4 CSI

CSI steht für Container Storage Interface. Es ist die standardisierte Schnittstelle, über die Storage-Systeme in Kubernetes integriert werden.

Typische CSI-Komponenten:

• Controller-Komponente für Provisionierung, Attach, Detach, Snapshot oder Expansion;
• Node-Komponente als DaemonSet für Mounts auf Nodes;
• StorageClass-Parameter für Treiberverhalten;
• VolumeSnapshotClass für Snapshots, wenn unterstützt.

CSI trennt Kubernetes-Kernlogik von Storage-spezifischer Implementierung. Das ist leistungsfähig, aber bedeutet auch: Details hängen stark vom konkreten Treiber ab.

12.5 Stateful Storage Design

Für zustandsbehaftete Workloads reichen PVCs allein nicht aus. Du brauchst ein vollständiges Datenkonzept.

Prüffragen:

• Ist die Anwendung für Kubernetes-Betrieb geeignet?
• Kann die Anwendung mit Pod-Neustarts umgehen?
• Ist Storage zonal oder regional?
• Muss der Pod auf denselben Node oder dieselbe Zone zurück?
• Wie funktioniert Replikation?
• Wie funktioniert Quorum?
• Wie funktioniert Backup?
• Wie funktioniert Restore in eine neue Umgebung?
• Sind Migrationsschritte idempotent?
• Was passiert bei Split-Brain oder Netzpartitionen?

Denkfehler: „StatefulSet plus PVC“ ist keine vollständige Datenbankarchitektur.

12.6 Backup, Restore und Datenkonsistenz

Backup-Konzepte müssen Datenkonsistenz beachten.

Restore ist wichtiger als Backup. Ein Backup ist erst dann belastbar, wenn du den Restore-Prozess regelmäßig testest.

13. Scheduling und Ressourcen

13.1 Scheduling-Grundlagen

Der Scheduler weist Pods Nodes zu. Er betrachtet unter anderem:

• Ressourcenanforderungen;
• Node-Kapazität und Allocatable;
• NodeSelector;
• Node Affinity;
• Pod Affinity und Anti-Affinity;
• Taints und Tolerations;
• Topology Spread Constraints;
• Volume-Bindings;
• Priority und Preemption;
• Policies und Scheduler-Profile.

Scheduling ist eine Entscheidung über Platzierung, nicht über Startfähigkeit der Anwendung. Ein Pod kann erfolgreich geplant sein und trotzdem später wegen Image Pull, Config, Volume Mount oder Runtime-Problemen scheitern.

13.2 Requests und Limits

Requests und Limits sind Kernkonzepte für Kapazitätsplanung.

Beispiel:

resources:
  requests:
    cpu: 100m
    memory: 128Mi
  limits:
    memory: 256Mi

Hinweise:

• CPU wird in Cores oder Millicores angegeben; 100m entspricht 0,1 CPU.
• Memory wird in Bytes beziehungsweise Einheiten wie Mi oder Gi angegeben.
• Für viele Anwendungen ist ein Memory-Limit sinnvoller als ein CPU-Limit, weil CPU-Throttling Latenzprobleme verursachen kann.
• Ohne Requests kann der Scheduler Kapazität nicht zuverlässig planen.
• Zu hohe Requests führen zu schlechter Auslastung oder Pending-Pods.
• Zu niedrige Memory-Limits führen zu OOMKills.

13.3 QoS-Klassen

Kubernetes ordnet Pods QoS-Klassen zu:

QoS beeinflusst, welche Pods bei Node-Ressourcenknappheit eher evicted werden.

13.4 NodeSelector, Affinity und Anti-Affinity

NodeSelector ist die einfache Form der Node-Auswahl:

nodeSelector:
  kubernetes.io/os: linux

Node Affinity ist ausdrucksstärker:

affinity:
  nodeAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      nodeSelectorTerms:
        - matchExpressions:
            - key: topology.kubernetes.io/zone
              operator: In
              values:
                - eu-central-1a
                - eu-central-1b

Pod Anti-Affinity kann verhindern, dass Replikate derselben Anwendung auf demselben Node oder in derselben Zone landen.

Denkfehler: Harte Regeln verbessern nicht automatisch Verfügbarkeit. Zu viele harte Constraints können Pods unschedulable machen.

13.5 Taints und Tolerations

Taints stoßen Pods ab. Tolerations erlauben Pods, trotz Taint geplant zu werden.

Beispiel:

tolerations:
  - key: "dedicated"
    operator: "Equal"
    value: "gpu"
    effect: "NoSchedule"

Typische Effekte:

Taints sind nützlich für dedizierte Nodes, GPU-Nodes, Infrastruktur-Nodes oder Maintenance-Situationen.

13.6 Topology Spread Constraints

Topology Spread Constraints verteilen Pods über Topologien wie Nodes, Zonen oder Regionen.

Ziel: Du willst vermeiden, dass alle Replikate auf demselben Node oder in derselben Zone laufen.

Beispielkonzept:

topologySpreadConstraints:
  - maxSkew: 1
    topologyKey: topology.kubernetes.io/zone
    whenUnsatisfiable: DoNotSchedule
    labelSelector:
      matchLabels:
        app.kubernetes.io/name: shop-api

Achte darauf, dass die Topologie-Labels auf Nodes vorhanden und korrekt sind.

13.7 PriorityClass und Preemption

PriorityClass weist Pods Prioritäten zu. Wenn Ressourcen knapp sind, kann Kubernetes niedrig priorisierte Pods verdrängen, damit höher priorisierte Pods laufen können.

Das ist mächtig und gefährlich:

• Kritische Infrastruktur kann bevorzugt werden.
• Falsch gesetzte Prioritäten können wichtige Workloads verdrängen.
• Preemption löst keine dauerhafte Unterkapazität.
• Prioritäten müssen organisatorisch geregelt sein.

13.8 ResourceQuota und LimitRange

ResourceQuotas begrenzen Ressourcennutzung im Namespace.

Beispiele:

• maximale CPU-Requests;
• maximale Memory-Limits;
• Anzahl Pods;
• Anzahl Services;
• Anzahl PVCs;
• Speicherverbrauch über PVCs.

LimitRanges setzen Defaults und Grenzen pro Objekt oder Container.

Zusammenhang:

Denkfehler: Quotas ohne Monitoring erzeugen Überraschungen. Teams müssen sehen können, warum neue Workloads abgelehnt werden.

13.9 Autoscaling-Konzepte

Autoscaling gibt es auf mehreren Ebenen:

Autoscaling braucht stabile Signale. CPU-basierte Skalierung ist einfach, aber nicht immer fachlich passend. Queue-Länge, Requests per Second, Latenz oder externe Metriken können aussagekräftiger sein.

14. Security

Kubernetes Security ist Schichtenarbeit. Es reicht nicht, nur ein einzelnes Feature zu aktivieren.

flowchart TD
  authn[Authentifizierung] --> authz[Autorisierung]
  authz --> admission[Admission Control]
  admission --> podsec[Pod Security]
  podsec --> runtime[Runtime Hardening]
  runtime --> network[Network Policies]
  network --> secrets[Secret-Schutz]
  secrets --> audit[Audit und Monitoring]

14.1 Authentifizierung, Autorisierung und Admission

Admission passiert nach Authentifizierung und Autorisierung, aber vor Persistierung des Objekts. Admission kann Objekte validieren oder mutieren.

Typische Admission-Aufgaben:

• Default-Werte setzen;
• unsichere Pods ablehnen;
• Image-Registries einschränken;
• Pflichtlabels erzwingen;
• Resource Requests verlangen;
• HostPath oder privileged Pods verbieten;
• Sidecars injizieren.

14.2 ServiceAccounts

Ein ServiceAccount ist eine Identität für Pods und Controller im Cluster. Pods können über ServiceAccount-Tokens mit der Kubernetes API sprechen.

Regeln:

• Verwende pro Anwendung eigene ServiceAccounts.
• Binde nur die Rechte, die wirklich notwendig sind.
• Vermeide den default ServiceAccount für produktive Workloads.
• Setze automountServiceAccountToken: false, wenn die Anwendung keine Kubernetes API benötigt.
• Prüfe, welche Pods mit welchem ServiceAccount laufen.

Beispiel:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: shop-api
  namespace: workshop
automountServiceAccountToken: false

14.3 RBAC

RBAC steuert Zugriff auf Kubernetes-Ressourcen. Es besteht aus Rollen und Bindings.

Subjekte können sein:

• User;
• Groups;
• ServiceAccounts.

Beispiel:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-reader
  namespace: workshop
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "list", "watch"]

Gute RBAC-Regeln:

• kein unnötiges cluster-admin;
• keine Wildcards ohne Begründung;
• Secrets separat schützen;
• create pods/exec und pods/portforward bewusst behandeln;
• Subresources berücksichtigen;
• Bindings regelmäßig auditieren.

14.4 Pod Security Standards

Pod Security Standards definieren drei Profile:

Pod Security Admission kann Namespaces anhand von Labels prüfen:

metadata:
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

Denkfehler: Pod Security ersetzt kein RBAC, keine NetworkPolicy und keine Image-Prüfung. Es ist eine Laufzeit-/Spec-Härtungsschicht.

14.5 SecurityContext

Der SecurityContext beschreibt Sicherheitsoptionen auf Pod- oder Container-Ebene.

Beispiel:

securityContext:
  runAsNonRoot: true
  seccompProfile:
    type: RuntimeDefault
containers:
  - name: app
    securityContext:
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: true
      capabilities:
        drop:
          - ALL

Wichtige Optionen:

• runAsNonRoot;
• runAsUser und runAsGroup;
• fsGroup;
• allowPrivilegeEscalation;
• privileged;
• Linux Capabilities;
• Seccomp-Profil;
• AppArmor, je nach Umgebung;
• readOnlyRootFilesystem.

Gute Praxis: Starte mit einem restriktiven Profil und füge nur begründet Rechte hinzu.

14.6 Images und Supply Chain

Kubernetes startet Images, aber es garantiert nicht automatisch deren Herkunft, Integrität oder Sicherheit.

Prüffragen:

• Woher kommt das Image?
• Ist der Tag unveränderlich oder nutzt du Digests?
• Wird das Image gescannt?
• Gibt es SBOMs?
• Ist die Signatur prüfbar?
• Sind Base Images aktuell?
• Enthält das Image unnötige Tools oder Secrets?
• Läuft der Prozess als Non-Root?

Nutze möglichst unveränderliche Referenzen:

image: registry.example.com/platform/shop-api@sha256:0123456789abcdef...

Tags wie latest sind für reproduzierbare Deployments ungeeignet.

14.7 Secrets, Verschlüsselung und externe Secret-Systeme

Secret-Schutz besteht aus mehreren Ebenen:

• Zugriff über RBAC minimieren;
• Encryption at Rest aktivieren;
• Secret-Zugriff in Audits beobachten;
• Rotation und Ablaufdaten definieren;
• externe Secret-Systeme einbinden;
• Secrets nicht in Images, Logs oder Git speichern;
• Debug-Zugriff begrenzen.

Wichtig: Wer einen Pod erstellen kann, der ein Secret mountet, kann oft indirekt an Secret-Werte gelangen. RBAC muss deshalb Pod-Erstellung, Exec, Debug und Secret-Zugriff zusammen betrachten.

14.8 Mandantentrennung

Namespaces sind ein Baustein für Mandantentrennung, aber keine harte Grenze wie separate Cluster.

Für Mandantentrennung brauchst du typischerweise:

• Namespace-Strategie;
• RBAC pro Team oder Anwendung;
• ResourceQuotas;
• LimitRanges;
• NetworkPolicies;
• Pod Security Enforcement;
• Admission-Policies;
• separate Ingress-/Gateway-Regeln;
• Secret-Isolation;
• Audit und Kostenreporting;
• gegebenenfalls separate Cluster für starke Isolation.

Entscheidungsregel: Wenn Mandanten sich gegenseitig nicht vertrauen, ist ein separater Cluster oft einfacher und sicherer als sehr komplexe Isolation innerhalb eines Clusters.

15. Beobachtbarkeit und Troubleshooting

Kubernetes liefert viele Signale, aber du musst wissen, welche Frage du stellst.

15.1 Status, Events und Logs

Grundsatz: kubectl get zeigt Symptome. kubectl describe, Events, Logs und Statusdetails zeigen Ursachen näher an.

15.2 Metriken

Metriken beantworten quantitative Fragen:

• Wie viel CPU nutzt der Pod?
• Wie viel Memory nutzt der Container?
• Wie viele Requests verarbeitet die Anwendung?
• Wie hoch ist die Latenz?
• Wie viele Fehler treten auf?
• Wie voll ist ein Volume?
• Wie hoch ist die API-Server-Latenz?
• Wie viele etcd-Leader-Wechsel gab es?

Typische Metrikquellen:

• Metrics Server für einfache Ressourcenmetriken;
• Prometheus für Zeitreihen;
• kube-state-metrics für Objektzustände;
• cAdvisor/kubelet-Metriken für Container- und Node-Signale;
• Controller- und Add-on-Metriken;
• Anwendungsmetering.

15.3 Traces

Traces helfen bei verteilten Anfragen über mehrere Services hinweg. Kubernetes selbst löst keine Anwendungstraces. Du brauchst Instrumentierung, zum Beispiel über OpenTelemetry.

Traces sind besonders nützlich, wenn:

• mehrere Microservices beteiligt sind;
• Latenzpfade unklar sind;
• Fehler nur bei bestimmten Aufrufketten auftreten;
• externe Abhängigkeiten beteiligt sind;
• du SLOs auf Request-Ebene verstehst.

15.4 Auditing

Audit-Logs beantworten Governance-Fragen:

• Wer hat welches Objekt geändert?
• Wer hat ein Secret gelesen?
• Wer hat exec in einen Pod ausgeführt?
• Welche ServiceAccounts sprechen mit der API?
• Welche Admission-Entscheidungen wurden getroffen?

Audit ist für Security, Compliance und Incident Response zentral. Ohne Audit kannst du viele Clusteränderungen nachträglich nur schwer rekonstruieren.

15.5 Fehlerdiagnose nach Schichten

Diagnostiziere Kubernetes-Probleme schichtweise:

Manifest -> API -> Admission -> Scheduling -> Node -> Runtime -> Netzwerk -> Storage -> Anwendung

16. Plattformbetrieb

16.1 Versionen und Upgrades

Kubernetes entwickelt sich kontinuierlich. Versionen betreffen API-Kompatibilität, Feature Gates, Add-ons, Container Runtime, CNI, CSI und Betriebssysteme.

Upgrade-Fragen:

• Welche Kubernetes-Version läuft aktuell?
• Welche Zielversion ist unterstützt?
• Gibt es entfernte oder deprecated APIs?
• Sind Add-ons kompatibel?
• Sind CRDs und Webhooks kompatibel?
• Gibt es PodDisruptionBudgets für kritische Workloads?
• Ist etcd gesichert?
• Ist ein Rollback- oder Wiederherstellungsplan vorhanden?

Produktionsupgrades sind keine reine kubeadm upgrade-Übung. Ein Upgrade ist ein Plattformänderungsprozess.

16.2 etcd und Clusterzustand

etcd speichert den Clusterzustand. Dazu gehören API-Objekte, Secrets, Statusinformationen und Konfigurationen.

Betriebsanforderungen:

• regelmäßige Snapshots;
• gesicherte Snapshot-Aufbewahrung;
• Restore-Test;
• Monitoring von Latenz, Disk, Quorum und Leader-Wechseln;
• Zugriffsschutz;
• Verschlüsselung sensibler Daten;
• sorgfältige Upgrade-Reihenfolge.

Denkfehler: Ein Backup der YAML-Dateien ersetzt kein etcd-Backup. Umgekehrt ersetzt ein etcd-Backup nicht automatisch Backups externer Datenbanken oder Volumes.

16.3 Node-Lifecycle

Nodes sind austauschbare Kapazität, aber nicht bedeutungslos. Node-Zustand beeinflusst Scheduling, Performance und Verfügbarkeit.

Wichtige Konzepte:

• Ready / NotReady;
• Node Conditions wie MemoryPressure, DiskPressure, PIDPressure;
• Cordon und Drain;
• kubelet-Status;
• Container Runtime;
• CNI-Status;
• lokale Images und Cache;
• lokale Volumes;
• Kernel- und cgroup-Konfiguration.

Bei Wartung setzt du einen Node typischerweise erst auf unschedulable und drainst danach Workloads kontrolliert. DaemonSets, PDBs und lokale Daten müssen dabei berücksichtigt werden.

16.4 Add-on-Lifecycle

Add-ons sind Teil der Plattform und brauchen Lifecycle-Management.

Für jedes Add-on solltest du wissen:

• Wer ist Owner?
• Welche Version läuft?
• Wie wird es installiert?
• Wie wird es aktualisiert?
• Welche CRDs bringt es mit?
• Welche RBAC-Rechte hat es?
• Welche Webhooks registriert es?
• Was passiert, wenn es ausfällt?
• Wie wird es beobachtet?
• Wie wird es deinstalliert?

Besonders kritisch sind Add-ons, die im API-Pfad liegen, etwa Admission Webhooks. Ein fehlerhafter Webhook kann Clusteränderungen blockieren.

16.5 Backup- und Restore-Denken

Du brauchst verschiedene Backupebenen:

Restore-Reihenfolge muss geplant werden. Beispiel: Erst Cluster und CRDs, dann Operatoren, dann Secrets, dann PVCs oder Datenrestore, dann Workloads.

17. Erweiterbarkeit

Kubernetes ist erweiterbar. Das ist einer der Hauptgründe für seine Verbreitung, aber auch eine Quelle von Komplexität.

17.1 CRDs

CustomResourceDefinitions erweitern die Kubernetes API um eigene Ressourcentypen.

Beispielhafte CRDs:

• Certificate von cert-manager;
• Application von Argo CD;
• Prometheus vom Prometheus Operator;
• Gateway und HTTPRoute der Gateway API;
• Datenbankressourcen eines Operators.

CRDs definieren Schema, Versionen und Validierung eigener Objekte. Eine CRD speichert aber allein noch keine Logik. Die Logik kommt durch Controller.

Wichtige CRD-Fragen:

• Welche Versionen werden unterstützt?
• Gibt es Conversion Webhooks?
• Sind Statusfelder sauber definiert?
• Was passiert beim Löschen?
• Gibt es Finalizers?
• Wie werden Upgrades durchgeführt?
• Ist das Schema restriktiv genug?

17.2 Controller und Operatoren

Ein Operator ist ein Controller mit domänenspezifischem Betriebswissen. Er verwaltet komplexe Anwendungen oder externe Ressourcen über Kubernetes-APIs.

Beispiele:

• Datenbank-Operator erstellt Cluster, Backups und Failover;
• cert-manager erstellt und erneuert Zertifikate;
• External Secrets Operator synchronisiert Secrets aus externen Systemen;
• Prometheus Operator verwaltet Monitoring-Ressourcen;
• Cloud-Operatoren verwalten externe Infrastruktur.

Denkfehler: Operatoren reduzieren manuelle Arbeit, aber sie verschieben Komplexität in Controller-Logik. Du musst weiterhin Upgrades, Backups, Rechte, Fehlerfälle und Datenkonsistenz verstehen.

17.3 Webhooks und Admission Policies

Admission Webhooks greifen in den API-Schreibpfad ein.

Risiken:

• Webhook nicht erreichbar blockiert API-Änderungen, je nach Failure Policy;
• langsamer Webhook erhöht API-Latenz;
• fehlerhafte Mutation erzeugt schwer sichtbare Änderungen;
• zu breite Regeln betreffen unerwartete Namespaces;
• Upgrade des Webhook-Services kann Clusterbetrieb stören.

Gute Regeln:

• Scope eng setzen;
• Failure Policy bewusst wählen;
• Timeouts niedrig halten;
• Webhooks hochverfügbar betreiben;
• eigene Webhook-Metriken und Logs überwachen;
• Break-Glass-Prozess dokumentieren.

17.4 API Aggregation

API Aggregation erlaubt zusätzliche API-Server hinter dem Kubernetes API Server. Dieser Mechanismus wird für manche Erweiterungen genutzt, zum Beispiel aggregierte APIs.

Für den Workshop reicht meist diese Abgrenzung:

• CRDs erweitern die API über Custom Resources im Kubernetes API Server.
• API Aggregation bindet zusätzliche API-Server ein.
• Admission Webhooks prüfen oder verändern Objekte beim Schreiben.
• Controller reagieren auf gespeicherte Objekte und führen Logik aus.

18. Entscheidungsmodelle

Kubernetes-Konzepte werden praktisch, wenn du Entscheidungen triffst. Die folgenden Modelle helfen dir im Workshop und im Betrieb.

18.1 Deployment oder StatefulSet?

18.2 ConfigMap oder Secret?

18.3 Service, Ingress oder Gateway?

18.4 Requests und Limits setzen

18.5 NetworkPolicy-Strategie

19. Typische Fehlerbilder als Konzeptlandkarte

20. Workshop-Übungen

Diese Übungen sind konzeptionell formuliert. Die konkrete Umsetzung findest du in der Kommandoreferenz oder in Lab-Dateien.

Übung 1: Objektstruktur lesen

Nimm ein Deployment-Manifest und markiere:

• apiVersion;
• kind;
• metadata.name;
• metadata.namespace;
• Labels;
• Selector;
• Pod Template;
• Container Image;
• Ports;
• Probes;
• Ressourcen.

Erkläre danach, welche Felder Absicht sind und welche Felder Kubernetes später als Status ergänzt.

Übung 2: Selector-Kette verstehen

Erstelle gedanklich diese Kette:

Deployment selector -> Pod labels -> Service selector -> EndpointSlice -> Traffic

Beantworte:

• Was passiert, wenn das Pod-Label nicht zum Deployment-Selector passt?
• Was passiert, wenn das Pod-Label nicht zum Service-Selector passt?
• Was passiert, wenn die Readiness Probe fehlschlägt?

Übung 3: Pod-Fehler klassifizieren

Ordne folgende Symptome Konzeptbereichen zu:

• ErrImagePull;
• FailedScheduling;
• Readiness probe failed;
• MountVolume.SetUp failed;
• Forbidden;
• OOMKilled.

Ziel: Du sollst nicht sofort Kommandos auswendig ausführen, sondern zuerst die betroffene Schicht erkennen.

Übung 4: Deployment vs StatefulSet

Bewerte drei Anwendungen:

1. HTTP-API ohne lokalen Zustand;
2. PostgreSQL-Datenbank;
3. Log-Agent auf jedem Node.

Entscheide für jede Anwendung, welche Workload-Ressource fachlich passt und warum.

Übung 5: Netzwerkmodell zeichnen

Zeichne für eine Webanwendung:

Client -> Load Balancer -> Ingress/Gateway -> Service -> EndpointSlice -> Pod -> Container-Port

Markiere, an welchen Stellen DNS, TLS, Labels, Readiness und NetworkPolicies wirken.

Übung 6: Ressourcen planen

Für eine Anwendung werden folgende Beobachtungen gemeldet:

• durchschnittlich 80 MiB Memory;
• Peaks bis 180 MiB;
• gelegentliche CPU-Spitzen;
• Latenz ist wichtig;
• drei Replikate sollen laufen.

Leite ab:

• Memory Request;
• Memory Limit;
• CPU Request;
• ob ein CPU Limit sinnvoll ist;
• welche Metriken du für HPA prüfen würdest.

Übung 7: Security-Schichten bauen

Entwirf für einen Namespace:

• eigenen ServiceAccount;
• minimale RBAC-Rolle;
• Pod Security restricted;
• Default-Deny NetworkPolicy;
• erlaubten Traffic vom Frontend zur API;
• Secret-Management-Regel.

Ziel: Du erkennst, dass Security nicht aus einem einzelnen YAML-Objekt besteht.

Übung 8: Storage-Entscheidung treffen

Eine Anwendung braucht persistenten Speicher. Beantworte:

• Braucht jeder Pod ein eigenes Volume?
• Darf der Pod in eine andere Zone verschoben werden?
• Muss das Volume von mehreren Pods gelesen oder geschrieben werden?
• Gibt es Snapshots?
• Wie wird Restore getestet?
• Welche Daten dürfen verloren gehen?

Übung 9: CRD und Operator bewerten

Wähle einen Operator, zum Beispiel cert-manager oder Prometheus Operator. Prüfe:

• welche CRDs installiert werden;
• welche Controller laufen;
• welche RBAC-Rechte vergeben werden;
• welche Webhooks genutzt werden;
• was beim Ausfall des Operators passiert;
• wie Upgrades dokumentiert sind.

Übung 10: Fehlerkette rekonstruieren

Symptom: Nach einem Rollout ist die Anwendung nicht erreichbar.

Arbeite konzeptionell von oben nach unten:

1. Ist das Deployment verfügbar?
2. Sind neue Pods ready?
3. Hat der Service Endpoints?
4. Routet Ingress oder Gateway auf den richtigen Service?
5. Greifen NetworkPolicies?
6. Funktioniert DNS?
7. Antwortet die Anwendung lokal im Pod?

21. Glossar

22. Quellen und weiterführende Dokumentation

Die folgenden offiziellen Dokumentationsseiten eignen sich als fachliche Vertiefung:

• Kubernetes Overview: https://kubernetes.io/docs/concepts/overview/
• Kubernetes Components: https://kubernetes.io/docs/concepts/overview/components/
• Cluster Architecture: https://kubernetes.io/docs/concepts/architecture/
• Kubernetes API Concepts: https://kubernetes.io/docs/reference/using-api/api-concepts/
• Objects in Kubernetes: https://kubernetes.io/docs/concepts/overview/working-with-objects/
• Labels and Selectors: https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/
• Namespaces: https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/
• Pods: https://kubernetes.io/docs/concepts/workloads/pods/
• Deployments: https://kubernetes.io/docs/concepts/workloads/controllers/deployment/
• StatefulSets: https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/
• DaemonSets: https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/
• Jobs: https://kubernetes.io/docs/concepts/workloads/controllers/job/
• CronJobs: https://kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/
• Services: https://kubernetes.io/docs/concepts/services-networking/service/
• Gateway API: https://kubernetes.io/docs/concepts/services-networking/gateway/
• Network Policies: https://kubernetes.io/docs/concepts/services-networking/network-policies/
• Persistent Volumes: https://kubernetes.io/docs/concepts/storage/persistent-volumes/
• Resource Management for Pods and Containers: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/
• RBAC Authorization: https://kubernetes.io/docs/reference/access-authn-authz/rbac/
• Pod Security Standards: https://kubernetes.io/docs/concepts/security/pod-security-standards/