1. Prüfungsziel

Die Prüfung weist nach, dass du Kubernetes als Plattform professionell entwerfen und betreiben kannst. Der Schwerpunkt liegt nicht mehr auf einzelnen Manifests, sondern auf Architektur, Verantwortlichkeiten, Upgradefähigkeit, Observability, Autoscaling, GitOps, Multi-Tenancy, Operator-Bewertung, Backup, Disaster Recovery und Kostenmanagement.

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

• Managed, Self-managed und Hybrid Kubernetes sachlich bewerten kannst,
• Cluster- und Node-Pool-Architektur für mehrere Teams planst,
• Plattform-Add-ons als Produkte mit Owner, Version, SLO und Upgrade-Pfad behandelst,
• Upgrades inklusive API-Deprecations, CRDs, Webhooks, Add-ons und Nodes planst,
• Observability als SLO-, Alert- und Runbook-System beschreibst,
• GitOps und CI/CD sauber trennst,
• Multi-Tenancy über Namespaces, RBAC, Quotas, LimitRanges, NetworkPolicies und Pod Security modellierst,
• Operatoren und CRDs betrieblich bewertest,
• Backup und Disaster Recovery testbar formulierst,
• Kostenquellen und Rightsizing-Maßnahmen nachvollziehbar ableitest.

2. Voraussetzungen und erlaubte Hilfsmittel

Du brauchst:

• keinen vollständigen Produktionscluster,
• Zugriff auf Beispielmanifeste oder ein Lab,
• optional kubectl, Helm und Kustomize,
• eine Textumgebung für Architektur- und Runbook-Dokumente.

Erlaubt sind:

• offizielle Kubernetes-Dokumentation,
• Workshop-Unterlagen,
• eigene Notizen,
• Diagramme, Tabellen und Entscheidungsmatrizen.

Nicht erlaubt sind:

• unbelegte Produktempfehlungen ohne Risikoabwägung,
• pauschale Aussagen wie „Managed ist immer besser“ oder „Namespaces sind vollständige Isolation“,
• ein Backup-Konzept ohne Restore-Test,
• ein GitOps-Konzept, bei dem CI dauerhaft Cluster-Admin-Rechte besitzt.

3. Ausgangsszenario

Eine Organisation möchte Kubernetes als interne Plattform für mehrere Produktteams betreiben. Es gibt drei Umgebungen:

• dev,
• staging,
• production.

Rahmenbedingungen:

• 12 Produktteams,
• 40 bis 60 Microservices,
• mehrere workerbasierte Workloads,
• 5 stateful Services mit PVCs,
• regulierte Daten in einzelnen Namespaces,
• zentrale Plattform-Add-ons,
• GitOps als Zielzustandsmodell,
• CI/CD mit Image-Build, Tests und Scans,
• externe DNS- und Zertifikatsanforderungen,
• Security-Vorgaben und Audit-Anforderungen,
• monatliche Release-Zyklen,
• geplante Kubernetes-Minor-Upgrades pro Quartal,
• Kosten müssen pro Team sichtbar werden.

Die Plattform soll upgradefähig, beobachtbar, kosteneffizient, mandantenfähig und wiederherstellbar sein.

4. Erwartete Abgabe

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

03-professional-abgabe/
  answers.md
  platform-blueprint.md
  operating-model.md
  node-pool-sizing.md
  addon-matrix.md
  upgrade-runbook.md
  observability-slo.md
  autoscaling-review.md
  gitops-flow.md
  tenant-standard.md
  operator-review.md
  dr-runbook.md
  cost-review.md
  handover.md

Die Dokumente dürfen Tabellen, Mermaid-Diagramme, Checklisten und Entscheidungsnotizen enthalten. Entscheidend ist, dass eine zweite Person die Plattformentscheidungen, Risiken und Betriebswege nachvollziehen kann.

5. Teil A: Fachfragen

Beantworte die Fragen mit Bezug zum Szenario.

1. Welche Verantwortung unterscheidet Managed Kubernetes von Self-managed Kubernetes?
2. Wann ist ein Shared Cluster sinnvoll, und wann ist ein Cluster pro Umgebung oder pro Kritikalität sinnvoller?
3. Welche Node Pools würdest du für Standard-Apps, CPU-Worker, stateful Workloads und System-Add-ons trennen?
4. Welche Add-ons gehören in einen Plattformstandard, und warum brauchen sie Owner, SLO und Upgrade-Pfad?
5. Warum ist ein Kubernetes-Upgrade ein Change-Prozess und nicht nur ein einzelner Befehl?
6. Welche Risiken entstehen durch API Deprecations, CRDs und Admission Webhooks bei Upgrades?
7. Was gehört zu Observability außer Dashboards?
8. Wie hängen Requests, HPA, VPA, Cluster Autoscaler, KEDA und Kosten zusammen?
9. Warum sollte CI nicht dauerhaft breite Clusterrechte besitzen?
10. Warum reicht ein Namespace allein nicht für Multi-Tenancy?
11. Welche Risiken bringen Operatoren und CRDs in den Plattformbetrieb?
12. Warum ist ein Backup ohne getesteten Restore kein belastbares DR-Konzept?

6. Teil B: Plattform-Blueprint

Erstelle platform-blueprint.md und operating-model.md.

Aufgabe B1: Zielarchitektur

Beschreibe eine Zielarchitektur mit:

• Cluster-Modell für dev, staging und production,
• Umgebungstrennung,
• Availability-Zone-Strategie,
• Verantwortlichkeiten für Plattformteam, App-Teams, Security und Betrieb,
• Ingress-/Gateway-Modell,
• DNS- und Zertifikatsmodell,
• Storage- und Backup-Grundmodell,
• GitOps-Zielzustand,
• Observability- und Alerting-Ansatz,
• Kostenlabel und Showback.

Aufgabe B2: Managed, Self-managed und Hybrid bewerten

Erstelle eine Entscheidungsmatrix.

Leite daraus eine Empfehlung für das Szenario ab. Die Empfehlung muss Trade-offs und offene Entscheidungen enthalten.

Aufgabe B3: Node Pools und Sizing

Erstelle node-pool-sizing.md mit mindestens vier Node Pools:

Berücksichtige:

• DaemonSet-Overhead,
• kube-reserved und system-reserved,
• Rollout-Puffer,
• Node- und Zonenausfall,
• Pod-Dichte,
• IP-Adressraum,
• Cloud-Quotas für Compute, Volumes, Load Balancer und Firewall-Regeln,
• Stop-Kriterien für Skalierung.

Aufgabe B4: Add-on-Matrix

Erstelle addon-matrix.md mit mindestens diesen Add-ons:

• CNI,
• CSI,
• CoreDNS,
• Ingress oder Gateway Controller,
• Metrics Server,
• Observability Stack,
• GitOps Controller,
• Policy Engine,
• Backup-Werkzeug,
• cert-manager oder vergleichbares Zertifikatsmodell.

Für jedes Add-on dokumentierst du:

• Zweck,
• Owner,
• Kritikalität,
• Version-/Upgrade-Pfad,
• SLO oder Betriebsziel,
• wichtigste Metriken oder Events,
• Backup- oder Restore-Relevanz,
• bekannte Ausfallwirkung.

7. Teil C: Betriebs- und Lifecycle-Runbooks

Aufgabe C1: Upgrade-Runbook

Erstelle upgrade-runbook.md für ein Kubernetes-Minor-Upgrade.

Pflichtabschnitte:

1. Zielversion und Istversion,
2. Version-Skew-Prüfung,
3. API-Deprecation-Scan für Manifeste, Helm Charts und Kustomize Overlays,
4. CRD- und Webhook-Prüfung,
5. Add-on-Kompatibilität,
6. Backup und Restore-Punkt,
7. Testcluster oder Staging-Test,
8. Control-Plane-Upgrade,
9. Add-on-Prüfung,
10. Node-Pool-Upgrade mit Cordon und Drain,
11. Smoke Tests,
12. Stop-Kriterien,
13. Recovery-Plan,
14. Abschlussbericht.

Nenne mindestens fünf konkrete Stop-Kriterien.

Aufgabe C2: Observability und SLO

Erstelle observability-slo.md für eine Beispiel-App checkout-api und Plattformkomponenten.

Dokumentiere:

• Service Level Objective,
• Service Level Indicators,
• Metriken,
• Logs,
• Traces,
• Kubernetes-Events,
• Dashboards,
• Alerts,
• Runbook-Links,
• Retention,
• On-Call- oder Eskalationsweg.

Plattformsignale müssen mindestens API Server, CoreDNS, Ingress/Gateway, Nodes, PVC/CSI und GitOps umfassen.

Aufgabe C3: Autoscaling-Review

Erstelle autoscaling-review.md für eine Queue-basierte Worker-Anwendung.

Bewerte:

• CPU-/Memory-Requests,
• HPA,
• VPA,
• Cluster Autoscaler,
• Karpenter oder vergleichbare Node-Provisionierung,
• KEDA für Queue-Länge,
• Flapping-Risiko,
• Kostenanstieg,
• fehlende oder falsche Metriken,
• maximale Replikate und Budgetgrenzen.

8. Teil D: Governance, GitOps, DR und Kosten

Aufgabe D1: GitOps- und CI/CD-Fluss

Erstelle gitops-flow.md mit Ablauf:

1. Code Commit,
2. CI: Build, Test, Scan,
3. Image Push in Registry,
4. Digest-Ermittlung,
5. Pull Request für Manifest-Änderung,
6. Review und Freigabe,
7. GitOps Sync,
8. Drift Detection,
9. Rollback per Git Revert.

Dokumentiere die Identitäten und Rechte:

Aufgabe D2: Tenant-Standard

Erstelle tenant-standard.md mit einem Muster für einen Team-Namespace.

Pflichtelemente:

• Namespace-Labels,
• Owner-Annotation,
• Kostenlabel,
• ResourceQuota,
• LimitRange,
• Role und RoleBinding,
• NetworkPolicy Default Deny,
• Pod-Security-Labels,
• Standard für Ingress/Gateway-Anträge,
• Ausnahmeprozess.

Beschreibe klar, welche Kontrollen im Professional-Level entworfen werden und welche im Advanced + Security-Level härter geprüft oder erzwungen werden.

Aufgabe D3: Operator-Review

Erstelle operator-review.md für einen hypothetischen database-operator.

Bewerte:

• installierte CRDs,
• benötigte ClusterRoles,
• Custom Resources,
• Conditions und Events,
• Backup-Relevanz,
• Upgrade-Risiken,
• Deinstallationsrisiken,
• Mandantenfähigkeit,
• Stop-Kriterien für Produktion.

Aufgabe D4: Backup und Disaster Recovery

Erstelle dr-runbook.md mit zwei Szenarien:

1. Restore eines einzelnen Namespace,
2. Restore eines gesamten Clusters.

Für jedes Szenario dokumentierst du:

• Datenklassen,
• benötigte Backups,
• Restore-Reihenfolge,
• Validierung,
• RTO/RPO-Annahme,
• Risiken,
• Evidence.

Datenklassen müssen mindestens Git-Zustand, etcd, PVC-Daten, Secrets, CRDs und externe Systeme umfassen.

Aufgabe D5: Kostenanalyse

Erstelle cost-review.md.

Ausgangslage:

• viele Pods mit hohen Requests und niedriger Nutzung,
• ungenutzte PVCs,
• mehrere externe Load Balancer,
• dauerhaft laufende Dev-Workloads,
• keine Showback-Zuordnung pro Namespace.

Dokumentiere:

• Kostenquellen,
• technische Messpunkte,
• Rightsizing-Empfehlungen,
• Risiken von Underrequesting,
• Showback-Modell,
• Maßnahmenplan mit Priorisierung.

Aufgabe D6: Betriebsübergabe

Erstelle handover.md für eine andere Person im Betrieb.

Pflichtinhalte:

• Plattformüberblick,
• kritische Add-ons,
• bekannte SLOs,
• Alarmwege,
• Upgrade-Fenster,
• Backup- und Restore-Verantwortung,
• Top-5-Runbooks,
• Stop-Kriterien,
• offene Risiken.

9. Bewertung

Bewertungsskala:

10. K.-o.-Kriterien

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

• Backup wird beschrieben, aber Restore-Test oder Restore-Reihenfolge fehlen vollständig.
• CI erhält dauerhaft pauschale Cluster-Admin-Rechte ohne Begründung und Begrenzung.
• Namespaces werden als vollständige Sicherheitsisolation dargestellt.
• Add-ons werden ohne Owner, Upgrade-Pfad oder Ausfallwirkung behandelt.
• Upgrade-Plan enthält keine API-Deprecation-, CRD- oder Webhook-Prüfung.
• Kostenmodell ignoriert Requests, Limits, Storage, Load Balancer und Egress vollständig.
• Die Abgabe besteht nur aus Toolnamen ohne Architektur- oder Betriebsentscheidung.

11. Prüfer-Checkliste