1. Prüfungsziel

Die Prüfung weist nach, dass du produktionsnähere Kubernetes-Workloads modellieren, konfigurieren und debuggen kannst. Der Schwerpunkt liegt auf Workload-Auswahl, Probes, Lifecycle, Ressourcenmanagement, Scheduling, NetworkPolicy, DNS, Ingress oder Gateway API, Storage, Helm, Kustomize und systematischem Troubleshooting.

Nach der Prüfung soll erkennbar sein, dass du:

• Deployment, StatefulSet, DaemonSet, Job und CronJob nach Zweck unterscheiden kannst,
• Init Container, Sidecar Container und Ephemeral Container korrekt einordnest,
• Startup, Readiness und Liveness Probes fachlich trennst,
• Requests, Limits, QoS, LimitRange und ResourceQuota anwenden kannst,
• Scheduling-Probleme über Events, Node-Labels, Taints und Tolerations erklärst,
• Service, DNS, EndpointSlices und NetworkPolicies getrennt diagnostizierst,
• Ingress und Gateway API als Regel plus Controller verstehst,
• PVC, PV, StorageClass und StatefulSet grundlegend beherrschst,
• Helm- und Kustomize-Ausgaben vor dem Anwenden prüfst.

2. Voraussetzungen und erlaubte Hilfsmittel

Du brauchst:

• einen Lab-Cluster mit funktionierendem CNI,
• CoreDNS,
• kubectl,
• optional helm,
• optional kubectl kustomize oder kustomize,
• optional eine StorageClass,
• optional einen Ingress Controller oder Gateway Controller.

Erlaubt sind:

• offizielle Kubernetes-Dokumentation,
• eigene Workshop-Notizen,
• kubectl explain, kubectl describe, kubectl logs, kubectl get events,
• lokale Manifeste, die während der Prüfung erstellt werden.

Nicht erlaubt sind:

• produktive Secrets,
• Änderungen außerhalb des Prüfungs-Namespace, sofern nicht ausdrücklich gefordert,
• Cluster-weite Änderungen ohne Dokumentation und Rückbau.

Empfohlener Namespace:

export NS=exam-intermediate

3. Ausgangsszenario

Ein Team betreibt eine kleine Shop-Anwendung im Lab. Die Anwendung besteht aus:

• frontend: nimmt HTTP-Anfragen an,
• backend: stellt eine interne API auf Port 8080 bereit,
• migration: läuft einmalig vor einer neuen Version,
• cleanup: läuft regelmäßig,
• data-demo: speichert eine kleine Datei persistent.

Die Anwendung soll kontrollierte Health Checks, Ressourcenanforderungen, Namespace-Grenzen, NetworkPolicies und eine saubere Diagnose erhalten. Externe Veröffentlichung erfolgt über Ingress oder Gateway API, falls ein Controller vorhanden ist. Falls kein Controller vorhanden ist, muss dies fachlich korrekt dokumentiert werden.

4. Erwartete Abgabe

Gib am Ende einen Ordner oder ein Archiv mit folgenden Dateien ab:

02-intermediate-abgabe/
  answers.md
  architecture-decision.md
  workloads/
    frontend.yml
    backend.yml
    migration-job.yml
    cleanup-cronjob.yml
  resources/
    limitrange.yml
    resourcequota.yml
  networking/
    services.yml
    networkpolicies.yml
    ingress-or-gateway.yml
  storage/
    statefulset.yml
  packaging/
    kustomize-output.md
    helm-output.md
  troubleshooting.md
  evidence.md
  cleanup.md

Wenn Helm, Gateway API, Ingress Controller oder StorageClass nicht verfügbar sind, dokumentiere die Einschränkung und liefere ein fachlich korrektes Beispielmanifest oder eine nachvollziehbare Alternativbewertung.

5. Teil A: Wissensfragen

Beantworte die Fragen präzise und mit betrieblichem Bezug.

1. Wann nutzt du ein Deployment, wann ein StatefulSet, wann einen Job und wann einen CronJob?
2. Was unterscheidet Init Container, Sidecar Container und Ephemeral Container?
3. Welche Aufgabe haben Startup Probe, Readiness Probe und Liveness Probe?
4. Warum kann eine zu aggressive Liveness Probe Schaden verursachen?
5. Welche Wirkung haben CPU-/Memory-Requests auf Scheduling und HPA?
6. Was ist der Unterschied zwischen Guaranteed, Burstable und BestEffort QoS?
7. Welche Aufgabe haben LimitRange und ResourceQuota?
8. Was ist der Unterschied zwischen nodeSelector, Affinity, Taints und Tolerations?
9. Warum kann ein Pod trotz korrektem Manifest im Status Pending bleiben?
10. Wie hängen Service, EndpointSlice, Pod-Readiness und DNS zusammen?
11. Warum muss DNS-Egress bei Default-Deny-NetworkPolicies explizit berücksichtigt werden?
12. Was ist der Unterschied zwischen Ingress-Ressource und Ingress Controller?
13. Welche Rolle haben PV, PVC, StorageClass und CSI?
14. Warum ist hostPath im Lab nicht automatisch eine Produktionslösung?
15. Was prüfst du bei PVC Pending, Service ohne Endpoints und CreateContainerConfigError?

6. Teil B: Workload- und Architekturentscheidung

Erstelle architecture-decision.md. Beschreibe für jede Anforderung die passende Kubernetes-Ressource und begründe deine Entscheidung.

7. Teil C: Praxisaufgaben

Aufgabe C1: Namespace, Quota und LimitRange

1. Erstelle den Namespace exam-intermediate.
2. Erstelle eine LimitRange mit Default Requests und Limits.
3. Erstelle eine ResourceQuota für Pods, CPU und Memory.
4. Zeige, dass ein zu großer Pod vom API Server abgelehnt wird.

Mindestanforderung für Quota:

pods: 10
requests.cpu: 2
requests.memory: 2Gi
limits.cpu: 4
limits.memory: 4Gi

Aufgabe C2: Frontend und Backend mit Probes

Erstelle zwei Deployments:

• frontend mit Image curlimages/curl:8.8.0 oder einem vergleichbaren ungefährlichen Testimage,
• backend mit einem HTTP-Testserver auf Port 8080, zum Beispiel registry.k8s.io/e2e-test-images/agnhost:2.53 mit netexec.

Anforderungen:

• sinnvolle CPU-/Memory-Requests und Limits,
• Readiness Probe für Service-Traffic,
• Liveness Probe für echte Neustartfälle,
• Startup Probe, falls die App langsam startet,
• eindeutige Labels: app, component, environment,
• Services für Frontend und Backend.

Dokumentiere, warum Readiness nicht dasselbe Ziel wie Liveness hat.

Aufgabe C3: Job und CronJob

Erstelle:

• einen Job migration, der einmalig erfolgreich endet,
• einen CronJob cleanup, der stündlich läuft,
• concurrencyPolicy: Forbid für den CronJob,
• sinnvolle successfulJobsHistoryLimit und failedJobsHistoryLimit.

Dokumentiere, warum ein Deployment hierfür fachlich schlechter geeignet wäre.

Aufgabe C4: Scheduling prüfen

1. Label einen Lab-Node mit exam-role=apps.
2. Erstelle einen Pod oder ein Deployment mit passendem nodeSelector.
3. Erstelle einen zweiten Pod mit nicht passendem nodeSelector.
4. Dokumentiere die Pending-Events.
5. Setze einen Taint auf den gelabelten Node.
6. Zeige den Unterschied zwischen Pod ohne Toleration und Pod mit passender Toleration.
7. Baue die Node-Änderungen sauber zurück.

Aufgabe C5: NetworkPolicy Default Deny plus gezielte Erlaubnisse

Erstelle NetworkPolicies mit diesen Anforderungen:

1. Default Deny für Ingress und Egress im Namespace.
2. DNS-Egress zu CoreDNS erlauben.
3. frontend darf backend auf TCP-Port 8080 erreichen.
4. Sonstiger Egress bleibt blockiert.
5. Dokumentiere, ob dein CNI NetworkPolicies tatsächlich durchsetzt.

Nachweise:

kubectl get networkpolicy -n exam-intermediate
kubectl exec <frontend-pod> -n exam-intermediate -- nslookup backend
kubectl exec <frontend-pod> -n exam-intermediate -- curl -s --max-time 5 http://backend:8080/hostname

Aufgabe C6: Ingress oder Gateway API

Prüfe zuerst, ob ein Controller vorhanden ist:

kubectl get ingressclass
kubectl get gatewayclass 2>/dev/null || true

Wenn ein Ingress Controller vorhanden ist:

• erstelle eine Ingress-Ressource mit Hostname shop.localtest.me,
• leite auf den passenden Service,
• dokumentiere Controller-Events und Backend-Zuordnung.

Wenn Gateway API vorhanden ist:

• erstelle oder beschreibe ein Gateway-/HTTPRoute-Modell,
• dokumentiere ParentRef, Hostname und BackendRef.

Wenn kein Controller vorhanden ist:

• erstelle ein Beispielmanifest,
• erkläre, warum die Ressource ohne Controller keine praktische Wirkung hat.

Aufgabe C7: PVC und StatefulSet

1. Prüfe vorhandene StorageClasses.
2. Erstelle ein StatefulSet data-demo mit volumeClaimTemplates.
3. Schreibe eine Datei in /data/test.txt.
4. Lösche den Pod.
5. Prüfe nach Neuerstellung, ob die Datei noch vorhanden ist.
6. Dokumentiere die StorageClass und die Grenzen des Labs.

Aufgabe C8: Helm und Kustomize rendern

1. Erstelle eine kleine Kustomize-Base und ein Overlay dev.
2. Rendere das Overlay mit kubectl kustomize.
3. Erstelle ein minimales Helm Chart oder nutze ein lokales Beispielchart.
4. Rendere das Chart mit helm template.
5. Vergleiche Reviewbarkeit, Parametrisierung und Fehlerrisiko.

8. Teil D: Troubleshooting-Parcours

Untersuche fünf Fehlerbilder. Für jedes Fehlerbild dokumentierst du Symptom, Diagnose, Ursache, Fix und Validierung.

9. Bewertung

Bewertungsskala:

10. K.-o.-Kriterien

Die Prüfung gilt unabhängig von der Punktzahl als nicht bestanden, wenn eines dieser Kriterien zutrifft:

• produktive oder fremde Cluster-Kontexte werden verwendet,
• Node-Taints oder Labels werden nicht zurückgebaut,
• NetworkPolicy wird behauptet, aber nicht getestet oder CNI-Wirkung nicht eingeordnet,
• echte Secrets oder produktive Registry-Zugangsdaten werden verwendet,
• keine Diagnose-Evidence für die Troubleshooting-Aufgaben vorhanden ist,
• Cluster-weite Ressourcen werden ohne Begründung verändert.

11. Prüfer-Checkliste