1. Ziel des Curriculums

Das Curriculum soll dir helfen, Kubernetes nicht nur als Sammlung einzelner Befehle zu verstehen, sondern als Plattformmodell für den Betrieb containerisierter Anwendungen. Du lernst, wie Anwendungen deklariert, ausgerollt, überwacht, abgesichert, skaliert und im Fehlerfall analysiert werden.

Nach Abschluss der vollständigen Reihe kannst du:

• Kubernetes-Architektur und Verantwortlichkeiten erklären.
• Kubernetes-Ressourcen lesen, schreiben, validieren und betreiben.
• Anwendungen mit Deployments, Services, ConfigMaps, Secrets, Probes und Ressourcenangaben produktionsnah ausrollen.
• typische Fehlerbilder mit kubectl, Logs, Events, Metriken und Ressourcenstatus analysieren.
• Plattformthemen wie Netzwerk, Storage, Scheduling, Add-ons, Observability, GitOps und Backup einordnen.
• Security-Kontrollen wie RBAC, ServiceAccounts, Pod Security Standards, NetworkPolicies und Secret-Schutz anwenden.
• Architekturentscheidungen dokumentieren und Kubernetes-Lösungen reviewfähig machen.

1.1. Was dieses Curriculum leisten soll

Dieses Curriculum ist für Workshops, interne Schulungen, Bootcamps und strukturierte Selbstlernphasen gedacht. Es kombiniert konzeptionelle Erklärungen mit konkreten Übungen. Jede Lerneinheit soll einen Bezug zu realem Betrieb haben: Was passiert im Cluster? Wie prüfst du den Zustand? Welche Risiken entstehen? Wie kannst du Änderungen rückbauen?

1.2. Was dieses Curriculum bewusst nicht ersetzt

Das Curriculum ersetzt keine produktive Plattformdokumentation deines Unternehmens, keine Provider-spezifische Betriebsanleitung und keine vollständige Security-Richtlinie. Es liefert die fachliche Struktur, mit der du solche Dokumente erstellen, prüfen oder verbessern kannst.

2. Didaktisches Modell

Der Workshop folgt einem wiederkehrenden Lernzyklus:

Verstehen -> Anwenden -> Beobachten -> Debuggen -> Absichern -> Dokumentieren

Jedes Thema wird nach Möglichkeit in fünf Schritten behandelt:

2.1. Lernprinzipien

• Deklarativ denken: Du beschreibst Zielzustände, statt manuell Prozesse im Cluster zusammenzuklicken.
• Status lesen: Du lernst, spec, status, Conditions und Events als Diagnosequellen zu nutzen.
• Fehler bewusst erzeugen: Du lernst schneller, wenn du typische Fehlerbilder kontrolliert reproduzierst.
• Betrieb einbeziehen: Jede Übung enthält Validierung, Rückbau und eine kurze Betriebsbewertung.
• Security nicht anhängen: Sicherheitsaspekte werden von Anfang an mitgeführt, nicht erst am Ende ergänzt.
• Reviewfähigkeit herstellen: Jede Lösung soll nachvollziehbar, versionierbar und prüfbar sein.

2.2. Tiefe pro Thema

Nicht jedes Thema braucht dieselbe Tiefe. Für Einsteiger reichen mentale Modelle und sichere Standardpfade. Für Plattformteams brauchst du zusätzlich Upgrade-, Failure-, Security- und Betriebsbetrachtungen.

3. Zielgruppen und Rollen

Das Curriculum ist modular. Du kannst es für unterschiedliche Rollen zuschneiden.

3.1. Erwartete Ergebnisse je Rolle

Entwickler

Du sollst nach dem Training eine Anwendung sauber in Kubernetes ausrollen können. Dazu gehören Deployment, Service, Konfiguration, Probes, Ressourcenangaben, Logs und ein einfacher Rollback.

DevOps und System Engineers

Du sollst Workloads produktionsnah betreiben können. Dazu gehören Debugging, Rollout-Strategien, Storage, Ingress, DNS, Ressourcenmanagement, Helm oder Kustomize sowie Basissicherheit.

Platform Engineers und SREs

Du sollst Plattformentscheidungen bewerten können. Dazu gehören Clusterarchitektur, Add-ons, GitOps, Observability, Multi-Tenancy, Upgrade-Strategien, Backup und Disaster Recovery.

Security Engineers

Du sollst Kubernetes-spezifische Angriffsflächen erkennen und technische Kontrollen umsetzen können. Dazu gehören RBAC, ServiceAccounts, Admission, Pod Security Standards, NetworkPolicies, Secret-Schutz, Image Security und Runtime Detection.

4. Voraussetzungen

4.1. Fachliche Voraussetzungen

Für den Einstieg brauchst du:

• Grundverständnis von Containern und Images.
• Grundkenntnisse der Linux-Shell.
• Grundverständnis von HTTP, DNS, Ports und TCP/IP.
• Basiswissen zu YAML.
• Fähigkeit, Fehlermeldungen systematisch zu lesen.

Für Professional und Advanced solltest du zusätzlich mitbringen:

• Erfahrung mit CI/CD oder GitOps.
• Erfahrung mit Linux-Systemdiensten und Logs.
• Verständnis von TLS, Zertifikaten, Authentifizierung und Autorisierung.
• Grundverständnis von Cloud-Netzwerk, Load Balancing und Storage.
• Erfahrung mit Monitoring- und Logging-Systemen.

4.2. Technische Voraussetzungen

Für die Labs brauchst du mindestens:

• kubectl
• Zugriff auf einen Kubernetes-Cluster
• eine Shell-Umgebung
• Git
• einen Editor
• optional: Helm, Kustomize, jq, yq, stern, k9s, crictl

Für lokale Workshops eignen sich je nach Zielsetzung:

• kind
• minikube
• k3d
• k3s
• kubeadm-basierte VMs
• verwaltete Kubernetes-Cluster bei Cloud-Providern

4.3. Vorbereitungscheck

Vor dem Workshop solltest du prüfen:

kubectl version --client
kubectl config current-context
kubectl cluster-info
kubectl get nodes -o wide
kubectl auth can-i get pods -A

Du brauchst für die meisten Übungen einen Namespace, in dem du Ressourcen erstellen, ändern und löschen darfst.

5. Lernpfade

5.1. Lernpfad für Entwickler

Ziel: Du kannst deine Anwendung in Kubernetes deployen, konfigurieren, prüfen und bei Problemen analysieren.

Empfohlene Reihenfolge:

1. Kubernetes-Grundmodell
2. Pods, Deployments und ReplicaSets
3. Services und DNS
4. ConfigMaps und Secrets
5. Probes und Rollouts
6. Logs, Events und Debugging
7. Ressourcenangaben und einfache Skalierung
8. Abschlussübung: Anwendung produktionsnah ausrollen

5.2. Lernpfad für DevOps und System Engineers

Ziel: Du kannst Workloads betreiben, Fehler analysieren und robuste Standards für Teams etablieren.

Empfohlene Reihenfolge:

1. Fundamentals vollständig
2. Workload-Controller im Detail
3. Ressourcenmanagement und Scheduling
4. Ingress, Gateway API und NetworkPolicies
5. Storage und Stateful Workloads
6. Helm, Kustomize und CI/CD-Validierung
7. Observability und Incident-Triage
8. Abschlussübung: Fehlerhafte Anwendung stabilisieren

5.3. Lernpfad für Platform Engineers

Ziel: Du kannst Kubernetes-Plattformen planen, betreiben und weiterentwickeln.

Empfohlene Reihenfolge:

1. Clusterarchitektur und Control Plane
2. kubeadm, Managed Kubernetes und Distributionen
3. CNI, CSI, Ingress und Load Balancing
4. Observability-Stack
5. GitOps und Plattform-Add-ons
6. Multi-Tenancy, Quotas, Policies und Kostensteuerung
7. Backup, Restore und Disaster Recovery
8. Abschlussübung: Plattform-Blueprint erstellen

5.4. Lernpfad für Security Engineers

Ziel: Du kannst Kubernetes-Workloads und Plattformen härten, Angriffe erkennen und Incidents strukturiert bearbeiten.

Empfohlene Reihenfolge:

1. Kubernetes-Bedrohungsmodell
2. API-Zugriff, Authentifizierung und Autorisierung
3. RBAC Least Privilege
4. ServiceAccounts und Token-Verhalten
5. Pod Security Standards und Admission Control
6. SecurityContext, Capabilities, seccomp, AppArmor und SELinux
7. NetworkPolicies und Service-Mesh-/CNI-Policies
8. Secret-Schutz, Image Security und Runtime Detection
9. Abschlussübung: Security Review und Incident-Simulation

6. Kompetenzstufen

6.1. Stufe A: Orientierung

Du kannst beschreiben, was Kubernetes macht, wofür ein Cluster eingesetzt wird und welche Kernkomponenten beteiligt sind.

Erwartete Kompetenz:

• Du erklärst Control Plane und Worker Nodes.
• Du unterscheidest Pod, Deployment und Service.
• Du verstehst Desired State und Reconciliation.
• Du kannst einen Namespace und einfache Ressourcen anzeigen.

6.2. Stufe B: Anwendung

Du kannst einfache Workloads erstellen, ausrollen und prüfen.

Erwartete Kompetenz:

• Du schreibst einfache Manifeste.
• Du nutzt kubectl apply, get, describe, logs und delete sicher.
• Du stellst eine Anwendung über einen Service bereit.
• Du prüfst Events, Logs und Ressourcenzustand.

6.3. Stufe C: Produktionsnähe

Du kannst Workloads robust konfigurieren.

Erwartete Kompetenz:

• Du definierst Requests, Limits und Probes.
• Du nutzt ConfigMaps und Secrets bewusst.
• Du steuerst Rollouts und Rollbacks.
• Du verstehst HPA, PDB und einfache Ingress-Szenarien.
• Du erkennst typische Fehlerbilder.

6.4. Stufe D: Plattformbetrieb

Du kannst Cluster- und Plattformentscheidungen bewerten.

Erwartete Kompetenz:

• Du verstehst Control Plane HA, etcd, CNI, CSI und Add-ons.
• Du bewertest Distributionen und Managed Kubernetes.
• Du planst Observability, GitOps, Backup, Restore und Upgrade-Prozesse.
• Du definierst Multi-Tenancy-Standards.

6.5. Stufe E: Security und Resilienz

Du kannst Kubernetes gezielt härten und Incident-Pfade bearbeiten.

Erwartete Kompetenz:

• Du setzt RBAC Least Privilege um.
• Du prüfst ServiceAccounts und Tokens.
• Du nutzt Pod Security Standards und SecurityContexts.
• Du bewertest NetworkPolicies, Image Security, Secret-Schutz und Runtime Detection.
• Du führst eine strukturierte Incident-Analyse durch.

7. Gesamtstruktur des Workshops

Das Curriculum ist in vier Hauptlevel gegliedert:

7.1. Empfohlene Modulreihenfolge

flowchart TD
  A[Fundamentals] --> B[Intermediate]
  B --> C[Professional]
  B --> D[Advanced und Security]
  C --> E[Plattformprojekt]
  D --> F[Security-Projekt]
  E --> G[Abschlussbewertung]
  F --> G

7.2. Mindestpfad für einen kompakten Workshop

Wenn wenig Zeit verfügbar ist, sollte der Workshop mindestens diese Themen enthalten:

1. Clusterarchitektur und Ressourcenmodell
2. Namespace, Pod, Deployment, ReplicaSet und Service
3. ConfigMap, Secret, Probes und Ressourcenangaben
4. Logs, Events, describe und Rollback
5. RBAC-Grundlagen und Pod Security-Grundlagen
6. Abschlussübung mit Deployment, Service und Fehleranalyse

8. Level 1: Fundamentals

8.1. Ziel

Du verstehst die Grundidee von Kubernetes und kannst einfache Anwendungen deployen, verfügbar machen und prüfen.

8.2. Zielgruppe

• Einsteiger
• Entwickler
• Junior DevOps
• Administratoren mit wenig Kubernetes-Erfahrung
• Teams, die Kubernetes als Zielplattform nutzen werden

8.3. Lernziele

Nach diesem Level kannst du:

• Kubernetes als Orchestrierungsplattform erklären.
• Control Plane und Worker Nodes unterscheiden.
• die Rolle von API Server, etcd, Scheduler, Controller Manager, kubelet und kube-proxy beschreiben.
• Desired State, Actual State und Reconciliation erklären.
• Namespaces, Pods, Deployments, ReplicaSets und Services einordnen.
• Labels und Selectors anwenden.
• mit kubectl Ressourcen anzeigen, erstellen und löschen.
• Logs und Events für einfache Fehleranalyse nutzen.

8.4. Modul F1: Einstieg und mentales Modell

Inhalte:

• Container-Orchestrierung
• gewünschter Zustand und tatsächlicher Zustand
• deklarative Konfiguration
• Kubernetes API als zentrale Schnittstelle
• Controller als kontinuierliche Regelkreise
• Abgrenzung zu Docker, CI/CD, Monitoring und Cloud-Providern

Übung:

kubectl version --client
kubectl cluster-info
kubectl config current-context
kubectl get nodes -o wide
kubectl create namespace workshop
kubectl get namespace workshop

Reflexionsfragen:

• Warum ist ein Kubernetes-Manifest kein Skript?
• Was passiert, wenn der gewünschte Zustand nicht zum tatsächlichen Zustand passt?
• Warum ist die API der zentrale Integrationspunkt?

8.5. Modul F2: Clusterarchitektur

Inhalte:

• Control Plane
• Worker Nodes
• API Server
• etcd
• Scheduler
• Controller Manager
• Cloud Controller Manager
• kubelet
• Container Runtime
• kube-proxy oder eBPF-Dataplane
• CNI-Plugin
• CoreDNS

Übung:

kubectl get nodes -o wide
kubectl get namespaces
kubectl get pods -n kube-system -o wide
kubectl describe node <node-name>

Typische Stolperstellen:

• Du verwechselst Control Plane-Komponenten mit Workload-Komponenten.
• Du erwartest, dass ein Pod direkt von kubectl auf einem Node gestartet wird.
• Du übersiehst, dass Controller den Zustand dauerhaft angleichen.

8.6. Modul F3: Ressourcenmodell und YAML

Inhalte:

• API-Gruppen und Kinds
• Objektmetadaten
• Namespaces
• Labels und Annotations
• spec als gewünschter Zustand
• status als Rückmeldung des Systems
• Conditions und Events
• Ressourcenidentität über Name, Namespace und UID

Beispiel:

apiVersion: v1
kind: Namespace
metadata:
  name: workshop
  labels:
    purpose: training

Übung:

kubectl apply -f namespace.yaml
kubectl get namespace workshop -o yaml
kubectl explain pod.spec.containers

8.7. Modul F4: Pods

Inhalte:

• Pod als Gruppe eines oder mehrerer Container
• gemeinsame Netzwerkidentität
• Container-Ports
• Volumes im Pod
• Restart Policy
• Pod-Phasen
• Container-States
• Events als Fehlerquelle

Übung:

kubectl run nginx-demo -n workshop --image=nginx:1.27 --restart=Never
kubectl get pod nginx-demo -n workshop -o wide
kubectl describe pod nginx-demo -n workshop
kubectl logs nginx-demo -n workshop
kubectl delete pod nginx-demo -n workshop

Wichtige Erkenntnis:

Ein Pod ist in der Regel kein langfristig manuell verwaltetes Objekt. Für normale Anwendungen nutzt du Controller wie Deployments.

8.8. Modul F5: Deployments und ReplicaSets

Inhalte:

• Deployment als Controller für zustandslose Anwendungen
• ReplicaSet als Replikationsmechanismus
• Pod Template
• Selektoren
• Rolling Update
• Revisionen
• Rollback

Beispiel:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
  namespace: workshop
spec:
  replicas: 2
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: nginx
          image: nginx:1.27
          ports:
            - containerPort: 80

Übung:

kubectl apply -f deployment.yaml
kubectl get deployment,replicaset,pod -n workshop
kubectl rollout status deployment/web -n workshop
kubectl scale deployment/web -n workshop --replicas=3
kubectl rollout history deployment/web -n workshop

8.9. Modul F6: Services und Service Discovery

Inhalte:

• Pod-IP als flüchtige Adresse
• Service als stabile Abstraktion
• Label Selector
• ClusterIP
• NodePort
• LoadBalancer
• Endpoints und EndpointSlices
• CoreDNS
• Service-DNS-Namen

Beispiel:

apiVersion: v1
kind: Service
metadata:
  name: web
  namespace: workshop
spec:
  selector:
    app: web
  ports:
    - name: http
      port: 80
      targetPort: 80
  type: ClusterIP

Übung:

kubectl apply -f service.yaml
kubectl get service,endpoints,endpointslice -n workshop
kubectl run dns-test -n workshop --rm -it --image=busybox:1.36 --restart=Never -- sh
wget -qO- http://web.workshop.svc.cluster.local

8.10. Modul F7: kubectl-Grundlagen

Inhalte:

• Kontext und kubeconfig
• Namespaces
• get
• describe
• logs
• apply
• delete
• diff
• explain
• Ausgabeformate
• Field Selector und Label Selector

Übung:

kubectl get all -n workshop
kubectl get pods -n workshop -l app=web
kubectl describe deployment web -n workshop
kubectl logs deployment/web -n workshop
kubectl diff -f deployment.yaml
kubectl delete -f deployment.yaml

8.11. Modul F8: Fundamentals-Abschlussübung

Ziel der Übung:

Du rollst eine einfache Webanwendung aus, veröffentlichst sie intern im Cluster, prüfst Logs und Events und dokumentierst den Rückbau.

Aufgaben:

1. Erstelle einen Namespace.
2. Erstelle ein Deployment mit zwei Replikaten.
3. Erstelle einen ClusterIP-Service.
4. Prüfe Pods, ReplicaSets, Deployment und Service.
5. Teste DNS aus einem Debug-Pod.
6. Ändere das Image und beobachte den Rollout.
7. Führe einen Rollback aus.
8. Lösche alle Ressourcen sauber.

Abnahmekriterien:

• Der Namespace ist eindeutig benannt.
• Das Deployment hat Labels und passende Selektoren.
• Der Service zeigt auf die erwarteten Pods.
• Der Rollout ist nachvollziehbar.
• Der Rückbau ist dokumentiert.

9. Level 2: Intermediate

9.1. Ziel

Du kannst produktionsnahe Workloads konfigurieren, debuggen und betreiben. Der Fokus liegt auf Robustheit, Konfiguration, Ressourcen, Rollouts, Netzwerk, Storage und operativer Fehleranalyse.

9.2. Zielgruppe

• DevOps Engineers
• Entwickler mit Betriebsverantwortung
• System Engineers
• Kubernetes-Anwender mit Grundlagenwissen
• Teams, die Anwendungen produktionsnah in Kubernetes betreiben wollen

9.3. Lernziele

Nach diesem Level kannst du:

• Deployments, StatefulSets, DaemonSets, Jobs und CronJobs unterscheiden.
• ConfigMaps und Secrets korrekt einsetzen.
• Liveness, Readiness und Startup Probes konfigurieren.
• Requests, Limits und QoS-Klassen erklären.
• HPA und PDB einordnen.
• Ingress, Gateway API und DNS-Grundlagen anwenden.
• PV, PVC und StorageClass nutzen.
• Scheduling-Regeln wie Node Affinity, Pod Affinity, Taints und Tolerations verstehen.
• Helm und Kustomize für Paketierung und Variantenmanagement einsetzen.
• typische Fehlerbilder strukturiert analysieren.

9.4. Modul I1: Workload-Controller im Vergleich

Übung:

• Erstelle ein Deployment für eine Webanwendung.
• Erstelle einen Job für eine einmalige Aufgabe.
• Erstelle einen CronJob mit kurzer Testfrequenz.
• Prüfe erzeugte Pods und Logs.
• Lösche die Testressourcen.

Abnahmekriterien:

• Du kannst erklären, warum ein Deployment nicht für jeden Anwendungsfall passt.
• Du erkennst, wann stabile Identität oder geplanter Ablauf wichtiger ist als horizontale Skalierung.

9.5. Modul I2: Konfiguration mit ConfigMaps und Secrets

Inhalte:

• Konfiguration von Images trennen
• ConfigMaps als Dateien oder Environment Variables
• Secrets als Kubernetes-Ressourcen
• Base64 ist keine Verschlüsselung
• Rollout-Verhalten bei Konfigurationsänderungen
• Secret-Zugriff über RBAC begrenzen
• externe Secret-Systeme einordnen

Übung:

kubectl create configmap app-config \
  -n workshop \
  --from-literal=LOG_LEVEL=info \
  --dry-run=client -o yaml > configmap.yaml

kubectl create secret generic app-secret \
  -n workshop \
  --from-literal=API_TOKEN=dummy \
  --dry-run=client -o yaml > secret.yaml

Aufgaben:

1. Binde eine ConfigMap als Environment Variable ein.
2. Binde ein Secret als Volume ein.
3. Prüfe, ob die Anwendung die Werte sieht.
4. Ändere die ConfigMap.
5. Beobachte, ob ein Rollout automatisch passiert.
6. Dokumentiere, wie du einen bewussten Rollout auslöst.

9.6. Modul I3: Probes und Anwendungslebenszyklus

Inhalte:

• Unterschied zwischen Prozess läuft und Anwendung ist bereit
• HTTP-, TCP- und Exec-Probes
• Initial Delay, Timeout, Period und Failure Threshold
• Graceful Shutdown
• terminationGracePeriodSeconds
• PreStop Hook
• Auswirkungen auf Rollouts

Übung:

1. Ergänze eine Readiness Probe.
2. Ergänze eine Liveness Probe.
3. Erzeuge eine fehlerhafte Probe.
4. Beobachte Events und Container-Restarts.
5. Korrigiere die Probe.

Fehlerbild:

Eine zu aggressive Liveness Probe kann eine noch startende Anwendung dauerhaft neu starten. Nutze Startup Probes oder realistische Schwellwerte.

9.7. Modul I4: Ressourcenmanagement

Inhalte:

• CPU Requests
• Memory Requests
• CPU Limits
• Memory Limits
• QoS-Klassen: Guaranteed, Burstable, BestEffort
• OOMKilled
• NodePressure
• LimitRange
• ResourceQuota
• Metrics Server
• Horizontal Pod Autoscaler

Beispiel:

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

Übung:

1. Ergänze Requests und Limits in einem Deployment.
2. Prüfe die resultierende QoS-Klasse.
3. Setze eine ResourceQuota im Namespace.
4. Erzeuge bewusst ein Manifest, das gegen die Quota verstößt.
5. Analysiere die Fehlermeldung.

Abnahmekriterien:

• Du kannst erklären, warum fehlende Requests Scheduling und Kapazitätsplanung verschlechtern.
• Du kannst OOMKilled von CrashLoopBackOff unterscheiden.
• Du verstehst, dass Limits nicht automatisch gute Performance bedeuten.

9.8. Modul I5: Rollouts, Rollbacks und Verfügbarkeit

Inhalte:

• Deployment Strategy
• RollingUpdate
• maxUnavailable
• maxSurge
• Revision History
• Rollout Status
• Rollback
• PodDisruptionBudget
• Readiness als Rollout-Signal

Übung:

kubectl rollout status deployment/web -n workshop
kubectl rollout history deployment/web -n workshop
kubectl set image deployment/web nginx=nginx:1.28 -n workshop
kubectl rollout undo deployment/web -n workshop

Aufgaben:

1. Ändere ein Image auf eine gültige Version.
2. Beobachte den Rolling Update.
3. Ändere ein Image auf eine ungültige Version.
4. Analysiere den hängenden Rollout.
5. Führe einen Rollback aus.
6. Ergänze ein PodDisruptionBudget.

9.9. Modul I6: Netzwerk, DNS, Ingress und Gateway API

Inhalte:

• Pod-Netzwerk
• Service Discovery
• ClusterIP, NodePort, LoadBalancer
• DNS-Namen für Services
• Endpoints und EndpointSlices
• Ingress Controller
• Ingress-Ressourcen
• Gateway API als erweiterbares Routing-Modell
• TLS-Terminierung
• NetworkPolicies

Übung:

1. Prüfe Service und EndpointSlices.
2. Teste DNS aus einem Debug-Pod.
3. Erstelle eine einfache Ingress-Regel oder HTTPRoute, falls die Umgebung es unterstützt.
4. Ergänze eine deny-by-default NetworkPolicy.
5. Erlaube gezielt Traffic von einem bestimmten Pod-Label.

Abnahmekriterien:

• Du kannst erklären, warum ein Service ohne Endpoints nicht funktionieren kann.
• Du kannst DNS-Probleme von Service-Selector-Problemen unterscheiden.
• Du weißt, dass NetworkPolicies nur wirken, wenn das Netzwerk-Plugin sie durchsetzt.

9.10. Modul I7: Storage

Inhalte:

• temporärer Pod-Speicher
• Volumes
• PersistentVolume
• PersistentVolumeClaim
• StorageClass
• dynamische Provisionierung
• Access Modes
• Reclaim Policy
• CSI
• Volume Expansion
• Backup und Restore

Übung:

1. Erstelle einen PVC.
2. Binde ihn in einen Pod oder ein Deployment ein.
3. Schreibe Testdaten.
4. Lösche den Pod.
5. Prüfe, ob die Daten erhalten bleiben.
6. Prüfe PV, PVC, StorageClass und Events.

Abnahmekriterien:

• Du unterscheidest Pod-Lebensdauer von Daten-Lebensdauer.
• Du kannst PVC Pending analysieren.
• Du kannst erklären, warum Stateful Workloads Backup- und Restore-Design brauchen.

9.11. Modul I8: Scheduling

Inhalte:

• Node Selector
• Node Affinity
• Pod Affinity
• Pod Anti-Affinity
• Taints
• Tolerations
• Topology Spread Constraints
• PriorityClass
• Preemption
• Resource Requests als Scheduling-Grundlage

Übung:

1. Weise einem Node ein Label zu, falls erlaubt.
2. Plane einen Pod per Node Selector auf passende Nodes.
3. Verwende eine Toleration für einen tainted Node.
4. Erzeuge bewusst einen Pending Pod.
5. Analysiere Scheduler-Events.

Typische Fehlannahme:

Scheduling-Regeln sind keine Sicherheitsgrenzen. Sie steuern Platzierung, ersetzen aber nicht RBAC, Admission, Pod Security oder Netzwerkisolierung.

9.12. Modul I9: Helm und Kustomize

Inhalte:

• Zweck von Paketierung und Templating
• Helm Chart-Struktur
• Values-Dateien
• Helm Template und Dry Run
• Helm Release Lifecycle
• Kustomize Bases und Overlays
• Patches
• Generatoren
• Validierung in CI/CD

Übung:

helm lint ./chart
helm template demo ./chart -f values.yaml
helm upgrade --install demo ./chart -n workshop --dry-run
kubectl kustomize overlays/dev
kubectl apply -k overlays/dev --dry-run=server

Abnahmekriterien:

• Du kannst erklären, wann Helm sinnvoll ist.
• Du kannst erklären, wann Kustomize einfacher und transparenter ist.
• Du validierst generierte Manifeste vor dem Apply.

9.13. Modul I10: Debugging und Triage

Inhalte:

• kubectl get
• kubectl describe
• Logs aktueller und vorheriger Container
• Events
• Debug-Pods
• Ephemeral Containers
• Port Forwarding
• Service- und DNS-Tests
• Ressourcenstatus
• CrashLoopBackOff
• ImagePullBackOff
• Pending
• OOMKilled
• Forbidden

Übung:

Du bekommst eine bewusst fehlerhafte Anwendung. Du sollst Ursache, Korrektur und Validierung dokumentieren.

Mögliche Fehler:

• falsches Image
• fehlender Secret-Key
• falscher Service Selector
• zu niedrige Memory Limits
• fehlerhafte Readiness Probe
• fehlende RBAC-Berechtigung
• PVC ohne passende StorageClass

Abnahmekriterien:

• Du dokumentierst Symptome und Ursache getrennt.
• Du belegst die Ursache mit Logs, Events oder Statusfeldern.
• Du führst eine minimale Korrektur durch.
• Du prüfst den Erfolg nach der Korrektur.

10. Level 3: Professional

10.1. Ziel

Du kannst Kubernetes-Plattformen planen, betreiben und bewerten. Der Fokus liegt auf Clusterarchitektur, Distributionen, Lifecycle, Netzwerk, Storage, Observability, GitOps, Multi-Tenancy, Kosten und Disaster Recovery.

10.2. Zielgruppe

• Platform Engineers
• Cloud Engineers
• SREs
• Systemarchitekten
• Tech Leads
• erfahrene DevOps Engineers

10.3. Lernziele

Nach diesem Level kannst du:

• Clusterarchitekturen bewerten.
• Distributionen und Betriebsmodelle einordnen.
• Control Plane HA und etcd-Risiken erklären.
• Kubernetes-Versionen und Version-Skew berücksichtigen.
• CNI, CSI und Load Balancing bewerten.
• Observability-Stacks für Kubernetes planen.
• GitOps mit Argo CD oder Flux einordnen.
• Plattform-Add-ons kontrolliert betreiben.
• Multi-Tenancy über Namespaces, RBAC, Quotas und NetworkPolicies gestalten.
• Backup, Restore und Disaster Recovery planen.

10.4. Modul P1: Clusterarchitektur und Betriebsmodell

Inhalte:

• Single-Cluster vs Multi-Cluster
• Multi-Zone und Multi-Region
• Control Plane HA
• Worker Node Pools
• getrennte System- und Workload-Nodepools
• Cluster pro Umgebung
• Cluster pro Mandant
• Shared Cluster mit Namespaces
• Cluster API und Lifecycle-Automatisierung
• Managed Kubernetes vs selbst betriebene Cluster

Entscheidungsfragen:

• Wer betreibt die Control Plane?
• Wer patcht Nodes?
• Wer verantwortet CNI, CSI und Ingress?
• Wie wird der Cluster-Zustand gesichert?
• Wie werden Plattformänderungen getestet?
• Welche Isolation braucht dein Mandantenmodell?

Übung:

Erstelle für ein Beispielszenario eine Cluster-Zielarchitektur. Dokumentiere:

• Betriebsmodell
• Umgebungen
• Node Pools
• Netzwerkannahmen
• Storage-Anforderungen
• Upgrade-Pfad
• Backup- und Restore-Konzept
• Risiken und offene Entscheidungen

10.5. Modul P2: Distributionen und Installationswege

Inhalte:

• kubeadm
• Managed Kubernetes
• RKE2
• k3s
• k0s
• OpenShift
• Talos
• kind und minikube als Lern- und Testumgebungen
• Produktivitäts- und Betriebsunterschiede
• Supportmodell
• Upgradepfad
• Add-on-Verantwortung

Bewertungskriterien:

10.6. Modul P3: kubeadm und Cluster-Lifecycle

Inhalte:

• Zweck von kubeadm
• kubeadm init
• kubeadm join
• Zertifikate
• Bootstrap Tokens
• kubeconfig-Dateien
• Control Plane-Erweiterung
• Worker Join
• Upgrade-Planung
• Version Skew
• Reset und Wiederherstellung
• Grenzen von kubeadm

Übung:

In einer geeigneten Lab-Umgebung:

1. Prüfe Voraussetzungen für Nodes.
2. Initialisiere eine Control Plane.
3. Installiere ein CNI-Plugin.
4. Füge einen Worker Node hinzu.
5. Prüfe Clusterzustand.
6. Simuliere ein Zertifikats- oder Join-Problem.
7. Dokumentiere die Korrektur.

Hinweis:

kubeadm ist ein Bootstrap-Werkzeug. Machine Provisioning, vollautomatisches Add-on-Management und vollständiger Plattformbetrieb müssen über zusätzliche Werkzeuge oder Prozesse geregelt werden.

10.7. Modul P4: etcd und Control Plane-Betrieb

Inhalte:

• etcd als konsistenter Key-Value-Store
• Snapshot und Restore
• Quorum
• Latenz und Storage-Performance
• Zertifikate
• Defragmentierung
• Monitoring
• Backup-Frequenz
• Restore-Test
• Control Plane-Komponenten als statische Pods

Übung:

1. Prüfe Control Plane-Pods.
2. Erstelle einen etcd-Snapshot in einer Lab-Umgebung.
3. Dokumentiere Restore-Schritte.
4. Definiere ein Restore-Testintervall.
5. Formuliere Risiken bei fehlerhaftem etcd-Backup.

Abnahmekriterien:

• Du kannst erklären, warum ein Backup ohne Restore-Test unzureichend ist.
• Du kennst die Auswirkungen eines Quorum-Verlusts.
• Du unterscheidest Anwendungssicherung von Clusterzustandssicherung.

10.8. Modul P5: CNI, Service-Netzwerk und Load Balancing

Inhalte:

• CNI-Aufgaben
• Pod-Netzwerk
• Service-Netzwerk
• kube-proxy
• eBPF-Dataplanes
• ClusterIP-Implementierung
• LoadBalancer-Integration
• Ingress Controller
• Gateway Controller
• NetworkPolicy-Unterstützung
• DNS und CoreDNS
• Service Mesh als optionales Zusatzmodell

Übung:

Analysiere den Netzwerkpfad einer Anfrage:

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

Dokumentiere je Hop:

• beteiligte Kubernetes-Ressource
• beteiligte Plattformkomponente
• mögliche Fehlerquelle
• passende Diagnosebefehle

10.9. Modul P6: CSI und Storage-Betrieb

Inhalte:

• CSI-Treiber
• StorageClasses
• dynamische Provisionierung
• Reclaim Policies
• Volume Binding Mode
• Snapshots
• Volume Expansion
• Performanceklassen
• Backup und Restore für Stateful Workloads
• Datenresidenz
• Verschlüsselung

Übung:

Erstelle ein Storage-Design für drei Workload-Typen:

1. zustandslose API
2. Datenbank
3. Message Broker

Bewerte jeweils:

• Persistenzbedarf
• Backup-Ziel
• Restore-Zeit
• Performancebedarf
• Verfügbarkeitsanforderung
• Risiken bei Node-Ausfall

10.10. Modul P7: Observability

Inhalte:

• Metriken
• Logs
• Traces
• Events
• Kubernetes-Objektstatus
• Prometheus
• Grafana
• Loki
• Tempo
• OpenTelemetry
• Alerting
• SLOs und SLIs
• Golden Signals
• Runbooks

Übung:

Entwirf ein Observability-Modell für eine Beispielanwendung:

• Welche Metriken brauchst du?
• Welche Logs brauchst du?
• Welche Traces helfen bei Fehleranalyse?
• Welche Kubernetes-Events sind relevant?
• Welche Alerts sind sinnvoll?
• Welche Alerts wären nur Rauschen?

Abnahmekriterien:

• Du trennst Infrastruktur-, Plattform- und Anwendungssignale.
• Du definierst Alerts mit Handlungspfad.
• Du vermeidest reine Symptommetriken ohne Kontext.

10.11. Modul P8: GitOps und Delivery

Inhalte:

• Git als gewünschter Zustand
• Pull-basiertes Deployment
• Argo CD
• Flux
• Drift Detection
• Sync Waves
• Health Checks
• Secrets im GitOps-Modell
• Umgebungsvarianten
• Promotion von Releases
• Rollback über Git
• Policy Gates in CI/CD

Übung:

1. Strukturiere ein GitOps-Repository für Dev, Stage und Prod.
2. Definiere, welche Dateien von Teams gepflegt werden.
3. Definiere, welche Dateien Plattformstandard sind.
4. Lege Validierungsschritte fest.
5. Beschreibe den Rollback-Pfad.

10.12. Modul P9: Plattform-Add-ons

Typische Add-ons:

• Metrics Server
• Ingress Controller
• Gateway Controller
• cert-manager
• ExternalDNS
• Cluster Autoscaler
• Karpenter oder alternatives Node-Autoscaling
• CNI-Plugin
• CSI-Treiber
• Observability-Komponenten
• Policy Engines
• External Secrets Operator
• Argo CD oder Flux

Bewertung je Add-on:

10.13. Modul P10: Multi-Tenancy

Inhalte:

• Namespace-Strategie
• RBAC pro Team
• ResourceQuota
• LimitRange
• NetworkPolicies
• Pod Security Admission
• getrennte Node Pools
• RuntimeClass
• Admission Policies
• Secret-Isolation
• Logging- und Monitoring-Isolation
• Kostenstellen und Labels

Übung:

Entwirf ein Mandantenmodell für drei Teams:

• Team A: interne API
• Team B: Batch Workloads
• Team C: sensible Datenverarbeitung

Dokumentiere:

• Namespaces
• Rollen und Berechtigungen
• Quotas
• Netzwerkregeln
• Pod Security-Level
• Ausnahmen und Genehmigungsprozess

10.14. Modul P11: Kosten und Kapazität

Inhalte:

• Requests als Planungsgrundlage
• Overcommitment
• Idle Capacity
• Namespace-Kosten
• Labels für Kostenstellen
• HPA, VPA und Cluster Autoscaler
• Spot- oder Preemptible Nodes
• Rechte und Risiken von Autoscaling
• Kostenmetriken

Übung:

Analysiere einen Namespace:

• Summe der CPU Requests
• Summe der Memory Requests
• tatsächliche Nutzung
• nicht genutzte Kapazität
• Workloads ohne Requests
• mögliche Optimierungen

10.15. Modul P12: Backup, Restore und Disaster Recovery

Inhalte:

• etcd-Backup
• Anwendungsdaten-Backup
• Kubernetes-Manifeste
• Secrets
• PV-Snapshots
• Restore-Reihenfolge
• RPO und RTO
• Cluster-Neuaufbau
• GitOps-Rehydration
• Disaster-Recovery-Tests

Übung:

Erstelle ein DR-Konzept für eine Anwendung mit Datenbank:

• Was wird gesichert?
• Wie oft wird gesichert?
• Wo wird gesichert?
• Wer darf wiederherstellen?
• Wie wird ein Restore getestet?
• Welche Reihenfolge gilt beim Wiederanlauf?

11. Level 4: Advanced und Security

11.1. Ziel

Du kannst Kubernetes härten, Risiken bewerten, Angriffe erkennen und Incidents strukturiert bearbeiten. Der Fokus liegt auf API-Zugriff, RBAC, Admission, Pod Security, Netzwerksegmentierung, Secret-Schutz, Image Supply Chain, Runtime Detection und Forensik.

11.2. Zielgruppe

• Security Engineers
• DevSecOps Engineers
• Platform Engineers
• SREs
• Incident-Response-Teams
• Architekten mit Sicherheitsverantwortung

11.3. Lernziele

Nach diesem Level kannst du:

• ein Kubernetes-Bedrohungsmodell erstellen.
• Authentifizierung, Autorisierung und Admission unterscheiden.
• RBAC Least Privilege umsetzen und prüfen.
• ServiceAccounts und Tokens sicher gestalten.
• Pod Security Standards anwenden.
• SecurityContexts bewerten.
• Capabilities, seccomp, AppArmor und SELinux einordnen.
• NetworkPolicies und CNI-spezifische Policies nutzen.
• Secrets sicherer verwalten.
• Image- und Supply-Chain-Risiken reduzieren.
• Runtime Security und Incident Response strukturieren.

11.4. Modul S1: Kubernetes Threat Modeling

Inhalte:

• Assets im Cluster
• Angriffsflächen
• API Server als zentrales Ziel
• ServiceAccount-Tokens
• Secrets
• Container Escape-Risiken
• privilegierte Pods
• laterale Bewegung
• Supply-Chain-Risiken
• unsichere Admission-Ausnahmen
• Cluster-Admin-Wildwuchs

Übung:

Erstelle ein Bedrohungsmodell für eine Beispielplattform. Dokumentiere:

• schützenswerte Assets
• mögliche Angreifer
• Einstiegspunkte
• Eskalationspfade
• technische Kontrollen
• Detektionssignale
• offene Risiken

11.5. Modul S2: Authentifizierung, Autorisierung und Admission

Inhalte:

• Authentifizierung: Wer bist du?
• Autorisierung: Was darfst du?
• Admission: Ist diese Änderung erlaubt oder wird sie mutiert?
• User, Groups und ServiceAccounts
• RBAC
• Webhook Authorization
• Mutating Admission Webhooks
• Validating Admission Webhooks
• ValidatingAdmissionPolicy
• Audit Logs

Übung:

1. Prüfe deine Rechte mit kubectl auth can-i.
2. Erzeuge eine Rolle mit minimalen Rechten.
3. Binde sie an einen ServiceAccount.
4. Teste erlaubte und verbotene Aktionen.
5. Dokumentiere erwartete Forbidden-Fehler.

11.6. Modul S3: RBAC Least Privilege

Inhalte:

• Role
• ClusterRole
• RoleBinding
• ClusterRoleBinding
• Verben
• Ressourcen
• API-Gruppen
• Namespaced vs clusterweit
• Aggregated ClusterRoles
• Impersonation
• gefährliche Rechte wie *, create pods, bind, escalate, impersonate

Übung:

Erstelle ein RBAC-Modell für eine Anwendung:

• Deployment darf ConfigMaps lesen.
• Deployment darf keine Secrets auflisten.
• Operator darf nur Ressourcen im eigenen Namespace verwalten.
• Entwickler dürfen Logs lesen, aber keine ClusterRoles ändern.

Abnahmekriterien:

• Du vermeidest pauschale ClusterRoleBindings.
• Du kannst Rechte mit kubectl auth can-i --as prüfen.
• Du dokumentierst, warum ein Recht benötigt wird.

11.7. Modul S4: ServiceAccounts und Tokens

Inhalte:

• Default ServiceAccount
• automatische Token-Projektion
• Bound ServiceAccount Tokens
• Token-Lebensdauer
• Audience
• Workload Identity-Modelle
• Zugriff aus Pods
• Minimierung von API-Zugriff

Übung:

1. Erstelle einen eigenen ServiceAccount.
2. Weise ihn einem Deployment zu.
3. Entferne unnötige API-Rechte.
4. Prüfe Token-Mounting.
5. Deaktiviere automatisches Token-Mounting, wenn es nicht gebraucht wird.

11.8. Modul S5: Pod Security Standards und Admission

Pod Security Standards definieren drei Policy-Level:

Inhalte:

• Pod Security Admission
• Namespace-Labels für enforce, audit und warn
• Baseline vs Restricted
• Ausnahmen
• Migration von alten Workloads
• Abgrenzung zu früherer PodSecurityPolicy
• Kombination mit Policy Engines

Übung:

1. Aktiviere Pod Security Admission über Namespace-Labels in einer Lab-Umgebung.
2. Erzeuge einen Pod, der gegen Restricted verstößt.
3. Analysiere die Warnung oder Ablehnung.
4. Härte den Pod schrittweise.

11.9. Modul S6: SecurityContext und Container-Härtung

Inhalte:

• runAsNonRoot
• runAsUser
• runAsGroup
• fsGroup
• readOnlyRootFilesystem
• allowPrivilegeEscalation
• Linux Capabilities
• seccomp
• AppArmor
• SELinux
• privileged Container
• hostNetwork, hostPID und hostIPC
• hostPath-Risiken

Beispiel:

securityContext:
  runAsNonRoot: true
  runAsUser: 1000
  allowPrivilegeEscalation: false
  readOnlyRootFilesystem: true
  seccompProfile:
    type: RuntimeDefault
  capabilities:
    drop:
      - ALL

Übung:

1. Prüfe einen unsicheren Pod.
2. Ergänze SecurityContext-Einstellungen.
3. Entferne unnötige Capabilities.
4. Prüfe Kompatibilität mit der Anwendung.
5. Dokumentiere notwendige Ausnahmen.

11.10. Modul S7: Netzwerkisolation

Inhalte:

• Default allow vs deny-by-default
• Ingress- und Egress-Regeln
• Namespace Selector
• Pod Selector
• IPBlock
• DNS-Ausnahmen
• CNI-spezifische Erweiterungen
• Cilium Policies
• Layer-7-Policies
• Service Mesh und mTLS

Übung:

1. Erstelle eine deny-by-default Policy im Namespace.
2. Erlaube Traffic vom Frontend zum Backend.
3. Erlaube DNS-Traffic zu CoreDNS.
4. Teste erlaubte und geblockte Verbindungen.
5. Dokumentiere erwartetes Verhalten.

Abnahmekriterien:

• Du prüfst, ob dein CNI NetworkPolicies durchsetzt.
• Du testest Regeln praktisch.
• Du berücksichtigst DNS und externe Abhängigkeiten.

11.11. Modul S8: Secrets Security

Inhalte:

• Kubernetes Secrets
• Base64 und Verschlüsselung
• Encryption at Rest
• RBAC auf Secrets
• Secret-Verteilung
• externe Secret-Systeme
• External Secrets Operator
• SOPS
• Vault
• Cloud Secret Manager
• Rotation
• Auditierung
• versehentliches Logging

Übung:

Erarbeite ein Secret-Modell:

• Welche Secrets liegen in Kubernetes?
• Welche Secrets bleiben extern?
• Wer darf Secrets lesen?
• Wie werden Secrets rotiert?
• Wie wird verhindert, dass Secrets in Git oder Logs landen?

11.12. Modul S9: Image Security und Supply Chain

Inhalte:

• Image Tags vs Digests
• minimale Base Images
• Vulnerability Scanning
• SBOM
• Signaturen
• Cosign
• SLSA-Grundidee
• Admission Policies für Images
• private Registries
• ImagePullSecrets
• Provenance

Übung:

1. Prüfe ein Image auf Tag-Strategie.
2. Ersetze ein unspezifisches Tag durch einen Digest.
3. Definiere eine Policy für erlaubte Registries.
4. Beschreibe, wie Signaturprüfung in Admission integriert wird.

11.13. Modul S10: Runtime Security

Inhalte:

• verdächtige Prozessstarts
• Shell in Containern
• Schreibzugriffe auf Systempfade
• Netzwerkverbindungen
• Zugriff auf ServiceAccount-Tokens
• Falco
• Tetragon
• eBPF-basierte Signale
• RuntimeClass
• Sandboxed Runtimes

Übung:

1. Definiere relevante Runtime-Signale.
2. Ordne Signale realen Angriffspfaden zu.
3. Entwirf Alerts mit Handlungspfad.
4. Unterscheide Fehlalarm und echter Incident.

11.14. Modul S11: Incident Response und Forensik

Inhalte:

• Incident-Klassifizierung
• Eindämmung
• Beweissicherung
• Pod- und Node-Zustand sichern
• Logs, Events und Audit Logs
• verdächtige RBAC-Änderungen
• verdächtige Images
• verdächtige Secrets-Zugriffe
• laterale Bewegung
• Recovery und Lessons Learned

Übung:

Du erhältst ein kompromittiertes Lab-Szenario. Bearbeite:

1. Erste Triage
2. betroffene Ressourcen identifizieren
3. Ausbreitung prüfen
4. Eindämmung planen
5. Beweise sichern
6. Ursache ableiten
7. Korrekturmaßnahmen definieren
8. Nachbereitung dokumentieren

Abnahmekriterien:

• Du löschst Beweise nicht vorschnell.
• Du trennst Eindämmung von Ursachenanalyse.
• Du dokumentierst Entscheidungen und Annahmen.

12. Praxisumgebung

12.1. Varianten

12.2. Mindestanforderungen an den Lab-Cluster

Für Fundamentals:

• ein funktionierender Cluster
• ein eigener Namespace pro Teilnehmer oder Team
• Rechte für Pods, Deployments, Services, ConfigMaps und Secrets
• Zugriff auf Logs und Events

Für Intermediate:

• Metrics Server
• Ingress Controller oder Gateway Controller
• StorageClass
• Möglichkeit für NetworkPolicies
• optional Helm und Kustomize

Für Professional:

• Zugriff auf Cluster-Add-ons
• Beobachtbarkeitssystem oder Demo-Stack
• Möglichkeit, Nodes oder Node Pools zu betrachten
• optional kubeadm-Lab oder Managed-Kubernetes-Sandbox

Für Advanced und Security:

• RBAC-Testumgebung
• Pod Security Admission
• NetworkPolicy-fähiges CNI
• Test-Registry oder Beispielimages
• optional Falco, Tetragon, Cilium oder Policy Engine

12.3. Namenskonventionen

Empfohlene Konvention:

namespace: workshop-<name>
app:       <team>-<app>
labels:    app.kubernetes.io/name, app.kubernetes.io/part-of, app.kubernetes.io/component

Beispiel:

metadata:
  labels:
    app.kubernetes.io/name: web
    app.kubernetes.io/part-of: kubernetes-workshop
    app.kubernetes.io/component: frontend
    training.kubernetes.io/owner: team-a

12.4. Sicherheitsregeln für Labs

• Verwende keine echten produktiven Secrets.
• Nutze dedizierte Namespaces.
• Lösche Lab-Ressourcen nach der Übung.
• Nutze keine Cluster-Admin-Rechte, wenn Namespace-Rechte reichen.
• Dokumentiere absichtliche Policy-Ausnahmen.
• Prüfe vor destruktiven Befehlen den aktuellen Kontext.

13. Workshop-Labs

13.1. Lab 0: Setup und Orientierung

Ziel:

Du stellst sicher, dass dein Zugriff funktioniert und du im richtigen Cluster arbeitest.

Aufgaben:

1. Prüfe die lokale kubectl-Version.
2. Prüfe den aktuellen Kontext.
3. Zeige Nodes und Namespaces an.
4. Erstelle deinen Workshop-Namespace.
5. Prüfe deine Berechtigungen.

Kommandos:

kubectl version --client
kubectl config current-context
kubectl get nodes
kubectl create namespace workshop-<name>
kubectl auth can-i create deployments -n workshop-<name>

Ergebnis:

Du kannst sicher sagen, in welchem Cluster und Namespace du arbeitest.

13.2. Lab 1: Erste Anwendung deployen

Ziel:

Du deployst eine einfache Webanwendung mit Deployment und Service.

Aufgaben:

1. Erstelle ein Deployment.
2. Skaliere auf zwei Replikate.
3. Erstelle einen ClusterIP-Service.
4. Prüfe Pods, ReplicaSets und Endpoints.
5. Teste die Anwendung aus einem Debug-Pod.

Ergebnis:

Die Anwendung ist intern im Cluster erreichbar.

13.3. Lab 2: Rollout und Rollback

Ziel:

Du steuerst eine Änderung kontrolliert und führst bei Fehlern einen Rollback aus.

Aufgaben:

1. Ändere das Image auf eine neue Version.
2. Beobachte den Rollout.
3. Setze ein ungültiges Image.
4. Analysiere den Fehler.
5. Führe einen Rollback aus.

Ergebnis:

Du kannst eine fehlerhafte Änderung erkennen und zurückdrehen.

13.4. Lab 3: Konfiguration und Secrets

Ziel:

Du trennst Anwendungscode von Laufzeitkonfiguration.

Aufgaben:

1. Erstelle eine ConfigMap.
2. Erstelle ein Secret mit Dummy-Werten.
3. Binde beide in ein Deployment ein.
4. Prüfe Werte im Pod.
5. Ändere die Konfiguration und löse einen Rollout aus.

Ergebnis:

Die Anwendung nutzt externe Konfiguration und keine fest eingebauten Werte.

13.5. Lab 4: Probes und Ressourcen

Ziel:

Du machst eine Anwendung rolloutsicherer und planbarer.

Aufgaben:

1. Ergänze Readiness Probe.
2. Ergänze Liveness Probe.
3. Ergänze Startup Probe, falls Startzeit relevant ist.
4. Setze Requests und Limits.
5. Prüfe Events und QoS-Klasse.

Ergebnis:

Der Workload ist besser planbar und gibt Kubernetes sinnvolle Gesundheitssignale.

13.6. Lab 5: Ingress, Gateway oder externer Zugriff

Ziel:

Du machst eine Anwendung über HTTP erreichbar.

Aufgaben:

1. Prüfe vorhandenen Ingress- oder Gateway-Controller.
2. Erstelle eine Routing-Ressource.
3. Konfiguriere Hostname oder Pfad.
4. Prüfe TLS-Annahmen.
5. Teste den Zugriff.

Ergebnis:

Du verstehst den Weg von externem Traffic zur Anwendung.

13.7. Lab 6: Storage

Ziel:

Du verwendest persistente Daten in Kubernetes.

Aufgaben:

1. Prüfe StorageClasses.
2. Erstelle einen PVC.
3. Binde den PVC in einen Pod ein.
4. Schreibe Daten.
5. Lösche und ersetze den Pod.
6. Prüfe die Daten erneut.

Ergebnis:

Du verstehst den Unterschied zwischen Pod-Lebensdauer und Daten-Lebensdauer.

13.8. Lab 7: RBAC

Ziel:

Du erstellst minimale Rechte für einen ServiceAccount.

Aufgaben:

1. Erstelle einen ServiceAccount.
2. Erstelle eine Role mit minimalen Rechten.
3. Erstelle eine RoleBinding.
4. Prüfe Rechte mit kubectl auth can-i.
5. Teste verbotene Aktionen.

Ergebnis:

Du kannst Least Privilege praktisch umsetzen.

13.9. Lab 8: NetworkPolicies

Ziel:

Du isolierst Workloads im Namespace.

Aufgaben:

1. Erstelle eine deny-by-default Policy.
2. Erlaube gezielt Frontend-zu-Backend-Traffic.
3. Erlaube DNS-Traffic.
4. Teste erlaubte und geblockte Verbindungen.
5. Dokumentiere Annahmen zum CNI.

Ergebnis:

Du kannst Netzwerkkommunikation im Cluster kontrollieren.

13.10. Lab 9: Fehleranalyse

Ziel:

Du analysierst mehrere typische Fehlerbilder.

Fehlerfälle:

• Pod Pending
• CrashLoopBackOff
• ImagePullBackOff
• Service ohne Endpoints
• DNS-Auflösung schlägt fehl
• PVC Pending
• RBAC Forbidden
• OOMKilled
• hängender Rollout

Vorgehen:

1. Symptom beschreiben.
2. relevante Ressourcen anzeigen.
3. Events prüfen.
4. Logs prüfen.
5. Ursache ableiten.
6. minimale Korrektur durchführen.
7. Erfolg validieren.

Ergebnis:

Du kannst Fehler systematisch bearbeiten und dokumentieren.

13.11. Lab 10: Plattform-Blueprint

Ziel:

Du entwirfst eine produktionsnahe Kubernetes-Plattform.

Aufgaben:

1. Wähle ein Betriebsmodell.
2. Definiere Cluster- und Namespace-Struktur.
3. Definiere Add-ons.
4. Definiere Observability.
5. Definiere Security-Baseline.
6. Definiere Backup und Restore.
7. Definiere Upgrade- und Rollback-Prozess.

Ergebnis:

Du kannst Architekturentscheidungen begründen.

13.12. Lab 11: Security Review

Ziel:

Du prüfst eine Anwendung auf Kubernetes-Sicherheitsrisiken.

Prüfpunkte:

• ServiceAccount
• RBAC
• Secrets
• SecurityContext
• Pod Security-Level
• NetworkPolicies
• Image-Quelle
• Ressourcenangaben
• Host-Zugriffe
• Privilegien
• Logs und sensible Daten

Ergebnis:

Du erstellst einen Security-Befund mit Priorität, Risiko und Korrekturvorschlag.

14. Abschlussprojekte

14.1. Projekt A: Produktionsnaher App-Rollout

Zielgruppe:

• Entwickler
• DevOps Engineers
• Intermediate-Teilnehmer

Aufgabe:

Du erhältst eine einfache Anwendung und sollst sie produktionsnah in Kubernetes ausrollen.

Mindestanforderungen:

• Namespace
• Deployment mit mindestens zwei Replikaten
• Service
• ConfigMap
• Secret mit Dummy-Werten
• Readiness und Liveness Probe
• Requests und Limits
• Rollout- und Rollback-Dokumentation
• Debugging-Nachweise
• Rückbauanleitung

Erweiterungen:

• Ingress oder Gateway API
• HPA
• PDB
• NetworkPolicy
• Helm oder Kustomize

Bewertung:

• Funktionalität
• Robustheit
• Nachvollziehbarkeit
• Betriebsreife
• Security-Baseline

14.2. Projekt B: Plattform-Design

Zielgruppe:

• Platform Engineers
• SREs
• Tech Leads
• Professional-Teilnehmer

Aufgabe:

Du entwirfst eine Kubernetes-Plattform für mehrere Teams.

Mindestanforderungen:

• Clusterstrategie
• Namespace- und Mandantenmodell
• RBAC-Design
• Quotas und LimitRanges
• Netzwerkmodell
• Ingress- oder Gateway-Strategie
• Storage-Strategie
• Observability-Konzept
• GitOps-Konzept
• Backup- und DR-Konzept
• Upgrade-Strategie
• Add-on-Verantwortlichkeiten

Bewertung:

• klare Verantwortungsgrenzen
• realistische Betriebsannahmen
• Upgradefähigkeit
• Sicherheitsniveau
• Skalierbarkeit
• Verständlichkeit

14.3. Projekt C: Kubernetes Security Assessment

Zielgruppe:

• Security Engineers
• DevSecOps
• Advanced-Teilnehmer

Aufgabe:

Du prüfst ein Beispielcluster- oder Beispielnamespace-Setup auf Sicherheitsrisiken.

Mindestanforderungen:

• RBAC-Review
• ServiceAccount-Review
• Pod Security-Review
• SecurityContext-Review
• Secret-Review
• NetworkPolicy-Review
• Image- und Registry-Review
• Admission-Review
• Runtime-Signal-Modell
• Incident-Response-Kurzplan

Bewertung:

• Risikobewertung
• Nachvollziehbare Evidenz
• Priorisierung
• realistische Korrekturvorschläge
• keine unnötig destruktiven Maßnahmen

15. Bewertungsraster

15.1. Allgemeines Raster

15.2. Bestehensgrenze

Eine Übung gilt als bestanden, wenn:

• die Funktion nachweisbar gegeben ist,
• die wichtigsten Ressourcen korrekt benannt und erklärt werden,
• mindestens ein Validierungsschritt dokumentiert ist,
• kein echtes Secret verwendet wurde,
• ein Rückbaupfad vorhanden ist.

15.3. Kriterien für sehr gute Lösungen

Eine Lösung ist sehr gut, wenn sie:

• deklarativ und reproduzierbar ist,
• klare Labels und Namenskonventionen nutzt,
• Ressourcenangaben enthält,
• Health Checks sinnvoll setzt,
• Rollout und Rollback berücksichtigt,
• SecurityContext und ServiceAccount bewusst setzt,
• Netzwerkzugriffe begrenzt,
• relevante Fehlerbilder dokumentiert,
• mit kubectl diff oder Server-side Dry Run validiert wurde,
• keine unnötigen Clusterrechte benötigt.

16. Agenda-Varianten

16.1. Kompaktworkshop: 1 Tag

Ziel:

Du bekommst einen praxisnahen Einstieg und kannst einfache Workloads deployen.

Nicht enthalten:

• tiefer Plattformbetrieb
• kubeadm-Lifecycle
• vollständige Security-Härtung
• Multi-Tenancy-Design

16.2. Standardworkshop: 2 Tage

Ziel:

Du kannst produktionsnahe Workloads erstellen und typische Fehler analysieren.

Tag 1

Tag 2

16.3. Professional-Workshop: 3 Tage

Ziel:

Du kannst Workloads betreiben und Plattformentscheidungen treffen.

Tag 1

• Kubernetes-Grundlagen auffrischen
• Workload-Controller vertiefen
• Ressourcen, Probes, Rollouts
• Debugging-Labs

Tag 2

• Netzwerk, Ingress, Gateway API
• Storage und CSI
• Scheduling
• Helm, Kustomize und GitOps

Tag 3

• Clusterarchitektur
• Distributionen und kubeadm
• Observability
• Multi-Tenancy
• Backup und DR
• Plattform-Blueprint

16.4. Security-Workshop: 2 Tage

Ziel:

Du kannst Kubernetes-spezifische Sicherheitsrisiken erkennen und reduzieren.

Tag 1

Tag 2

16.5. Vollständige Enablement-Reihe: 6 bis 8 Tage

Ziel:

Du baust nachhaltige Kubernetes-Kompetenz im Team auf.

Empfohlene Struktur:

1. Tag: Fundamentals
2. Tag: Workloads und Konfiguration
3. Tag: Netzwerk, Storage und Scheduling
4. Tag: Debugging, Helm, Kustomize und Delivery
5. Tag: Plattformarchitektur und kubeadm
6. Tag: Observability, GitOps, Multi-Tenancy und DR
7. Tag: Security-Härtung
8. Tag: Incident Response, Abschlussprojekt und Review

17. Trainerleitfaden

17.1. Vorbereitung

Vor dem Workshop solltest du:

• die Clusterumgebung testen,
• Namespaces oder Zugänge vorbereiten,
• Berechtigungen prüfen,
• Beispielmanifeste validieren,
• absichtliche Fehlerfälle vorbereiten,
• Rückbaukommandos dokumentieren,
• Provider-spezifische Unterschiede notieren,
• Netzwerk- und Storage-Funktionen testen,
• Ingress oder Gateway API nur einplanen, wenn die Umgebung es unterstützt.

17.2. Durchführung

Gute Durchführung folgt diesem Muster:

1. Konzept knapp erklären.
2. Ressource im Manifest zeigen.
3. Manifest anwenden.
4. Status prüfen.
5. Fehler provozieren.
6. Fehler analysieren.
7. Korrektur durchführen.
8. Ergebnis dokumentieren.

17.3. Umgang mit gemischten Gruppen

In gemischten Gruppen solltest du:

• Einsteiger über klare Begriffe abholen,
• Fortgeschrittene über Fehlerfälle einbinden,
• Plattformthemen als optionale Vertiefung kennzeichnen,
• Security-Fragen früh aufnehmen, aber strukturiert einordnen,
• Labs in Basis- und Bonusaufgaben teilen.

17.4. Typische Zeitfallen

• lokale Setup-Probleme
• fehlende Clusterrechte
• nicht vorhandener Ingress Controller
• fehlende StorageClass
• NetworkPolicies ohne unterstützendes CNI
• Containerimages, die nicht pullbar sind
• DNS- oder Proxy-Probleme in Unternehmensnetzwerken
• zu große Themenblöcke ohne Übungen

17.5. Empfohlene Abgrenzung im Workshop

Kubernetes sollte nicht isoliert von angrenzenden Systemen betrachtet werden. Trotzdem muss klar bleiben, welches Werkzeug welche Verantwortung trägt.

18. Lernkontrollen und Reflexionsfragen

18.1. Fundamentals

• Was ist der Unterschied zwischen Pod und Deployment?
• Warum sind Pods kurzlebig?
• Wie findet ein Service seine Pods?
• Was ist der Unterschied zwischen spec und status?
• Warum ist kubectl describe bei Fehleranalyse oft wertvoller als nur kubectl get?
• Wie erkennst du, ob ein Service Endpoints hat?
• Warum sollte ein Manifest versioniert werden?

18.2. Intermediate

• Wann brauchst du eine Startup Probe?
• Wie unterscheiden sich Readiness und Liveness?
• Was passiert, wenn ein Container sein Memory Limit überschreitet?
• Warum sind Requests für Scheduling wichtig?
• Warum löst eine ConfigMap-Änderung nicht immer automatisch einen Rollout aus?
• Wie analysierst du einen Pending Pod?
• Wie unterscheidest du DNS-, Service- und Endpoint-Probleme?
• Welche Risiken entstehen durch fehlende NetworkPolicies?

18.3. Professional

• Welche Verantwortung bleibt bei dir, wenn du Managed Kubernetes nutzt?
• Warum ist etcd besonders kritisch?
• Was bedeutet Version Skew?
• Wie planst du einen sicheren Cluster-Upgrade?
• Welche Add-ons sind kritisch für den Plattformbetrieb?
• Wie unterscheidest du Cluster-Backup und Anwendungsdaten-Backup?
• Wann ist Multi-Cluster sinnvoll?
• Welche Signale gehören in ein gutes Kubernetes-Observability-Modell?

18.4. Advanced und Security

• Warum ist ClusterRoleBinding mit cluster-admin riskant?
• Welche Rechte ermöglichen Privilege Escalation?
• Was leisten Pod Security Standards und was leisten sie nicht?
• Warum ist Base64 keine Verschlüsselung?
• Welche Risiken entstehen durch hostPath?
• Wie testest du NetworkPolicies?
• Welche Indikatoren sprechen für einen kompromittierten Pod?
• Was musst du sichern, bevor du einen verdächtigen Pod löschst?

19. Häufige Fehlannahmen

20. Empfohlene Dauer

20.1. Dauer nach Tiefe

21. Mapping zu Praxisrollen

21.1. Entwickler

Pflichtthemen:

• Namespaces
• Pods
• Deployments
• Services
• ConfigMaps
• Secrets-Grundlagen
• Probes
• Ressourcenangaben
• Logs und Events
• Rollout und Rollback

Optionale Themen:

• HPA
• Ingress oder Gateway API
• Helm oder Kustomize
• NetworkPolicies

21.2. DevOps Engineers

Pflichtthemen:

• alle Entwicklerthemen
• Workload-Controller
• Storage
• Scheduling
• Helm und Kustomize
• CI/CD-Validierung
• Debugging
• RBAC-Grundlagen
• PDB und HPA

Optionale Themen:

• GitOps
• Observability
• kubeadm
• SecurityContext

21.3. Platform Engineers

Pflichtthemen:

• Clusterarchitektur
• Distributionen
• CNI und CSI
• Ingress und Gateway API
• Observability
• GitOps
• Multi-Tenancy
• Add-ons
• Backup und DR
• Upgrade-Strategie
• Kostensteuerung

Optionale Themen:

• Runtime Security
• Service Mesh
• Cluster API
• Policy Engines

21.4. Security Engineers

Pflichtthemen:

• Threat Modeling
• RBAC
• ServiceAccounts
• Pod Security Standards
• Admission Control
• SecurityContext
• NetworkPolicies
• Secrets Security
• Image Security
• Runtime Detection
• Incident Response

Optionale Themen:

• Service Mesh Security
• eBPF-basierte Security
• Forensik auf Node-Ebene
• Compliance-Automatisierung

22. Weiterführende Themen

Diese Themen eignen sich für Vertiefungsmodule oder separate Workshops:

• Kubernetes API intern
• Controller-Entwicklung
• Operator SDK
• CustomResourceDefinitions
• ValidatingAdmissionPolicy
• Policy-as-Code mit Kyverno, Gatekeeper oder Validating Admission Policies
• Service Mesh mit Istio, Linkerd oder Consul
• eBPF und Cilium
• Cluster API
• Multi-Cluster-GitOps
• Progressive Delivery mit Argo Rollouts oder Flagger
• Canary, Blue-Green und A/B-Deployments
• Workload Identity
• Confidential Containers
• Sandbox-Runtimes
• GPU- und Accelerator-Scheduling
• Dynamic Resource Allocation
• Backup-Lösungen wie Velero
• Kubernetes-Kostenmanagement
• FinOps für Plattformteams
• SLO Engineering auf Kubernetes
• Chaos Engineering

22.1. Vertiefungsmodul: Controller und Operatoren

Lernziele:

• Du verstehst, wie Controller gewünschte Zustände abgleichen.
• Du kannst CRDs als API-Erweiterung einordnen.
• Du erkennst Risiken durch schlecht betriebene Operatoren.

Inhalte:

• Reconciliation Loop
• Owner References
• Finalizers
• Conditions
• CRDs
• Controller Runtime
• Operator-Pattern
• Upgrade- und Backup-Fragen bei CRDs

22.2. Vertiefungsmodul: Policy-as-Code

Lernziele:

• Du kannst technische Plattformregeln automatisiert prüfen.
• Du verstehst Unterschied zwischen Validierung, Mutation und Audit.

Inhalte:

• Admission Control
• ValidatingAdmissionPolicy
• Kyverno
• Gatekeeper
• Policy-Tests
• Ausnahmeprozesse
• CI/CD-Policy-Prüfung

22.3. Vertiefungsmodul: Progressive Delivery

Lernziele:

• Du kannst Risiken bei Releases reduzieren.
• Du verstehst Rollout-Strategien jenseits des Standard-Rolling-Updates.

Inhalte:

• Canary
• Blue-Green
• Feature Flags
• Traffic Splitting
• Metrikbasierte Promotion
• automatische Rollbacks
• Argo Rollouts
• Flagger

22.4. Vertiefungsmodul: Kubernetes für regulierte Umgebungen

Lernziele:

• Du kannst Audit-, Compliance- und Nachvollziehbarkeitsanforderungen in Kubernetes übersetzen.

Inhalte:

• Audit Logs
• RBAC-Nachweise
• Policy Reports
• Image Provenance
• Secret-Rotation
• Verschlüsselung
• Mandantentrennung
• Backup-Nachweise
• Change Management

23. Quellen und Referenzen

Die folgenden Referenzen eignen sich zur fachlichen Vertiefung und zur Aktualisierung des Curriculums:

• Kubernetes Dokumentation: https://kubernetes.io/docs/
• Kubernetes Konzepte: https://kubernetes.io/docs/concepts/
• Kubernetes Komponenten: https://kubernetes.io/docs/concepts/overview/components/
• Kubernetes API-Konzepte: https://kubernetes.io/docs/reference/using-api/api-concepts/
• Pods: https://kubernetes.io/docs/concepts/workloads/pods/
• Deployments: https://kubernetes.io/docs/concepts/workloads/controllers/deployment/
• Services: https://kubernetes.io/docs/concepts/services-networking/service/
• Gateway API: https://kubernetes.io/docs/concepts/services-networking/gateway/
• NetworkPolicies: https://kubernetes.io/docs/concepts/services-networking/network-policies/
• PersistentVolumes: https://kubernetes.io/docs/concepts/storage/persistent-volumes/
• Ressourcenmanagement: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/
• Probes: https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/
• RBAC: https://kubernetes.io/docs/reference/access-authn-authz/rbac/
• Pod Security Standards: https://kubernetes.io/docs/concepts/security/pod-security-standards/
• kubectl Referenz: https://kubernetes.io/docs/reference/kubectl/
• kubeadm Referenz: https://kubernetes.io/docs/reference/setup-tools/kubeadm/
• kubeadm Cluster erstellen: https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/
• kubeadm Upgrade: https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/
• etcd Disaster Recovery: https://etcd.io/docs/
• Helm Dokumentation: https://helm.sh/docs/
• Kustomize Dokumentation: https://kubectl.docs.kubernetes.io/references/kustomize/
• Argo CD Dokumentation: https://argo-cd.readthedocs.io/
• Flux Dokumentation: https://fluxcd.io/flux/
• Cilium Dokumentation: https://docs.cilium.io/
• Falco Dokumentation: https://falco.org/docs/
• OpenTelemetry Dokumentation: https://opentelemetry.io/docs/

Anhang A: Kurzmatrix der Kernressourcen

Anhang B: Mindeststandard für Workshop-Manifeste

Jedes Manifest im Workshop sollte nach Möglichkeit enthalten:

• klare Namen,
• Namespace,
• Labels,
• definierte Selektoren,
• Ressourcenangaben,
• Probes bei langlebigen Anwendungen,
• SecurityContext, soweit anwendbar,
• keine echten Secrets,
• nachvollziehbare Image-Versionen,
• Kommentare nur dort, wo sie Verständnis schaffen.

Beispielstruktur:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
  namespace: workshop
  labels:
    app.kubernetes.io/name: web
    app.kubernetes.io/part-of: kubernetes-workshop
spec:
  replicas: 2
  selector:
    matchLabels:
      app.kubernetes.io/name: web
  template:
    metadata:
      labels:
        app.kubernetes.io/name: web
    spec:
      serviceAccountName: web
      containers:
        - name: web
          image: nginx:1.27
          ports:
            - name: http
              containerPort: 80
          readinessProbe:
            httpGet:
              path: /
              port: http
            periodSeconds: 10
          livenessProbe:
            httpGet:
              path: /
              port: http
            periodSeconds: 20
          resources:
            requests:
              cpu: "100m"
              memory: "128Mi"
            limits:
              memory: "256Mi"
          securityContext:
            allowPrivilegeEscalation: false
            readOnlyRootFilesystem: true
            capabilities:
              drop:
                - ALL

Anhang C: Rückbaucheckliste

Vor dem Ende einer Übung solltest du prüfen:

• Welche Namespaces wurden erstellt?
• Welche Deployments, Services, Jobs und Pods laufen noch?
• Welche PVCs und PVs bleiben erhalten?
• Welche LoadBalancer wurden erzeugt?
• Welche Secrets enthalten Testdaten?
• Welche RBAC-Bindings wurden erstellt?
• Welche NetworkPolicies beeinflussen weitere Übungen?
• Welche Helm-Releases sind installiert?

Beispielkommandos:

kubectl get all -n workshop
kubectl get configmap,secret,pvc,ingress,networkpolicy -n workshop
helm list -n workshop
kubectl delete namespace workshop

Anhang D: Abschluss-Review-Fragen

• Welche Ressource war der autoritative gewünschte Zustand?
• Welche Controller waren beteiligt?
• Welche Conditions oder Events waren für die Diagnose relevant?
• Welche Änderung war riskant?
• Wie hättest du die Änderung vorab validieren können?
• Wie wurde der Erfolg gemessen?
• Wie wird die Lösung zurückgebaut?
• Welche Security-Annahme ist noch offen?
• Welche Betriebsaufgabe muss automatisiert werden?
• Welche Dokumentation fehlt für den produktiven Betrieb?