# Plattform-Blueprint

## Ziel

Die Kubernetes-Plattform stellt standardisierte Umgebungen für 12 Produktteams und 40 bis 60 Microservices bereit. Sie soll upgradefähig, beobachtbar, mandantenfähig, wiederherstellbar und kostenbewusst betrieben werden.

## Cluster-Modell

| Umgebung | Modell | Begründung |
| --- | --- | --- |
| dev | Shared Cluster | Kosten, schnelle Iteration, geringere Kritikalität |
| staging | eigener Cluster | Produktionsnähe, Upgrade- und Release-Tests |
| production | eigener Cluster, optional getrennt nach Kritikalität | Blast Radius, Compliance, stabile Betriebsfenster |

## Availability Zones

Production wird über mindestens drei Availability Zones betrieben. System-Add-ons und App-Replikate werden zonenverteilt. Stateful Workloads erhalten Storage-Klassen mit passender Zonenbindung und dokumentierter Restore-Strategie.

## Verantwortlichkeiten

| Bereich | Owner | Aufgaben |
| --- | --- | --- |
| Plattformteam | Plattform | Cluster, Node Pools, Add-ons, GitOps, Quotas, Runbooks |
| App-Teams | Produktteams | App-Manifeste, SLOs, Requests, Probes, fachliche Releases |
| Security | Security-Team | Policies, Audits, Ausnahmeprozesse, Compliance Evidence |
| Betrieb/On-Call | Plattform + App | Incident-Erstreaktion, Eskalation, DR-Übungen |

## Ingress/Gateway

- Zentraler Gateway oder Ingress Controller pro Umgebung.
- App-Teams beantragen Hostnames und Routes per PR.
- TLS-Zertifikate werden über cert-manager oder ein internes Zertifikatsmodell verwaltet.
- Wildcard-Zertifikate nur mit dokumentierter Freigabe.

## DNS und Zertifikate

- Externe DNS-Einträge werden automatisiert oder per Change-Prozess gepflegt.
- Zertifikate haben Owner, Ablaufüberwachung und Erneuerungspfad.
- Production nutzt separate Issuer oder PKI-Richtlinien.

## Storage und Backup

- Standard-StorageClass für allgemeine PVCs.
- Separate StorageClass für stateful/regulated Workloads.
- VolumeSnapshots oder Backup-Tool für PVC-Daten.
- Restore-Tests mindestens quartalsweise.

## GitOps

- Git ist Quelle des gewünschten Zustands.
- CI erstellt Images und Manifest-PRs mit Digests.
- GitOps Controller synchronisiert Zielnamespaces mit begrenzten Rechten.
- Rollback erfolgt per Git Revert.

## Observability

- Metriken, Logs, Traces und Kubernetes-Events werden zentral gesammelt.
- Plattform- und App-SLOs sind dokumentiert.
- Alerts verweisen auf Runbooks.
- Retention ist nach Umgebung und Compliance festgelegt.

## Kostenlabel und Showback

Pflichtlabels:

- `owner`
- `environment`
- `cost-center`
- `app`

Showback wird pro Namespace, Team, Umgebung und Kostenquelle ausgewertet.

# Operating Model

## Empfehlung

Für das Szenario wird Managed Kubernetes empfohlen, sofern Providergrenzen und Compliance-Anforderungen erfüllt werden. Self-managed Kubernetes ist nur für spezielle On-Premises- oder Bare-Metal-Anforderungen gerechtfertigt. Hybrid ist möglich, erhöht aber Netzwerk-, Governance- und Betriebsaufwand.

## Entscheidungsmatrix

| Kriterium | Managed | Self-managed | Hybrid |
| --- | --- | --- | --- |
| Control Plane | Provider betreibt | internes Team betreibt | geteilt |
| Upgrade-Aufwand | geringer, aber Add-ons bleiben intern | hoch | mittel bis hoch |
| Security-Verantwortung | geteilt | überwiegend intern | geteilt und komplex |
| Provider-Abhängigkeit | hoch | niedrig bis mittel | mittel |
| Betriebsrisiko | Provider-Limits und Abstraktion | Betriebsfehler, PKI/etcd/HA | Integrationsfehler |
| Teamfähigkeiten | Plattform- und Cloud-Know-how | tiefes Kubernetes/etcd/PKI | Cloud + On-Prem + Netzwerk |
| Kostenmodell | planbar, Providerkosten | Betriebspersonal + Infrastruktur | komplexes Modell |

## Offene Entscheidungen

- Trennung regulierter Produktivdaten per Cluster oder Namespace mit Zusatzkontrollen.
- Auswahl Gateway API vs. Ingress.
- Backup-Werkzeug und Restore-Test-Frequenz.
- Policy Engine und Ausnahmeprozess.

# Node Pool Sizing

| Node Pool | Zweck | Eigenschaften | Risiken |
| --- | --- | --- | --- |
| system-pool | Plattform-Add-ons | Taints, stabile On-Demand-Nodes, Overhead eingeplant | Add-on-Ausfall blockiert Plattform |
| app-general | Standard-Webservices | zonenverteilt, HPA-fähig, Rolling-Update-Puffer | Overrequesting, Pod-Dichte |
| worker-cpu | CPU-intensive Worker | Autoscaling, optional Spot mit Retry/PDB | Spot-Unterbrechung, Kostenflapping |
| stateful | PVC-nahe Workloads | stabile Storage-Anbindung, vorsichtige Wartung | Zonenbindung, Restore-Komplexität |

## Sizing-Regeln

- App-Requests plus DaemonSet-Overhead planen.
- `kube-reserved` und `system-reserved` berücksichtigen.
- Rollout-Puffer für neue Pods während Rolling Update einplanen.
- Mindestens Node-Ausfall, bei Prod auch Zonenausfall bewerten.
- Pod-Dichte und IP-Adressraum prüfen.
- Cloud-Quotas für Compute, IPs, Volumes, Load Balancer und Firewall-Regeln prüfen.

## Stop-Kriterien

- Pods bleiben wegen Ressourcen `Pending`.
- Cluster Autoscaler kann keine Nodes mehr hinzufügen.
- IP-Adressraum oder Cloud-Quota erschöpft.
- CoreDNS, CNI oder CSI zeigt kritische Fehlerrate.
- System-Add-ons laufen in OOMKill oder CPU-Throttling.

# Add-on-Matrix

| Add-on | Zweck | Owner | Kritikalität | Upgrade-Pfad | SLO/Betriebsziel | Metriken/Events | Backup/Restore | Ausfallwirkung |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| CNI | Pod-Netz und NetworkPolicy | Plattform | kritisch | Staging vor Prod | Pod-Netz verfügbar | CNI-Errors, Pod Pending | Konfiguration sichern | Pods kommunizieren nicht |
| CSI | Storage-Provisionierung | Plattform | kritisch für Stateful | Version passend zu Cluster | PVC-Provisionierung stabil | PVC Pending, Attach-Errors | VolumeSnapshots | Stateful Apps blockieren |
| CoreDNS | Service Discovery | Plattform | kritisch | Rolling Update | DNS-Latenz niedrig | NXDOMAIN-Rate, Latenz | ConfigMap sichern | Services nicht auffindbar |
| Gateway/Ingress | HTTP-Zugriff | Plattform | hoch | kontrolliertes Controller-Upgrade | 99.9% Routing | 5xx, Backend-Health | Config aus Git | externe Apps nicht erreichbar |
| Metrics Server | Resource Metrics API | Plattform | mittel | Cluster-kompatibel | HPA-Metriken verfügbar | Metrics API Errors | kein Datenbackup | HPA/kubectl top gestört |
| Observability | Metrics/Logs/Traces | Plattform | hoch | Komponentenweise | Signalverfügbarkeit | Ingest, Query, Retention | Storage/Config sichern | Blindflug im Incident |
| GitOps Controller | Desired-State-Sync | Plattform | hoch | Staging-Test | Sync zuverlässig | Drift, Sync-Errors | Git ist Quelle | Deployments stoppen/falsch |
| Policy Engine | Governance | Plattform+Security | hoch | Audit vor Enforce | sichere Ressourcen | Policy Reports | Policies aus Git | unsichere oder blockierte Deployments |
| Backup-Werkzeug | Restore-Fähigkeit | Plattform | hoch | Restore-Test | Backup+Restore erfolgreich | Backup Status | Backups selbst schützen | DR nicht möglich |
| cert-manager | Zertifikate | Plattform | hoch | Issuer prüfen | Zertifikate gültig | Expiry, failed renewals | Issuer/Secrets schützen | TLS-Ausfälle |

# Upgrade-Runbook: Kubernetes Minor Upgrade

## 1. Zielversion und Istversion

- Istversion: v1.x
- Zielversion: v1.y
- Umgebungen: zuerst dev, dann staging, dann production

## 2. Version-Skew-Prüfung

```bash
kubectl version
kubectl get nodes -o wide
```

## 3. API-Deprecation-Scan

- Manifeste in Git scannen.
- Helm Charts mit `helm template` rendern.
- Kustomize Overlays mit `kubectl kustomize` rendern.
- Alte API-Versionen dokumentieren und migrieren.

## 4. CRD- und Webhook-Prüfung

```bash
kubectl get crds
kubectl get validatingwebhookconfigurations,mutatingwebhookconfigurations
kubectl get apiservices
```

## 5. Add-on-Kompatibilität

CNI, CSI, CoreDNS, Gateway/Ingress, Metrics Server, Observability, GitOps, Policy Engine und Backup-Werkzeug gegen Zielversion prüfen.

## 6. Backup und Restore-Punkt

- etcd/Provider-Snapshot oder Cluster-Backup.
- GitOps-Revision festhalten.
- PVC-Snapshots für stateful Workloads.
- Restore-Prozess im Staging validieren.

## 7. Staging-Test

Upgrade vollständig im Staging durchführen, inklusive Smoke Tests und Rollback-Simulation.

## 8. Control-Plane-Upgrade

Managed: Provider-Mechanismus nutzen. Self-managed: API Server, Controller Manager, Scheduler und etcd gemäß Betriebsdokumentation aktualisieren.

## 9. Add-on-Prüfung

Nach Control-Plane-Upgrade Add-on-Status prüfen:

```bash
kubectl get pods -A
kubectl get events -A --sort-by=.metadata.creationTimestamp
```

## 10. Node-Pool-Upgrade

```bash
kubectl cordon <node>
kubectl drain <node> --ignore-daemonsets --delete-emptydir-data
# Node durch Provider oder Betriebsprozess aktualisieren
kubectl uncordon <node>
```

## 11. Smoke Tests

- API Server erreichbar.
- CoreDNS löst Services auf.
- Ingress/Gateway routet.
- PVC Attach/Detach funktioniert.
- GitOps synchronisiert.
- Kritische App-SLOs sind unauffällig.

## 12. Stop-Kriterien

- API Server Error Rate erhöht oder API nicht stabil.
- CNI blockiert Pod-Netzwerk.
- CoreDNS instabil oder hohe DNS-Fehlerrate.
- CSI kann Volumes nicht attachen.
- Admission Webhook blockiert normale Deployments.
- Kritische Workloads werden nicht Ready.
- Deprecation-Funde sind nicht behoben.
- Restore-Punkt fehlt oder Backup fehlgeschlagen.

## 13. Recovery-Plan

- Change stoppen.
- Betroffenen Node Pool nicht weiter aktualisieren.
- Add-on-Version zurückrollen, falls kompatibel.
- Workloads per GitOps auf bekannte Revision zurücksetzen.
- Bei Clusterfehler: Provider-Support oder Restore-Prozess aktivieren.

## 14. Abschlussbericht

- Version vorher/nachher.
- Zeitfenster.
- betroffene Komponenten.
- Smoke-Test-Ergebnisse.
- offene Risiken.
- Lessons Learned.

# Observability und SLO

## App-SLO: checkout-api

99.9% der erfolgreichen `/checkout`-Requests innerhalb von 300 ms über 30 Tage.

## SLIs

| SLI | Quelle |
| --- | --- |
| Erfolgsrate | Ingress/App-Metriken |
| p95/p99-Latenz | App/Ingress-Metriken |
| Request Rate | App/Ingress |
| Error Rate | HTTP 5xx und fachliche Fehler |

## Signale

| Signal | Verwendung |
| --- | --- |
| Metriken | SLO, Alerts, Kapazität |
| Logs | Ursachenanalyse |
| Traces | Abhängigkeiten und Latenzen |
| Kubernetes-Events | Scheduling, Image Pull, Probe, PVC |
| Dashboards | Lagebild |
| Alerts | Handlungsbedarf mit Runbook |

## Alerts

- Error Rate > 2% für 10 Minuten.
- p95 > 300 ms für 15 Minuten.
- Deployment nicht vollständig verfügbar für 10 Minuten.
- HPA am Maximum für 15 Minuten.

## Plattformsignale

| Komponente | Signal |
| --- | --- |
| API Server | Latenz, 5xx, Request Rate |
| CoreDNS | DNS-Latenz, Fehler, Replikate |
| Gateway/Ingress | 5xx, Backend-Health, TLS-Fehler |
| Nodes | Ready, MemoryPressure, DiskPressure, PIDPressure |
| PVC/CSI | Pending PVC, Attach/Detach-Fehler |
| GitOps | Sync-Status, Drift, Reconcile-Fehler |

## Retention und On-Call

- Metriken: 30 bis 90 Tage je Umgebung.
- Logs: 14 bis 30 Tage, regulierte Daten nach Policy.
- Traces: kürzer, samplingbasiert.
- Alerts verweisen auf konkrete Runbooks und Eskalationswege.

# Autoscaling Review: Queue Worker

## Ausgangslage

Queue-basierte Worker verarbeiten Jobs mit Lastspitzen tagsüber und niedriger Last nachts.

## Ressourcen

- CPU Request anhand p95-Nutzung je Job-Typ.
- Memory Request anhand p95/p99 plus Sicherheitsmarge.
- Memory Limit vorsichtig setzen, um OOMKills zu vermeiden.

## HPA

HPA kann CPU ergänzend nutzen, ist aber für Queue-Länge nicht ideal. MaxReplicas begrenzen Kosten.

## KEDA

KEDA ist sinnvoll, wenn Queue-Länge oder Lag die beste Lastmetrik ist. Beispielstrategie:

- minReplicas: 1 oder 0, falls Cold Start akzeptabel.
- maxReplicas: budgetabhängig.
- Scaling nach Queue-Länge pro Worker.

## VPA

VPA im Empfehlungsmodus für Rightsizing. Automatischer Modus nur nach Test, da er Pods neu starten kann.

## Node Autoscaling

Cluster Autoscaler oder Karpenter stellt Nodes für Pending Pods bereit. Quotas, IPs, NodeClass und Spot-Risiken müssen begrenzt werden.

## Risiken

| Risiko | Kontrolle |
| --- | --- |
| Flapping | Stabilization Windows und Cooldowns |
| Kostenanstieg | maxReplicas, Budgets, Alerts |
| fehlende Metriken | Fallback und Alert |
| Underrequesting | SLO- und OOMKill-Überwachung |
| langsames Node-Provisioning | Puffer, Priority, Pre-Warming |

# GitOps- und CI/CD-Fluss

## Ablauf

1. Code Commit.
2. CI baut Image.
3. CI führt Tests und Scans aus.
4. CI pusht Image in Registry.
5. CI ermittelt Image-Digest.
6. CI erstellt Pull Request für Manifest-Änderung.
7. Review prüft Diff, Policies, Ressourcen und Security.
8. Merge aktualisiert gewünschten Zustand.
9. GitOps Controller synchronisiert Cluster.
10. Drift Detection meldet manuelle Abweichungen.
11. Rollback erfolgt per Git Revert.

## Identitäten und Rechte

| Identität | Benötigte Rechte | Nicht erlaubt |
| --- | --- | --- |
| CI Build Identity | Registry Push, Scan, PR erstellen | dauerhafte Cluster-Admin-Rechte |
| Reviewer | Git Review und Freigabe | direkte Clusteränderungen ohne Review |
| GitOps Controller | begrenzte Rechte auf Zielnamespaces | unbegrenzte Clusterrechte ohne Scope |
| Plattformteam | Add-ons, Policies, Clusterressourcen | unreviewte Ad-hoc-Änderungen |
| App-Team | PRs und namespace-bezogene App-Änderungen | clusterweite Rechte |

# Tenant Standard: Team Namespace

## Namespace

```yaml
apiVersion: v1
kind: Namespace
metadata:
  name: team-a-prod
  labels:
    owner: team-a
    environment: prod
    cost-center: cc-1234
    pod-security.kubernetes.io/enforce: baseline
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted
  annotations:
    platform.example.com/owner-email: team-a@example.com
```

## ResourceQuota

```yaml
apiVersion: v1
kind: ResourceQuota
metadata:
  name: team-quota
  namespace: team-a-prod
spec:
  hard:
    pods: "30"
    requests.cpu: "8"
    requests.memory: 16Gi
    limits.cpu: "16"
    limits.memory: 32Gi
    persistentvolumeclaims: "10"
```

## LimitRange

```yaml
apiVersion: v1
kind: LimitRange
metadata:
  name: defaults
  namespace: team-a-prod
spec:
  limits:
    - type: Container
      defaultRequest:
        cpu: 100m
        memory: 128Mi
      default:
        cpu: 500m
        memory: 512Mi
```

## Role und RoleBinding

```yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: app-deployer
  namespace: team-a-prod
rules:
  - apiGroups: ["", "apps", "batch", "networking.k8s.io"]
    resources: ["pods", "pods/log", "services", "configmaps", "deployments", "replicasets", "jobs", "cronjobs", "ingresses"]
    verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: app-deployer-binding
  namespace: team-a-prod
subjects:
  - kind: Group
    name: team-a-developers
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: app-deployer
  apiGroup: rbac.authorization.k8s.io
```

## Default-Deny NetworkPolicy

```yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
  namespace: team-a-prod
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress
```

## Abgrenzung Professional vs. Advanced + Security

Professional entwirft Tenant-Governance und Standardressourcen. Advanced + Security prüft zusätzlich harte RBAC-Eskalationspfade, Admission Enforcement, Secret-Flows, Runtime Detection und Incident Response.

# Operator Review: database-operator

## Zweck

Der hypothetische `database-operator` verwaltet Datenbankinstanzen über Custom Resources.

## CRDs

- `databases.example.com`
- `databasebackups.example.com`
- `databaserestores.example.com`

## Rechte

Benötigt Zugriff auf eigene CRDs, StatefulSets, Services, PVCs, Secrets und Events. Clusterweite Rechte müssen begründet und minimiert werden.

## Conditions und Events

- `Ready`
- `Progressing`
- `Degraded`
- `BackupReady`
- `RestoreFailed`

## Backup-Relevanz

CRs allein reichen nicht. PVC-Daten, Secrets, Operator-Konfiguration und externe Backups müssen einbezogen werden.

## Upgrade-Risiken

- CRD-Schemaänderungen.
- Conversion Webhooks.
- Finalizer blockieren Löschung.
- Operator-Version nicht kompatibel.
- alte CRs nicht migrierbar.

## Deinstallationsrisiken

- CRDs löschen auch Custom Resources.
- Finalizer können hängen bleiben.
- PVCs und Secrets können verwaisen.

## Mandantenfähigkeit

Pro Namespace begrenzte Rechte bevorzugen. ClusterRole nur, wenn technisch zwingend erforderlich.

## Stop-Kriterien

- ClusterRole mit `*` ohne Begründung.
- kein Restore-Test.
- keine CRD-Versionierungsstrategie.
- keine Deinstallationsanleitung.
- keine Owner oder SLOs.

# Disaster-Recovery-Runbook

## Szenario 1: Restore eines Namespace

### Datenklassen

- Git-Zustand für Manifeste.
- Secrets aus Secret-Management.
- PVC-Daten aus VolumeSnapshots oder Backup.
- Custom Resources, falls CRDs beteiligt sind.

### Restore-Reihenfolge

1. Zielnamespace erstellen.
2. Quotas, RBAC, NetworkPolicies und Pod Security anwenden.
3. Secrets wiederherstellen.
4. PVCs oder VolumeSnapshots wiederherstellen.
5. Workloads per GitOps synchronisieren.
6. Service-, DNS- und Gateway-Pfade prüfen.
7. Smoke Tests durchführen.

### Validierung

- Pods Ready.
- Services mit Endpoints.
- App-Smoke-Test erfolgreich.
- PVC-Daten lesbar.

### RTO/RPO-Annahme

- RTO: 2 Stunden für Standardnamespace.
- RPO: 24 Stunden, abhängig von Backup-Frequenz.

## Szenario 2: Restore eines gesamten Clusters

### Datenklassen

- GitOps-Repositories.
- Cluster-Add-ons.
- etcd/Clusterzustand.
- CRDs und Custom Resources.
- Secrets.
- PVC-Daten.
- externe Systeme: DNS, Registry, Identity Provider, Datenbanken.

### Restore-Reihenfolge

1. Neuen Cluster bereitstellen oder etcd-Restore durchführen.
2. CNI, CoreDNS und CSI validieren.
3. CRDs installieren.
4. GitOps Controller installieren.
5. Plattform-Add-ons synchronisieren.
6. Tenant-Namespaces synchronisieren.
7. Secrets und PVC-Daten wiederherstellen.
8. Gateway/Ingress und DNS prüfen.
9. Smoke Tests und SLO-Prüfung durchführen.

### Evidence

- Backup-ID.
- Git-Revision.
- Restore-Start/-Ende.
- Smoke-Test-Ausgaben.
- Abweichungen und Nacharbeiten.

# Kostenanalyse

## Kostenquellen

| Quelle | Messpunkt | Maßnahme |
| --- | --- | --- |
| CPU/Memory Overrequesting | Requests vs. tatsächliche Nutzung | p95/p99-basiertes Rightsizing |
| Idle Workloads | Replikate ohne Traffic | Dev-Zeitfenster, Scale-to-zero prüfen |
| PVCs | PVC ohne aktive Pods | Owner prüfen, Snapshot, löschen |
| Load Balancer | Anzahl externer LBs | Shared Gateway/Ingress nutzen |
| Egress | Cloud Billing, Flow Logs | Datenpfade optimieren |
| Observability | Log-/Metric-Volumen | Retention und Sampling anpassen |

## Risiken von Underrequesting

Zu niedrige Requests können Scheduling, HPA, Stabilität und Latenz verschlechtern. Rightsizing bedeutet realistische Werte, nicht minimale Werte.

## Showback-Modell

Kosten werden nach Namespace-Labels `owner`, `cost-center`, `environment` und `app` ausgewertet.

## Maßnahmenplan

| Priorität | Maßnahme |
| --- | --- |
| 1 | Pflichtlabels und Kostenreports einführen |
| 2 | Top-Namespaces nach Overrequesting prüfen |
| 3 | ungenutzte PVCs und Load Balancer bereinigen |
| 4 | Dev-Workloads zeitgesteuert skalieren |
| 5 | Spot für fehlertolerante Worker prüfen |

# Betriebsübergabe Kubernetes-Plattform

## Plattformüberblick

- Modell: Managed Kubernetes.
- Umgebungen: dev, staging, production.
- GitOps: zentraler Controller pro Umgebung.
- Gateway/Ingress: zentral verwaltet.
- Observability: Metriken, Logs, Traces, Events.

## Kritische Add-ons

| Add-on | Owner | Runbook |
| --- | --- | --- |
| CNI | Plattform | runbooks/network.md |
| CoreDNS | Plattform | runbooks/coredns.md |
| CSI | Plattform | runbooks/storage.md |
| GitOps | Plattform | runbooks/gitops.md |
| Gateway/Ingress | Plattform | runbooks/ingress.md |

## Bekannte SLOs

- API Server und Plattformsignale gemäß Plattform-SLO.
- App-SLOs je Produktteam.

## Alarmwege

- Kritische Plattformalarme an Plattform-On-Call.
- App-Alarme an App-On-Call mit Plattform-Eskalation.

## Upgrade-Fenster

- Minor-Upgrades quartalsweise.
- Add-on-Upgrades nach Staging-Test.

## Backup und Restore

- Namespace-Restore und Cluster-Restore dokumentiert.
- Restore-Test mindestens quartalsweise.

## Top-5-Runbooks

1. CoreDNS-Störung.
2. CNI/NetworkPolicy-Störung.
3. CSI/PVC Pending.
4. GitOps Sync Failure.
5. Kubernetes Minor Upgrade.

## Stop-Kriterien

- API Server nicht stabil.
- CNI oder CoreDNS kritisch.
- CSI kann Volumes nicht bereitstellen.
- GitOps synchronisiert falschen Zielzustand.
- Backup oder Restore-Punkt fehlt vor kritischem Change.

## Offene Risiken

- Einige Legacy-Namespaces ohne Kostenlabel.
- Restore-Test für Cluster älter als 90 Tage.
- Zwei Add-ons ohne dokumentierten SLO.

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