Ziel dieses Übungsdokuments

Dieses Übungsdokument ergänzt den Professional-Workshop mit produktionsnahen Aufgaben. Der Schwerpunkt liegt auf Plattform-Blueprint, Betriebsmodell, Managed/Self-managed/Hybrid, Node Pools, Cluster Sizing, Upgrades, API Deprecations, Observability, Autoscaling, GitOps, Multi-Tenancy, Operatoren, CRDs, Backup, Disaster Recovery, Kostenmanagement und Runbooks.

Professional bedeutet hier: Du beweist nicht nur, dass eine Anwendung läuft. Du formulierst, wie eine Plattform für mehrere Teams betrieben, aktualisiert, beobachtet, skaliert, wiederhergestellt und kostenbewusst verantwortet wird.

Voraussetzungen

Du brauchst:

• einen Lab-Cluster oder simulierte Cluster-Kontexte
• kubectl
• optional Helm und Kustomize
• optional Metrics Server, Prometheus/Grafana oder eine bereitgestellte Observability-Umgebung
• optional GitOps-Controller wie Argo CD oder Flux
• optional Velero oder eine Backup-Demo

Empfohlener Arbeitsordner:

kubernetes/professional-exercises/
  platform-blueprint.md
  upgrade-runbook.md
  observability-slo.md
  autoscaling-review.md
  gitops-flow.md
  tenant-template/
  operator-review.md
  dr-runbook.md
  cost-review.md

Aufgabenübersicht

Teil A – Aufgaben

Aufgabe 1: Plattform-Blueprint erstellen

Ziel

Du beschreibst einen wiederholbaren Standard für einen produktionsnahen Kubernetes-Cluster.

Arbeitsauftrag

Erstelle platform-blueprint.md mit diesen Abschnitten:

1. Ziel der Plattform
2. Cluster-Modell: Shared Cluster oder Cluster pro Umgebung
3. Umgebungstrennung: Dev, Test, Stage, Prod
4. Verantwortlichkeiten: Plattformteam, App-Team, Security, Betrieb
5. Standard-Add-ons: CNI, CSI, CoreDNS, Ingress/Gateway, Metrics, Observability, GitOps, Backup
6. Namespace-Standard: Labels, Owner, RBAC, Quotas, LimitRanges, NetworkPolicy, Pod Security
7. Upgrade- und Deprecation-Prozess
8. Observability- und SLO-Modell
9. Backup- und Restore-Modell
10. Kostenmodell: Showback oder Chargeback

Erwartetes Ergebnis

Eine zweite Person kann aus dem Blueprint ableiten, wie ein neuer Cluster aufgebaut und betrieben werden soll.

Aufgabe 2: Managed, Self-managed und Hybrid bewerten

Ziel

Du triffst eine belastbare Plattformentscheidung und dokumentierst Trade-offs.

Arbeitsauftrag

Erstelle eine Entscheidungsmatrix für drei Szenarien:

1. Managed Kubernetes für Standard-Webanwendungen
2. Self-managed Kubernetes für hochspezialisierte Bare-Metal-Workloads
3. Hybrid-Modell für Cloud- und On-Premises-Anteile

Bewerte:

• Control-Plane-Verantwortung,
• Upgrade-Aufwand,
• Security-Verantwortung,
• Kosten- und Provider-Abhängigkeit,
• Betriebsrisiko,
• benötigte Teamfähigkeiten.

Aufgabe 3: Node Pools und Cluster Sizing planen

Ziel

Du planst Node Pools, Kapazitätspuffer und Add-on-Ressourcen für eine produktionsnahe Plattform.

Ausgangslage

Die Plattform soll folgende Workloads aufnehmen:

• 20 Standard-Webservices
• 5 CPU-intensive Worker
• 3 stateful Services mit PVC
• Observability-Stack
• Ingress/Gateway Controller
• GitOps Controller
• Backup Controller

Arbeitsauftrag

1. Entwirf mindestens drei Node Pools.
2. Plane System- und Add-on-Overhead.
3. Definiere Kapazitätspuffer für Rollouts und Node-Ausfälle.
4. Dokumentiere Cloud-Provider-Quotas, die geprüft werden müssen.
5. Schreibe Stop-Kriterien für Skalierung.

Aufgabe 4: Upgrade-Runbook mit API-Deprecation-Check schreiben

Ziel

Du planst ein Kubernetes-Minor-Upgrade als Change mit Validierung und Rollback-Pfad.

Arbeitsauftrag

Erstelle upgrade-runbook.md mit:

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

Aufgabe 5: Observability-Modell und SLO definieren

Ziel

Du beschreibst Observability nicht als Toolliste, sondern als Betriebsmodell mit Signalen, SLOs, Alerts und Runbooks.

Arbeitsauftrag

Definiere für eine Beispiel-App checkout-api:

• Service Level Objective,
• Service Level Indicator,
• Metriken,
• Logs,
• Traces,
• Kubernetes-Events,
• Dashboards,
• Alerts,
• Runbook-Link,
• Retention.

Ergänze auch Plattformsignale für API Server, CoreDNS, Ingress, Nodes und PVCs.

Aufgabe 6: Autoscaling bewerten

Ziel

Du ordnest HPA, VPA, Cluster Autoscaler, Karpenter und KEDA nach Zweck, Voraussetzung und Risiko ein.

Ausgangslage

Eine Queue-basierte Worker-Anwendung verarbeitet unregelmäßig Jobs. Tagsüber entstehen Lastspitzen. Nachts soll die Plattform Kosten sparen.

Arbeitsauftrag

1. Definiere CPU- und Memory-Requests.
2. Entwirf eine HPA-Strategie.
3. Entscheide, ob KEDA sinnvoll ist.
4. Beschreibe das Zusammenspiel mit Node-Autoscaling.
5. Formuliere Risiken wie Flapping, Kostenanstieg und fehlende Metriken.

Aufgabe 7: GitOps- und CI/CD-Fluss skizzieren

Ziel

Du trennst CI und GitOps sauber und vermeidest dauerhafte breite Clusterrechte in der CI-Pipeline.

Arbeitsauftrag

Erstelle gitops-flow.md mit einem Ablauf von:

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, welche Identität welche Rechte benötigt.

Aufgabe 8: Multi-Tenant Namespace-Template erstellen

Ziel

Du erstellst ein Namespace-Muster für ein Team, das begrenzt deployen kann, ohne Cluster-weite Rechte zu erhalten.

Arbeitsauftrag

Erstelle Manifeste für:

• Namespace mit Labels,
• ResourceQuota,
• LimitRange,
• Role,
• RoleBinding,
• NetworkPolicy Default Deny,
• Pod Security Labels,
• Owner-Annotation.

Dokumentiere, welche Kontrollen im Professional-Level nur vorbereitet und im Advanced-Level härter durchgesetzt werden.

Aufgabe 9: Operator und CRD bewerten

Ziel

Du bewertest, ob ein Operator betrieblich tragfähig ist.

Arbeitsauftrag

Wähle einen hypothetischen Operator database-operator und dokumentiere:

1. installierte CRDs,
2. benötigte ClusterRoles,
3. verwaltete Custom Resources,
4. Conditions und Events,
5. Backup-Relevanz,
6. Upgrade-Risiken,
7. Deinstallationsrisiken,
8. Mandantenfähigkeit,
9. Stop-Kriterien für Produktion.

Aufgabe 10: Backup und Disaster Recovery planen

Ziel

Du unterscheidest Git-Zustand, etcd, PVC-Daten, Secrets, CRDs und externe Systeme.

Arbeitsauftrag

Erstelle dr-runbook.md mit zwei Szenarien:

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

Für jedes Szenario beschreibst du:

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

Aufgabe 11: Kostenanalyse und Rightsizing durchführen

Ziel

Du analysierst Kostenfaktoren und formulierst technische Rightsizing-Maßnahmen.

Ausgangslage

Ein Cluster zeigt:

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

Arbeitsauftrag

Erstelle cost-review.md mit:

• Kostenquellen,
• technischen Messpunkten,
• Rightsizing-Empfehlungen,
• Risiken von Underrequesting,
• Showback-Modell,
• Maßnahmenplan.

Aufgabe 12: Betriebsübergabe vorbereiten

Ziel

Du erstellst eine Betriebsübergabe, die eine andere Person im Bereitschafts- oder Betriebskontext nutzen kann.

Arbeitsauftrag

Erstelle eine kurze Übergabe mit:

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

Teil B – Musterlösungen und Walkthroughs

Lösung 1: Plattform-Blueprint

Musterstruktur:

# Plattform-Blueprint

## 1. Ziel

Die Plattform stellt standardisierte Kubernetes-Umgebungen für mehrere Anwendungsteams bereit. Sie bietet sichere Namespaces, GitOps-basiertes Deployment, zentrale Observability, Ingress/Gateway, Storage, Backup und dokumentierte Upgrade-Prozesse.

## 2. Cluster-Modell

- Dev/Test: Shared Cluster mit Namespace-Isolation.
- Stage/Prod: getrennte Cluster pro Kritikalität oder Umgebung.
- Prod-Cluster über mindestens drei Availability Zones.

## 3. Verantwortlichkeiten

| Bereich | Owner |
| --- | --- |
| Control Plane | Provider oder Plattformteam |
| Nodes und Node Pools | Plattformteam |
| CNI/CSI/CoreDNS | Plattformteam |
| Namespace-Inhalte | Anwendungsteam |
| Security Policies | Plattformteam + Security |
| App-SLOs | Anwendungsteam |
| Plattform-SLOs | Plattformteam |

## 4. Standard-Add-ons

| Add-on | Zweck | Owner | SLO |
| --- | --- | --- | --- |
| CNI | Pod-Netzwerk und NetworkPolicy | Plattform | Pod-Netz verfügbar |
| CSI | PV-Provisionierung | Plattform | PVC-Provisionierung stabil |
| CoreDNS | Service Discovery | Plattform | DNS-Latenz und Fehlerrate |
| Ingress/Gateway | externer HTTP-Zugriff | Plattform | 99.9% Routing-Verfügbarkeit |
| Observability | Metrics/Logs/Traces/Events | Plattform | Signalverfügbarkeit |
| GitOps | Desired State Sync | Plattform | Sync zuverlässig |
| Backup | Restore-Fähigkeit | Plattform | Restore getestet |

## 5. Namespace-Standard

Jeder Tenant-Namespace erhält:

- Owner-Labels,
- ResourceQuota,
- LimitRange,
- Role/RoleBinding,
- Default-Deny-NetworkPolicy,
- Pod-Security-Labels,
- Kostenlabel.

## 6. Lifecycle

- monatlicher Deprecation-Scan,
- quartalsweises Kubernetes-Minor-Upgrade-Fenster,
- Staging-Test vor Prod,
- dokumentierte Stop-Kriterien,
- Smoke Tests nach jedem Upgrade-Schritt.

Bewertung:

Ein guter Blueprint ist nicht toolfixiert. Er beschreibt Owner, SLOs, Upgrade-Pfade, Isolation, Kosten und Wiederherstellung.

Lösung 2: Managed, Self-managed und Hybrid

Musterentscheidung:

Musterbewertung:

• Managed Kubernetes ist Standard für die meisten Webanwendungen, wenn Providergrenzen akzeptiert werden.
• Self-managed ist nur sinnvoll, wenn spezielle Anforderungen die Zusatzkomplexität rechtfertigen.
• Hybrid ist kein Kompromiss ohne Kosten; es erhöht Governance-, Netzwerk- und Betriebsaufwand.

Lösung 3: Node Pools und Sizing

Muster-Node-Pools:

Sizing-Checkliste:

• Summe App-Requests plus DaemonSet-Overhead.
• Platz für Rolling Updates: mindestens zusätzliche Kapazität für neue Pods während Rollout.
• Platz für Zonenausfall oder Node-Ausfall, abhängig von SLA.
• CoreDNS, Logging, Metrics und Ingress nicht mit Minimalwerten aus kleinen Clustern betreiben.
• Cloud-Quotas für Compute, IPs, Volumes, Load Balancer, Firewall-Regeln und Egress prüfen.

Stop-Kriterien:

• Cluster Autoscaler kann keine Nodes mehr hinzufügen.
• IP-Adressraum erschöpft.
• CoreDNS oder CNI zeigt hohe Fehlerrate.
• Pods bleiben wegen Ressourcen Pending.
• Add-ons laufen in OOMKill oder CPU-Throttling.

Lösung 4: Upgrade-Runbook

Musterinhalt:

# Upgrade-Runbook

## Ziel

Upgrade von Kubernetes v1.x auf v1.y.

## Vorprüfung

- kubectl version
- kubectl get nodes -o wide
- kubectl get pods -A
- kubectl get apiservices
- kubectl get crds
- kubectl get validatingwebhookconfigurations,mutatingwebhookconfigurations

## API-Deprecation-Check

- Git-Repositories nach alten API-Versionen scannen.
- Helm Charts rendern und prüfen.
- Kustomize Overlays rendern und prüfen.
- CRD-Versionen und Conversion Webhooks prüfen.

## Backup

- etcd-Backup oder Provider-Snapshot.
- Velero/Namespace-Backup, falls vorhanden.
- PV-Snapshots für stateful Workloads.
- GitOps-Repository-Revision festhalten.

## Reihenfolge

1. Change ankündigen.
2. Staging testen.
3. Control Plane upgraden.
4. Add-ons validieren.
5. Node Pool einzeln upgraden.
6. Pro Node: cordon, drain, upgrade, uncordon.
7. Smoke Tests.
8. Abschlussreport.

## Stop-Kriterien

- API Server Error Rate erhöht.
- CoreDNS nicht stabil.
- CNI/CSI inkompatibel.
- kritische Workloads nicht Ready.
- Webhook blockiert Deployments.
- Deprecation-Fund nicht behoben.

Beispielbefehle:

kubectl api-resources
kubectl api-versions
kubectl get apiservices
kubectl get crds
kubectl get events -A --sort-by=.metadata.creationTimestamp
kubectl drain <node> --ignore-daemonsets --delete-emptydir-data
kubectl uncordon <node>

Lösung 5: Observability und SLO

Muster-SLO:

# Observability-SLO checkout-api

## SLO

99.9% der HTTP-Requests auf `/checkout` sind innerhalb von 300 ms erfolgreich über ein 30-Tage-Fenster.

## SLI

- Erfolgsrate: HTTP 2xx/3xx geteilt durch alle Requests ohne explizit ausgeschlossene 4xx.
- Latenz: p95 Request Duration.

## Signale

| Signal | Quelle | Zweck |
| --- | --- | --- |
| Request Rate | Ingress/App Metrics | Lastbild |
| Error Rate | App/Ingress Metrics | Verfügbarkeit |
| Duration p95/p99 | App/Ingress Metrics | Latenz |
| Logs | App Logs | Ursachenanalyse |
| Traces | OpenTelemetry | Abhängigkeitsanalyse |
| Events | Kubernetes API | Scheduling, Probe, Pull, PVC |
| Resource Usage | cAdvisor/kubelet | CPU/Memory/Throttling |

## 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.

## Runbooks

- checkout-api-high-error-rate.md
- checkout-api-latency.md
- checkout-api-rollout-failure.md

Plattformsignale:

Lösung 6: Autoscaling

Musterbewertung:

Muster-HPA:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: worker
  namespace: worker-prod
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: worker
  minReplicas: 2
  maxReplicas: 30
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 300

Musterentscheidung:

Für Queue-basierte Last ist KEDA fachlich oft besser als reine CPU-Skalierung, weil Queue-Länge direkter das Arbeitspensum abbildet. HPA kann ergänzend sinnvoll sein, wenn CPU pro Job stark schwankt.

Lösung 7: GitOps und CI/CD

Musterfluss:

Code Commit
  -> CI baut Image
  -> CI führt Tests und Scan aus
  -> CI pusht Image in Registry
  -> CI ermittelt Image-Digest
  -> CI erstellt Pull Request im Manifest-Repo
  -> Review prüft Manifest, Policy und Diff
  -> Merge aktualisiert gewünschten Zustand
  -> GitOps Controller synchronisiert Cluster
  -> Drift Detection meldet Abweichungen
  -> Rollback erfolgt per Git Revert

Rechte:

Stop-Kriterium:

Die CI-Pipeline erhält keine dauerhaften Cluster-Admin-Rechte. Der Clusterzustand wird über GitOps synchronisiert, nicht durch imperative CI-Deployments.

Lösung 8: Multi-Tenant Namespace

Namespace:

apiVersion: v1
kind: Namespace
metadata:
  name: team-a
  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:

apiVersion: v1
kind: ResourceQuota
metadata:
  name: team-a-quota
  namespace: team-a
spec:
  hard:
    pods: "20"
    requests.cpu: "4"
    requests.memory: 8Gi
    limits.cpu: "8"
    limits.memory: 16Gi
    persistentvolumeclaims: "5"

LimitRange:

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

Role und RoleBinding:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: app-deployer
  namespace: team-a
rules:
  - apiGroups: ["", "apps", "batch", "networking.k8s.io"]
    resources: ["pods", "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
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:

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

Professional-Abgrenzung:

• Professional modelliert Tenant-Governance.
• Advanced + Security prüft harte RBAC-Eskalationspfade, Admission Enforcement, Secrets, Threat Model und Incident Response.

Lösung 9: Operator-Review

Musterreview:

# Operator-Review: database-operator

## Zweck

Automatisiert Datenbank-Instanzen über Custom Resources.

## CRDs

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

## Rechte

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

## Conditions

- Ready
- Progressing
- Degraded
- BackupReady
- RestoreFailed

## Backup

Custom Resources allein reichen nicht. PVC-Daten, Secrets und externe Backups müssen einbezogen werden.

## Upgrade-Risiken

- CRD-Schemaänderungen
- Conversion Webhooks
- finalizer blockieren Löschung
- Operator-Image nicht kompatibel
- alte Custom Resources nicht migrierbar

## Stop-Kriterien

- unklare ClusterRole mit `*`
- kein dokumentierter Restore-Test
- keine CRD-Versionierungsstrategie
- keine Deinstallationsanleitung
- keine Mandantenfähigkeit

Lösung 10: Backup und DR

Namespace-Restore:

# Namespace-Restore

## Datenklassen

- Manifeste aus Git
- Secrets aus Secret-Management
- PVC-Daten aus Volume-Snapshot oder Backup
- CRDs, falls Namespace Custom Resources enthält

## Reihenfolge

1. Zielnamespace erstellen.
2. Quotas, RBAC und Policies anwenden.
3. Secrets wiederherstellen.
4. PVCs oder VolumeSnapshots wiederherstellen.
5. Workloads aus GitOps synchronisieren.
6. Service- und Ingress/Gateway-Pfade prüfen.
7. Smoke Tests durchführen.

## Evidence

- Restore-Zeitpunkt
- Git-Revision
- Backup-ID
- erfolgreiche Smoke Tests
- offene Abweichungen

Cluster-Restore:

# Cluster-Restore

## Datenklassen

- Cluster-Add-ons
- CRDs
- Namespaces
- RBAC
- Secrets
- PV/PVC-Daten
- externe Systeme: DNS, Registry, Identity Provider

## Reihenfolge

1. neuen Cluster bereitstellen oder etcd-Restore durchführen.
2. CNI, CSI, CoreDNS validieren.
3. CRDs installieren.
4. GitOps Controller installieren.
5. Plattform-Namespaces synchronisieren.
6. Tenant-Namespaces synchronisieren.
7. PV-Daten wiederherstellen.
8. Ingress/DNS validieren.
9. SLO-Smoke-Tests durchführen.

Wichtige Aussage:

Ein Backup ist erst belastbar, wenn ein Restore-Test durchgeführt und dokumentiert wurde.

Lösung 11: Kostenanalyse und Rightsizing

Musteranalyse:

Muster-Showback:

Jeder Namespace braucht Labels:

metadata:
  labels:
    owner: team-a
    cost-center: cc-1234
    environment: prod

Risiko von Underrequesting:

Zu niedrige Requests sparen scheinbar Kosten, können aber Scheduling, HPA, Node-Auslastung und Stabilität verschlechtern. Rightsizing bedeutet nicht „Requests auf Minimum setzen“, sondern realistische Betriebswerte festlegen.

Lösung 12: Betriebsübergabe

Musterübergabe:

# Betriebsübergabe Kubernetes-Plattform

## Überblick

- Cluster: prod-eu-1
- Modell: Managed Kubernetes
- Umgebungen: stage/prod getrennt
- GitOps: Argo CD
- Ingress: Gateway Controller
- Observability: Prometheus, Grafana, Loki, OpenTelemetry

## Kritische Add-ons

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

## Stop-Kriterien

- API Server nicht erreichbar.
- CoreDNS Fehlerrate kritisch.
- CNI blockiert Pod-Netzwerk.
- CSI kann keine Volumes attachen.
- GitOps synchronisiert falschen Zielzustand.

## Offene Risiken

- Restore-Test für Cluster zuletzt vor mehr als 90 Tagen.
- Einige Namespaces ohne Kostenlabel.
- Zwei alte API-Versionen in Legacy-Chart gefunden.

Bewertungscheckliste