1. Ziel und Abgrenzung

1.1. Ziel

Nach dieser Unterlage kannst du einen Kubernetes-Cluster nicht nur starten, sondern betrieblich führen. Dazu gehören:

• du erkennst Cluster-, Node-, Netzwerk-, Storage- und Workload-Probleme frühzeitig,
• du führst Änderungen kontrolliert und rückbaubar durch,
• du sicherst Cluster-Zustand, Anwendungsdaten, Konfiguration, Zertifikate und Betriebsartefakte,
• du testest Restore- und Disaster-Recovery-Abläufe regelmäßig,
• du patchst Betriebssysteme, Container Runtimes, Kubernetes-Komponenten und Add-ons,
• du planst Kubernetes-Minor- und Patch-Upgrades ohne unnötige Ausfallrisiken,
• du betreibst Monitoring, Logging, Tracing und Alerting als zusammenhängendes Observability-System,
• du unterscheidest lokale Lab-Umgebungen, selbst betriebene Cluster und Managed Kubernetes.

1.2. Abgrenzung

Dieses Dokument ersetzt keine Provider-spezifische Produktdokumentation und keine unternehmensinterne Betriebsanweisung. Es liefert aber ein belastbares Referenzmodell und konkrete Runbooks, die du auf folgende Umgebungen übertragen kannst:

• WSL2 unter Windows 11,
• kind, minikube und k3d,
• VirtualBox, VMware Workstation, VMware Fusion und Vagrant-VMs,
• gemietete Remote-VMs,
• Bare Metal,
• kubeadm-Cluster,
• k3s, RKE2, k0s und Talos,
• Managed Kubernetes wie EKS, AKS, GKE, DOKS, LKE, OKE, IKS und OpenShift-basierte Plattformen.

1.3. Grundannahmen

• Der autoritative gewünschte Zustand liegt in Git, einem IaC-Repository, einem GitOps-Repository oder einer gleichwertig versionierten Quelle.
• Änderungen werden nicht direkt im Produktivcluster ausprobiert.
• Ein Backup gilt erst als brauchbar, wenn mindestens ein Restore-Test erfolgreich war.
• Monitoring ohne Alerting ist nur Sichtbarkeit. Alerting ohne Runbook erzeugt Lärm. Logging ohne Such- und Aufbewahrungskonzept ist kein Betriebskonzept.
• Day-2 Operations sind nicht nur Technik. Sie bestehen aus Prozessen, Verantwortlichkeiten, Zeitfenstern, Kommunikationswegen und Nachweisen.

2. Day-2-Betriebsmodell

2.1. Was Day-2 Operations bedeutet

Day-0 ist Planung. Day-1 ist Provisionierung. Day-2 ist Betrieb. In Kubernetes umfasst Day-2 Operations alle wiederkehrenden und ereignisgetriebenen Aufgaben nach der initialen Bereitstellung.

2.2. Betriebsprinzipien

1. Erst beobachten, dann ändern. Erfasse den Ausgangszustand, bevor du handelst.
2. Jede Änderung braucht einen Rückweg. Der Rückweg kann Rollback, Restore, Rebuild oder Deaktivierung sein.
3. Cluster-Zustand ist nicht gleich Anwendungszustand. Kubernetes-Objekte und persistente Daten müssen getrennt betrachtet werden.
4. Automatisierung ersetzt kein Verständnis. Automatisierte Upgrades, GitOps und Autoscaler brauchen Grenzen, Alerts und Runbooks.
5. Provider nehmen dir Aufgaben ab, aber nicht Verantwortung. Managed Kubernetes reduziert Control-Plane-Betrieb, lässt aber Workloads, Add-ons, Kosten, Security, Backups und Abhängigkeiten bei dir.

2.3. Serviceklassen

Nicht jede Umgebung braucht denselben Betriebsaufwand. Definiere Serviceklassen, bevor du Runbooks und SLAs versprichst.

2.4. RTO, RPO und Betriebsziele

Wichtig: Ein Kubernetes-Backup ohne RTO/RPO-Aussage ist nur eine technische Aktivität. Erst mit Wiederherstellungsziel, Testintervall und Verantwortlichkeit wird daraus ein Betriebskonzept.

3. Betriebsarchitektur

3.1. Gesamtbild

flowchart TD
    Users[Benutzer und Systeme] --> Edge[DNS, Load Balancer, Ingress, Gateway]
    Edge --> Services[Kubernetes Services]
    Services --> Workloads[Pods und Workloads]
    Workloads --> Storage[Persistenter Storage]
    Workloads --> Config[ConfigMaps, Secrets, externe Konfiguration]

    Operators[Platform / SRE / DevOps] --> Git[Git, IaC, GitOps]
    Git --> CD[CI/CD oder GitOps Controller]
    CD --> API[Kubernetes API Server]
    API --> State[etcd / Managed Control Plane State]
    API --> Controllers[Controller, Scheduler, Operatoren]
    Controllers --> Workloads

    Workloads --> Logs[Logs]
    Workloads --> Metrics[Metriken]
    Workloads --> Traces[Traces]
    API --> Audit[Audit Logs]
    Logs --> Obs[Observability Backend]
    Metrics --> Obs
    Traces --> Obs
    Audit --> Obs
    Obs --> Alerts[Alertmanager / Cloud Alerts / On-Call]
    Alerts --> Operators

    State --> Backup[Backups]
    Storage --> Backup
    Git --> Backup
    Backup --> Restore[Restore und DR]
    Restore --> API

3.2. Operations-Kreislauf

flowchart LR
    Plan[Planen] --> Change[Änderung vorbereiten]
    Change --> Validate[Dry-Run, Tests, Policy-Checks]
    Validate --> Execute[Ausführen]
    Execute --> Observe[Überwachen]
    Observe --> Decide{Ziel erreicht?}
    Decide -- Ja --> Document[Dokumentieren]
    Decide -- Nein --> Mitigate[Rollback, Rollforward oder Restore]
    Mitigate --> Observe
    Document --> Improve[Runbook verbessern]
    Improve --> Plan

3.3. Drei Zustandsebenen

flowchart TD
    Desired[Gewünschter Zustand: Git, Helm, Kustomize, Terraform, Crossplane] --> API[Kubernetes API]
    API --> Cluster[Cluster-Zustand: etcd, API-Objekte, Controller-Status]
    Cluster --> Runtime[Laufzeitzustand: Pods, Container, Volumes, Netzwerk]
    Runtime --> Data[Datenzustand: Datenbanken, PVCs, Objekt-Storage, externe Systeme]
    Data --> Backup[Backup und Replikation]
    Backup --> Restore[Restore-Test]
    Restore --> Desired

Betrieb ist stabil, wenn alle drei Ebenen verstanden werden:

• Desired State: Was soll laufen?
• Cluster State: Was glaubt Kubernetes, was laufen soll?
• Runtime/Data State: Was läuft tatsächlich, und welche Daten sind kritisch?

4. Umgebungsmatrix

4.1. Umgebungstypen

4.2. Entscheidungsmatrix für Betriebsaufwand

4.3. Nicht jedes Lab braucht produktive Komplexität

Für Workshops ist es sinnvoll, Konzepte zu zeigen, ohne künstlich produktive Betriebsprozesse zu erzwingen. Du kannst die gleiche Struktur nutzen, aber die Tiefe anpassen:

• kind/k3d: Rebuild ist oft schneller und sauberer als Restore.
• minikube: Profil löschen und neu erstellen ist oft der beste Rückbau.
• WSL: Betrieb konzentriert sich auf Tooling, Port-Zugriff, lokale Hosts-Datei und saubere Dateisystemtrennung.
• VM/Bare Metal/kubeadm: echte Backups, etcd-Snapshots, Node-Wartung und Upgrade-Reihenfolge sind relevant.
• Managed Kubernetes: Provider übernimmt Teile der Control Plane; du bleibst verantwortlich für Workloads, Add-ons, Security, Observability, Daten und Kosten.

5. Verantwortungsmodell

5.1. Selbst betrieben vs. Managed Kubernetes

flowchart TD
    subgraph Self[Selbst betriebener Cluster]
      A1[Control Plane] --> A2[etcd]
      A2 --> A3[Nodes]
      A3 --> A4[CNI, CSI, Ingress]
      A4 --> A5[Workloads]
      A5 --> A6[Backups und Monitoring]
    end

    subgraph Managed[Managed Kubernetes]
      P1[Provider Control Plane] --> P2[Provider Upgrades]
      P2 --> P3[Node Pools]
      P3 --> P4[Add-ons]
      P4 --> P5[Workloads]
      P5 --> P6[Backups und Monitoring]
    end

5.2. RACI-Vorlage

Legende: A = Accountable, R = Responsible, C = Consulted, I = Informed.

6. Betriebsgrundlagen vor dem ersten Incident

6.1. Mindeststandard pro Cluster

Ein Cluster ist nicht betriebsbereit, nur weil kubectl get nodes grün aussieht. Für Day-2 Operations brauchst du mindestens:

• dokumentierte Cluster-ID, Umgebung, Owner, Kritikalität und Kostenstelle,
• unterstützte Kubernetes-Version und Upgrade-Zielpfad,
• funktionierende kubeconfig mit rollenbasiertem Zugriff,
• Git-Repository für Manifeste, Helm-Values, Kustomize-Overlays oder GitOps,
• definierte Namespaces und Verantwortliche,
• Resource Requests, Limits, Quotas und LimitRanges,
• Liveness-, Readiness- und Startup-Probes für relevante Workloads,
• PodDisruptionBudgets für hochverfügbare Workloads,
• NetworkPolicies für Mandantentrennung und Default-Deny-Modelle,
• zentrale Metriken, Logs und Events,
• Alerts mit Severity, Runbook-Link und Owner,
• Backup-Plan mit Aufbewahrung und Restore-Test,
• Upgrade- und Wartungsfenster,
• Rückbau- und Kostenkontrolle.

6.2. Cluster-Inventar

Führe ein Inventar. Es kann als Markdown, CMDB, Terraform-Output, Backstage-Katalog oder GitOps-Metadaten gepflegt werden.

6.3. Kubeconfig- und Zugriffskonzept

• Nutze getrennte Kontexte für dev, stage und prod.
• Vergib keinen dauerhaften Cluster-Admin-Zugriff für Alltagsarbeit.
• Nutze kubectl auth can-i, bevor du Berechtigungen ausweitest.
• Prüfe, ob kubeconfig-Dateien in Repositories, Tickets, Chatverläufen oder Artefakten landen.
• Verwende kurzlebige Tokens, OIDC, Cloud IAM oder zentrale Identitäten, wo möglich.

kubectl config get-contexts
kubectl config current-context
kubectl auth can-i get pods -A
kubectl auth can-i '*' '*' --as system:serviceaccount:demo:app
kubectl get clusterrolebinding -o wide

6.4. Namespace-Baseline

Jeder produktionsnahe Namespace sollte eine Baseline haben:

• Owner-Label,
• Umgebung-Label,
• ResourceQuota,
• LimitRange,
• Pod Security Admission Label,
• NetworkPolicy Default Deny,
• optionale Egress-Policy,
• ServiceAccount pro Anwendung,
• Runbook-Link als Annotation.

apiVersion: v1
kind: Namespace
metadata:
  name: demo
  labels:
    environment: stage
    owner: team-platform
    pod-security.kubernetes.io/enforce: baseline
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted
  annotations:
    runbook.example.com/url: https://runbooks.example.local/kubernetes/demo
---
apiVersion: v1
kind: ResourceQuota
metadata:
  name: demo-quota
  namespace: demo
spec:
  hard:
    requests.cpu: "4"
    requests.memory: 8Gi
    limits.cpu: "8"
    limits.memory: 16Gi
    pods: "40"
    persistentvolumeclaims: "10"
---
apiVersion: v1
kind: LimitRange
metadata:
  name: demo-defaults
  namespace: demo
spec:
  limits:
    - type: Container
      defaultRequest:
        cpu: 100m
        memory: 128Mi
      default:
        cpu: 500m
        memory: 512Mi
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: demo
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress

7. Standard-Runbook für jede Änderung

7.1. Ablauf

1. Scope festlegen: Cluster, Namespace, Workload, Add-on, Node Pool oder Provider-Ressource.
2. Risiko bewerten: Auswirkung, Downtime, Datenverlust, Sicherheitsrisiko, Kostenrisiko.
3. Ausgangszustand erfassen: Versionen, Pods, Events, Metriken, Logs, Backups, offene Alerts.
4. Backup prüfen: Muss vor der Änderung ein Backup oder Snapshot erzeugt werden?
5. Änderung vorbereiten: Manifest, Helm-Values, Terraform-Plan, CLI-Befehl, GitOps-PR.
6. Validierung vorab: kubectl diff, --dry-run=server, Helm Template, Policy Checks, Staging-Test.
7. Kommunikation: Wartungsfenster, Betroffene, On-Call, Rollback-Entscheider.
8. Ausführen: Änderung in kleinen Schritten durchführen.
9. Beobachten: Rollout, Events, Logs, SLOs, Fehlerquoten, Latenz, Ressourcen, Kosten.
10. Entscheiden: Stabil, Rollforward, Rollback, Restore oder Incident.
11. Dokumentieren: Ergebnis, Abweichungen, neue Risiken, Verbesserungen am Runbook.

7.2. Vorher-/Nachher-Kommandos

# Kontext und Version
kubectl config current-context
kubectl version
kubectl get nodes -o wide

# Clusterzustand
kubectl get componentstatuses 2>/dev/null || true
kubectl get --raw='/readyz?verbose' 2>/dev/null || true
kubectl get --raw='/livez?verbose' 2>/dev/null || true
kubectl get pods -A -o wide
kubectl get events -A --sort-by=.lastTimestamp | tail -100

# Zielnamespace
NS=demo
kubectl get all -n "$NS" -o wide
kubectl get deploy,sts,ds,job,cronjob -n "$NS"
kubectl get configmap,secret,sa,role,rolebinding -n "$NS"
kubectl get pvc -n "$NS"

# Validierung eines Manifests
kubectl apply --dry-run=server -f manifest.yaml
kubectl diff -f manifest.yaml

# Nachher
kubectl rollout status deployment/demo -n "$NS" --timeout=180s
kubectl get pods -n "$NS" -o wide
kubectl get events -n "$NS" --sort-by=.lastTimestamp | tail -50

7.3. Änderungsarten

8. Tages-, Wochen- und Monatsroutinen

8.1. Tägliche Routine

kubectl get nodes -o wide
kubectl get pods -A --field-selector=status.phase!=Running
kubectl get events -A --sort-by=.lastTimestamp | tail -80
kubectl top nodes 2>/dev/null || echo "metrics-server nicht verfügbar"
kubectl get volumesnapshot -A 2>/dev/null || true
velero backup get 2>/dev/null || true

8.2. Wöchentliche Routine

• Review der Top-Alerts und häufigsten Events.
• Prüfen veralteter Images und Add-on-Versionen.
• Prüfen von Pods ohne Requests/Limits.
• Prüfen von Namespaces ohne Quotas und NetworkPolicies.
• Prüfen von PVCs mit hoher Auslastung.
• Test eines repräsentativen Restores in einer nichtproduktiven Umgebung.
• Review von Kosten, nicht genutzten LoadBalancern, PVs und Node Pools.
• Prüfung von Zertifikatsablaufzeiten.

kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.namespace}{"/"}{.metadata.name}{" "}{range .spec.containers[*]}{.name}{":cpu="}{.resources.requests.cpu}{",mem="}{.resources.requests.memory}{" "}{end}{"
"}{end}'
kubectl get networkpolicy -A
kubectl get resourcequota -A
kubectl get limitrange -A
kubectl get certificates -A 2>/dev/null || true
kubectl get ingress -A
kubectl get svc -A --field-selector spec.type=LoadBalancer 2>/dev/null || kubectl get svc -A

8.3. Monatliche Routine

• Kubernetes-Release- und Provider-Hinweise prüfen.
• Minor-/Patch-Upgrade-Plan aktualisieren.
• DR-Runbook gegen eine Testumgebung ausführen.
• RBAC- und ServiceAccount-Review durchführen.
• Backup-Aufbewahrung und Verschlüsselung prüfen.
• Dashboard- und Alert-Relevanz prüfen.
• Kapazitätsprognose und Kostenentwicklung bewerten.
• CRDs, Webhooks und Operatoren auf Versions- und API-Kompatibilität prüfen.
• Node-Images, Kernel und Container Runtime patchen oder Node Pools rotieren.

8.4. Quartalsroutine

• vollständiger Restore-Test eines produktionsnahen Workloads,
• Incident-Drill mit realistischen Symptomen,
• Review der RTO/RPO-Ziele,
• Review von Notfallzugängen und Break-Glass-Prozessen,
• Review von Audit-Logs und Security Findings,
• Upgrade-Probe für den nächsten Kubernetes-Minor-Release,
• Prüfung, ob veraltete API-Versionen entfernt werden müssen.

9. Cluster-Gesundheit und Triage

9.1. Schnelle Triage in 5 Minuten

# 1. Kontext absichern
kubectl config current-context

# 2. Nodes und Versionen
kubectl get nodes -o wide
kubectl version

# 3. Problematische Pods
kubectl get pods -A --field-selector=status.phase!=Running
kubectl get pods -A | egrep 'CrashLoopBackOff|ImagePullBackOff|ErrImagePull|Pending|Evicted|OOMKilled|CreateContainerConfigError' || true

# 4. Events
kubectl get events -A --sort-by=.lastTimestamp | tail -120

# 5. Control Plane Readiness
kubectl get --raw='/readyz?verbose' 2>/dev/null || true
kubectl get --raw='/livez?verbose' 2>/dev/null || true

# 6. Ressourcen
kubectl top nodes 2>/dev/null || true
kubectl top pods -A 2>/dev/null || true

# 7. Add-ons
kubectl get pods -n kube-system -o wide

9.2. Control-Plane-Gesundheit

Bei Managed Kubernetes ist die Control Plane nur eingeschränkt sichtbar. Bei kubeadm, Bare Metal, VM und Remote-VM prüfst du zusätzlich Systemdienste und statische Pods.

# kubeadm / selbst betriebene Control Plane
sudo crictl ps | egrep 'kube-apiserver|kube-controller-manager|kube-scheduler|etcd'
sudo crictl logs $(sudo crictl ps --name kube-apiserver -q | head -1)
sudo journalctl -u kubelet -n 200 --no-pager
sudo ls -l /etc/kubernetes/manifests
sudo ls -l /var/lib/etcd

# API intern prüfen
kubectl get --raw='/readyz?verbose'
kubectl get --raw='/livez?verbose'
kubectl get --raw='/metrics' | head

9.3. Node-Gesundheit

NODE=<node-name>
kubectl describe node "$NODE"
kubectl get pods -A -o wide --field-selector spec.nodeName="$NODE"
kubectl top node "$NODE" 2>/dev/null || true

# Auf dem Node
sudo systemctl status kubelet --no-pager
sudo journalctl -u kubelet -n 200 --no-pager
sudo crictl ps -a
sudo crictl images
sudo crictl stats
sudo df -h
sudo free -h
sudo ip route
sudo ss -tulpn

9.4. Events richtig lesen

Events sind kurzlebige Betriebsindikatoren. Sie ersetzen keine Logs, aber sie zeigen häufig die Ursache:

10. Workload-Betrieb

10.1. Produktionsfähiger Workload-Mindeststandard

Ein Workload ist betriebsfähig, wenn er mindestens folgende Punkte erfüllt:

• Deployment, StatefulSet, DaemonSet, Job oder CronJob ist bewusst gewählt.
• Container-Images sind versioniert und nicht nur latest.
• Requests und Limits sind gesetzt.
• Readiness-Probe schützt Traffic.
• Liveness-Probe ist nicht aggressiver als die Anwendung verträgt.
• Startup-Probe schützt langsam startende Anwendungen.
• Graceful Shutdown ist über terminationGracePeriodSeconds und Signalbehandlung abgedeckt.
• PodDisruptionBudget schützt vor freiwilligen Unterbrechungen.
• ConfigMaps und Secrets sind getrennt.
• Logs gehen auf stdout/stderr und enthalten keine Secrets.
• ServiceAccount hat minimale Rechte.
• SecurityContext ist gesetzt.
• Rollout und Rollback sind getestet.

10.2. Beispiel: betriebsfähiges Deployment

apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo-api
  namespace: demo
  labels:
    app.kubernetes.io/name: demo-api
    app.kubernetes.io/part-of: workshop
spec:
  replicas: 3
  revisionHistoryLimit: 5
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 1
  selector:
    matchLabels:
      app.kubernetes.io/name: demo-api
  template:
    metadata:
      labels:
        app.kubernetes.io/name: demo-api
    spec:
      serviceAccountName: demo-api
      terminationGracePeriodSeconds: 30
      securityContext:
        runAsNonRoot: true
        seccompProfile:
          type: RuntimeDefault
      containers:
        - name: app
          image: ghcr.io/example/demo-api:1.2.3
          imagePullPolicy: IfNotPresent
          ports:
            - name: http
              containerPort: 8080
          envFrom:
            - configMapRef:
                name: demo-api-config
          resources:
            requests:
              cpu: 100m
              memory: 128Mi
            limits:
              cpu: 500m
              memory: 512Mi
          startupProbe:
            httpGet:
              path: /health/startup
              port: http
            failureThreshold: 30
            periodSeconds: 2
          readinessProbe:
            httpGet:
              path: /health/ready
              port: http
            periodSeconds: 5
            timeoutSeconds: 2
          livenessProbe:
            httpGet:
              path: /health/live
              port: http
            periodSeconds: 10
            timeoutSeconds: 2
          securityContext:
            allowPrivilegeEscalation: false
            readOnlyRootFilesystem: true
            capabilities:
              drop: ["ALL"]
---
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: demo-api
  namespace: demo
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app.kubernetes.io/name: demo-api

10.3. Rollout überwachen

NS=demo
APP=demo-api
kubectl rollout status deployment/$APP -n $NS --timeout=180s
kubectl rollout history deployment/$APP -n $NS
kubectl get rs -n $NS -l app.kubernetes.io/name=$APP
kubectl get pods -n $NS -l app.kubernetes.io/name=$APP -o wide
kubectl logs deployment/$APP -n $NS --all-containers --tail=100

10.4. Rollback durchführen

NS=demo
APP=demo-api
kubectl rollout undo deployment/$APP -n $NS
kubectl rollout status deployment/$APP -n $NS --timeout=180s
kubectl rollout history deployment/$APP -n $NS

Bei GitOps ist ein manueller Rollback im Cluster nur eine Sofortmaßnahme. Danach musst du den autoritativen Zustand in Git korrigieren, sonst reconciled GitOps die fehlerhafte Änderung erneut.

10.5. Workload-Drift prüfen

# Serverzustand exportieren, ohne laufzeitgenerierte Felder zu vertrauen
kubectl get deployment demo-api -n demo -o yaml

# Gegen Git prüfen
kubectl diff -f k8s/overlays/stage/

# Argo CD
argocd app get demo-api
argocd app diff demo-api

# Flux
flux get kustomizations -A
flux diff kustomization demo-api --path ./clusters/stage/demo-api

11. Monitoring-Konzept

11.1. Zielbild

Monitoring soll nicht möglichst viele Graphen erzeugen. Es soll beantworten:

• Ist der Cluster erreichbar?
• Sind kritische Workloads verfügbar?
• Verbrauchen Nodes, Pods oder PVCs kritische Ressourcen?
• Droht ein SLO-Verstoß?
• Sind Backups aktuell?
• Hängen Rollouts oder GitOps-Syncs?
• Funktionieren DNS, Ingress, CNI und CSI?
• Gibt es Security- oder Compliance-Verstöße?

flowchart TD
    KubeAPI[Kubernetes API] --> Prom[Prometheus]
    Kubelet[kubelet und cAdvisor] --> Prom
    NodeExporter[Node Exporter] --> Prom
    KSM[kube-state-metrics] --> Prom
    App[Application Metrics] --> Prom
    Blackbox[Blackbox Exporter] --> Prom
    Prom --> Rules[Recording und Alerting Rules]
    Rules --> Alertmanager[Alertmanager]
    Prom --> Grafana[Grafana Dashboards]
    Alertmanager --> OnCall[On-Call, Chat, Ticket]
    Logs[Loki/OpenSearch/Cloud Logs] --> Grafana
    Traces[Tempo/Jaeger/Cloud Trace] --> Grafana

11.2. Metrikquellen

11.3. Minimaler Prometheus-Stack

Für produktionsnahe Cluster ist der kube-prometheus-stack ein verbreiteter Startpunkt, weil er Prometheus, Alertmanager, Grafana, kube-state-metrics, node-exporter und sinnvolle Standardregeln bündelt. In Workshops kannst du ihn per Helm installieren:

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update
helm upgrade --install monitoring prometheus-community/kube-prometheus-stack   --namespace monitoring --create-namespace   --set grafana.enabled=true   --set prometheus.prometheusSpec.retention=7d

kubectl get pods -n monitoring
kubectl port-forward -n monitoring svc/monitoring-grafana 3000:80

11.4. Monitoring je Umgebung

11.5. Dashboard-Mindestmenge

• Cluster Overview: API, Nodes, Pods, Errors, Kapazität.
• Namespace Overview: CPU, Memory, Pods, Restarts, Quotas.
• Workload Overview: Requests, Limits, HPA, Rollouts, Latenz, Fehlerquote.
• Node Overview: CPU, Memory, Disk, Network, kubelet, Runtime.
• Storage Overview: PVC-Auslastung, Volume Attach/Mount, Snapshot Status.
• Network Overview: DNS-Latenz, Ingress/Gateway, CNI-Flows, Drops.
• Backup Overview: letzter Erfolg, Dauer, Retention, Restore-Test-Status.
• Security Overview: Policy-Verstöße, Admission Denials, Audit-Auffälligkeiten.

11.6. Beispiel: ServiceMonitor

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: demo-api
  namespace: monitoring
  labels:
    release: monitoring
spec:
  namespaceSelector:
    matchNames:
      - demo
  selector:
    matchLabels:
      app.kubernetes.io/name: demo-api
  endpoints:
    - port: metrics
      interval: 30s
      path: /metrics

12. Logging-Konzept

12.1. Zielbild

Kubernetes speichert Container-Logs auf Nodes und macht sie über kubectl logs zugänglich. Für produktiven Betrieb reicht das nicht, weil Pods, Container und Nodes kurzlebig sind. Cluster-Level Logging braucht einen Agenten pro Node und ein separates Backend mit Such-, Aufbewahrungs- und Zugriffskonzept.

flowchart TD
    PodA[Pod stdout/stderr] --> NodeLog[/Node Log Files/]
    PodB[Pod stdout/stderr] --> NodeLog
    NodeLog --> Agent[Fluent Bit, Vector, Promtail, Grafana Alloy]
    Agent --> Backend[Loki, Elasticsearch, OpenSearch, Cloud Logging, CloudWatch Logs, Azure Monitor]
    Backend --> Query[Suche, Dashboards, Korrelation]
    Query --> Incident[Incident Analyse]

12.2. Logging-Regeln für Anwendungen

• Schreibe Logs auf stdout/stderr.
• Nutze strukturierte Logs, bevorzugt JSON.
• Enthält jeder Logeintrag Zeit, Level, Service, Version, Trace-ID, Request-ID und relevante Labels?
• Schreibe keine Passwörter, Tokens, personenbezogene Daten oder private Schlüssel in Logs.
• Trenne Audit-Logs, Access-Logs und Applikationslogs logisch.
• Definiere Retention nach Kritikalität und Compliance.
• Nutze Sampling für sehr laute Debug-Logs.

12.3. Logging-Backends

12.4. Beispiel: Loki mit Helm

helm repo add grafana https://grafana.github.io/helm-charts
helm repo update
helm upgrade --install loki grafana/loki   --namespace logging --create-namespace
helm upgrade --install promtail grafana/promtail   --namespace logging   --set "config.clients[0].url=http://loki-gateway.logging.svc.cluster.local/loki/api/v1/push"

kubectl get pods -n logging

12.5. Log-Retention

12.6. Log-Triage

# Kubernetes-nativ
kubectl logs deployment/demo-api -n demo --all-containers --tail=200
kubectl logs pod/demo-api-abc -n demo -c app --previous
kubectl logs -n kube-system -l k8s-app=kube-dns --tail=100

# Häufige Suche in Loki LogQL
# {namespace="demo", app="demo-api"} |= "error"
# {namespace="ingress-nginx"} | json | status >= 500
# {namespace="demo"} |= "trace_id="

13. Tracing und OpenTelemetry

13.1. Warum Tracing zu Day-2 gehört

Metriken zeigen, dass etwas langsam oder fehlerhaft ist. Logs erklären einzelne Ereignisse. Traces zeigen Pfade über Services hinweg. In verteilten Kubernetes-Anwendungen ist Tracing besonders nützlich für:

• Latenz zwischen Microservices,
• Fehler an externen Abhängigkeiten,
• Datenbank- und Queue-Wartezeiten,
• Korrelation zwischen Ingress, Service und Backend,
• Root-Cause-Analyse bei sporadischen Fehlern.

13.2. Zielarchitektur

flowchart LR
    App1[Service A] --> OTel[OpenTelemetry Collector]
    App2[Service B] --> OTel
    App3[Service C] --> OTel
    OTel --> Tempo[Tempo oder Jaeger]
    OTel --> Prom[Prometheus oder Mimir]
    OTel --> Logs[Loki oder Log Backend]
    Tempo --> Grafana[Grafana]
    Prom --> Grafana
    Logs --> Grafana

13.3. Betriebsregeln

• Nutze einheitliche Resource Attributes: service.name, service.version, deployment.environment, k8s.namespace.name, k8s.pod.name.
• Erzwinge Trace-Kontext-Propagation über HTTP, gRPC und Messaging.
• Behalte Sampling bewusst unter Kontrolle.
• Exportiere Telemetriedaten nicht unkontrolliert über Länder- oder Mandantengrenzen.
• Korrelieren heißt: Metrik, Log und Trace müssen denselben Service- und Request-Kontext tragen.

13.4. Minimaler Collector als Konzeptbeispiel

apiVersion: v1
kind: ConfigMap
metadata:
  name: otel-collector-config
  namespace: observability
data:
  config.yaml: |
    receivers:
      otlp:
        protocols:
          grpc: {}
          http: {}
    processors:
      batch: {}
      memory_limiter:
        check_interval: 1s
        limit_percentage: 75
        spike_limit_percentage: 15
    exporters:
      logging:
        verbosity: basic
    service:
      pipelines:
        traces:
          receivers: [otlp]
          processors: [memory_limiter, batch]
          exporters: [logging]
        metrics:
          receivers: [otlp]
          processors: [memory_limiter, batch]
          exporters: [logging]
        logs:
          receivers: [otlp]
          processors: [memory_limiter, batch]
          exporters: [logging]

14. Alerting-Konzept

14.1. Alerting-Ziel

Ein Alert soll eine menschliche oder automatisierte Handlung auslösen. Alerts, die keine Handlung brauchen, gehören in Dashboards, Reports oder Tickets, aber nicht in die Nachtbereitschaft.

14.2. Alert-Schweregrade

14.3. Gute Alerts

Ein guter Alert enthält:

• Was: präzise Bedingung,
• Wo: Cluster, Namespace, Workload, Node, Region,
• Seit wann: Dauer und Trend,
• Auswirkung: SLO, Kundenwirkung, Datenrisiko,
• Owner: Team oder Service,
• Runbook: Link oder klare nächste Schritte,
• Labels: severity, team, service, environment, cluster.

14.4. Beispiel: PrometheusRule

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: kubernetes-day2-alerts
  namespace: monitoring
  labels:
    release: monitoring
spec:
  groups:
    - name: kubernetes.day2.workloads
      rules:
        - alert: KubernetesPodCrashLooping
          expr: max_over_time(kube_pod_container_status_waiting_reason{reason="CrashLoopBackOff"}[10m]) >= 1
          for: 10m
          labels:
            severity: warning
          annotations:
            summary: "Pod {{ $labels.namespace }}/{{ $labels.pod }} ist im CrashLoopBackOff"
            runbook_url: "https://runbooks.example.local/kubernetes/pod-crashloopbackoff"
        - alert: KubernetesDeploymentReplicasMismatch
          expr: kube_deployment_spec_replicas != kube_deployment_status_replicas_available
          for: 15m
          labels:
            severity: warning
          annotations:
            summary: "Deployment {{ $labels.namespace }}/{{ $labels.deployment }} hat nicht genügend verfügbare Replicas"
        - alert: KubernetesPersistentVolumeClaimFillingUp
          expr: (kubelet_volume_stats_used_bytes / kubelet_volume_stats_capacity_bytes) > 0.85
          for: 15m
          labels:
            severity: warning
          annotations:
            summary: "PVC {{ $labels.namespace }}/{{ $labels.persistentvolumeclaim }} ist zu mehr als 85 Prozent gefüllt"
        - alert: KubernetesNodeNotReady
          expr: kube_node_status_condition{condition="Ready",status="true"} == 0
          for: 10m
          labels:
            severity: critical
          annotations:
            summary: "Node {{ $labels.node }} ist nicht Ready"
        - alert: KubernetesBackupMissing
          expr: time() - max(kubernetes_backup_last_success_timestamp_seconds) > 86400
          for: 10m
          labels:
            severity: critical
          annotations:
            summary: "Letztes erfolgreiches Kubernetes-Backup ist älter als 24 Stunden"

14.5. Alertmanager-Routing

route:
  receiver: default
  group_by: ['cluster', 'namespace', 'alertname']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  routes:
    - matchers:
        - severity="critical"
      receiver: oncall-critical
      repeat_interval: 30m
    - matchers:
        - severity="warning"
      receiver: team-warning
      repeat_interval: 4h
receivers:
  - name: default
    webhook_configs:
      - url: http://alert-router.monitoring.svc.cluster.local/default
  - name: oncall-critical
    webhook_configs:
      - url: http://alert-router.monitoring.svc.cluster.local/critical
  - name: team-warning
    webhook_configs:
      - url: http://alert-router.monitoring.svc.cluster.local/warning

14.6. Alerts, die du vermeiden solltest

• CPU > 80 % für einzelne Pods ohne Kontext. CPU darf hoch sein, wenn SLOs stabil bleiben.
• Jeder einzelne Pod-Restart als Page. Kurzlebige Restarts sind nicht immer kritisch.
• Alerts ohne for-Dauer.
• Alerts auf rohe Metriken ohne Owner und Runbook.
• Alerts auf lokale Labs mit Produktionsseverity.
• Doppelte Alerts aus Prometheus und Cloud Monitoring ohne Deduplizierung.

15. Backup-Konzept

15.1. Was du sichern musst

flowchart TD
    Git[Git: Manifeste, Helm, Kustomize, GitOps] --> Recovery[Wiederherstellung]
    IaC[IaC: Terraform/OpenTofu/Pulumi State] --> Recovery
    Etcd[etcd oder Managed Control Plane State] --> Recovery
    PV[Persistent Volumes und Snapshots] --> Recovery
    DB[Anwendungsdatenbanken] --> Recovery
    Secrets[Secrets, Zertifikate, Schlüsselmaterial] --> Recovery
    Registry[Images und Artefakte] --> Recovery
    DNS[DNS, TLS, Load Balancer, Provider-Konfiguration] --> Recovery
    Runbooks[Runbooks und Inventar] --> Recovery

15.2. Backup-Artefakte

15.3. Backup-Strategien je Umgebung

15.4. etcd-Backup bei kubeadm

etcd enthält den Kubernetes-Clusterzustand. Snapshots enthalten sensible Informationen und müssen verschlüsselt, zugriffsbeschränkt und außerhalb des Clusters abgelegt werden.

# Auf einem Control-Plane-Node eines kubeadm-Clusters
sudo ETCDCTL_API=3 etcdctl snapshot save /var/backups/etcd/snapshot-$(date +%F-%H%M%S).db   --endpoints=https://127.0.0.1:2379   --cacert=/etc/kubernetes/pki/etcd/ca.crt   --cert=/etc/kubernetes/pki/etcd/server.crt   --key=/etc/kubernetes/pki/etcd/server.key

sudo ETCDCTL_API=3 etcdctl snapshot status /var/backups/etcd/snapshot-*.db --write-out=table

Sichere zusätzlich:

sudo tar czf /var/backups/kubernetes-pki-$(date +%F).tgz /etc/kubernetes/pki
sudo tar czf /var/backups/kubernetes-manifests-$(date +%F).tgz /etc/kubernetes/manifests
sudo sha256sum /var/backups/etcd/*.db /var/backups/*.tgz > /var/backups/SHA256SUMS

15.5. Velero-Konzept

Velero eignet sich für Backups und Restores von Kubernetes-Ressourcen und persistenten Volumes. Es arbeitet mit einem Objekt-Storage-Ziel und optional mit Volume Snapshots oder Dateisystem-Backups.

# Beispiel: Backup eines Namespaces
velero backup create demo-$(date +%F-%H%M) --include-namespaces demo
velero backup describe demo-$(date +%F-%H%M) --details
velero backup logs demo-$(date +%F-%H%M)

# Zeitplan
velero schedule create demo-daily   --schedule="0 2 * * *"   --include-namespaces demo   --ttl 720h

# Restore
velero restore create demo-restore-$(date +%F-%H%M) --from-backup demo-daily-20260613020000
velero restore describe demo-restore-$(date +%F-%H%M) --details

15.6. CSI VolumeSnapshots

VolumeSnapshots sichern Volumes auf Storage-Ebene. Sie sind schnell, aber abhängig vom CSI-Treiber, Storage-Backend und Standort. Ein Snapshot allein ersetzt kein applikationskonsistentes Backup.

apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
  name: data-snapshot
  namespace: demo
spec:
  volumeSnapshotClassName: csi-snapshot-class
  source:
    persistentVolumeClaimName: data

15.7. Applikationskonsistente Backups

Für Datenbanken reicht ein Kubernetes-Volume-Snapshot oft nicht. Du brauchst anwendungsspezifische Verfahren:

15.8. Backup-Aufbewahrung

15.9. Backup-Sicherheit

• Verschlüssele Backups im Ruhezustand und beim Transport.
• Speichere Backups nicht nur im selben Cluster.
• Schütze Backup-Buckets gegen versehentliches Löschen.
• Begrenze Schreib- und Leserechte getrennt.
• Teste Restore mit eingeschränkten Berechtigungen.
• Prüfe, ob Secrets im Backup enthalten sind.
• Dokumentiere Schlüsselrotation und Recovery von Verschlüsselungsschlüsseln.

16. Restore und Disaster Recovery

16.1. DR-Stufen

16.2. DR-Architektur

flowchart TD
    Prod[Produktivcluster] --> B1[Git und IaC Mirror]
    Prod --> B2[etcd Snapshots oder Managed State]
    Prod --> B3[PV Snapshots und App-Backups]
    Prod --> B4[Image Registry Mirror]
    Prod --> B5[Observability Export]

    B1 --> DR[DR-Cluster oder neue Umgebung]
    B2 --> DR
    B3 --> DR
    B4 --> DR
    DR --> Validate[Validierung: DNS, Ingress, Daten, SLO]
    Validate --> Cutover[DNS/LB Cutover]

16.3. Restore-Test-Runbook

1. Wähle einen repräsentativen Workload.
2. Erzeuge oder identifiziere ein gültiges Backup.
3. Stelle in einem isolierten Namespace oder Testcluster wieder her.
4. Prüfe Deployments, Pods, Services, PVCs, Secrets und Ingress.
5. Prüfe Anwendungsdaten fachlich, nicht nur Kubernetes-Objekte.
6. Messe Wiederherstellungsdauer.
7. Dokumentiere Abweichungen zu RTO/RPO.
8. Lösche Testressourcen kontrolliert.
9. Aktualisiere Runbook, Alerts und Backup-Konfiguration.

# Beispiel: Velero-Restore in neuen Namespace via Namespace Mapping
velero restore create demo-restore-test   --from-backup demo-daily-20260613020000   --namespace-mappings demo:demo-restore-test

kubectl get all,pvc,secret,configmap -n demo-restore-test
kubectl get events -n demo-restore-test --sort-by=.lastTimestamp

16.4. etcd-Restore bei kubeadm als Notfallmuster

Achtung: Führe etcd-Restore nur in einer kontrollierten Umgebung aus. Ein falscher Restore kann den Clusterzustand überschreiben. Sichere vorher den aktuellen Zustand, auch wenn er defekt wirkt.

Grobablauf:

1. Control-Plane-Zugriff sicherstellen.
2. Aktuelle statische Pod-Manifeste und PKI sichern.
3. Snapshot-Integrität prüfen.
4. Control-Plane-Komponenten stoppen, indem statische Manifeste temporär entfernt werden.
5. Snapshot in neues etcd-Datenverzeichnis wiederherstellen.
6. etcd-Manifest auf neues Datenverzeichnis anpassen.
7. Statische Manifeste wieder aktivieren.
8. API-Server-Readiness prüfen.
9. Workload-Zustand validieren.

# Beispielhafte Orientierung, nicht blind ausführen
SNAPSHOT=/var/backups/etcd/snapshot.db
RESTORE_DIR=/var/lib/etcd-restore

sudo ETCDCTL_API=3 etcdctl snapshot status "$SNAPSHOT" --write-out=table
sudo mkdir -p "$RESTORE_DIR"
sudo etcdutl snapshot restore "$SNAPSHOT" --data-dir "$RESTORE_DIR"

# Danach muss das etcd static pod manifest kontrolliert auf das neue Datenverzeichnis zeigen.
# Prüfe /etc/kubernetes/manifests/etcd.yaml und dokumentiere jede Änderung.

16.5. Managed Kubernetes DR

Bei Managed Kubernetes stellst du selten die Provider-Control-Plane selbst wieder her. Realistischer ist:

1. neue Umgebung per Terraform/OpenTofu/Pulumi/Provider-CLI erstellen,
2. Add-ons in definierter Reihenfolge ausrollen,
3. GitOps verbinden,
4. Secrets/External Secrets wiederherstellen,
5. PVs und Datenbanken aus Snapshots/Backups wiederherstellen,
6. Ingress, DNS, Zertifikate und WAF prüfen,
7. Traffic kontrolliert umschalten,
8. alte Umgebung einfrieren oder analysieren.

16.6. DR-Entscheidungsbaum

flowchart TD
    Incident[Schwerer Ausfall] --> DataLoss{Datenverlust?}
    DataLoss -- Nein --> Rebuild{Cluster neu aufbaubar?}
    Rebuild -- Ja --> GitRebuild[Rebuild aus Git/IaC]
    Rebuild -- Nein --> NodeFix[Node/Control-Plane reparieren]
    DataLoss -- Ja --> BackupOk{Backup gültig und getestet?}
    BackupOk -- Ja --> Restore[Restore durchführen]
    BackupOk -- Nein --> Contain[Schaden begrenzen und manuell rekonstruieren]
    Restore --> Validate[Anwendung fachlich validieren]
    GitRebuild --> Validate
    NodeFix --> Validate
    Validate --> Cutover[Traffic freigeben]
    Contain --> RCA[Root Cause Analyse]

17. Patch- und Update-Konzept

17.1. Patch-Kategorien

17.2. Patch-Fenster

17.3. Vor jedem Patch

kubectl config current-context
kubectl get nodes -o wide
kubectl get pods -A --field-selector=status.phase!=Running
kubectl get events -A --sort-by=.lastTimestamp | tail -100
kubectl get pdb -A
kubectl get hpa -A
kubectl get pvc -A
velero backup get 2>/dev/null || true

Prüfe zusätzlich:

• Gibt es ein aktuelles Backup?
• Sind PDBs realistisch oder blockieren sie jeden Drain?
• Ist genug freie Kapazität vorhanden, wenn ein Node fehlt?
• Sind DaemonSets toleriert und aktuell?
• Gibt es lang laufende Jobs oder Migrationen?
• Sind kritische Wartungsfenster, Freeze-Zeiten oder Blackout-Dates aktiv?

17.4. Node-Patching-Grundmuster

NODE=<node-name>

kubectl cordon "$NODE"
kubectl drain "$NODE"   --ignore-daemonsets   --delete-emptydir-data   --timeout=10m

# Auf dem Node patchen
sudo apt update && sudo apt -y upgrade
sudo reboot

# Nach Reboot
kubectl get node "$NODE" -o wide
kubectl uncordon "$NODE"
kubectl get pods -A -o wide --field-selector spec.nodeName="$NODE"

Bei RHEL/Rocky/Alma/Fedora:

sudo dnf -y update
sudo reboot

Bei SLES/openSUSE:

sudo zypper refresh
sudo zypper update -y
sudo reboot

17.5. Automatisiertes Node-Patching

Optionen:

• Cluster Autoscaler plus neue Node Images und Node-Pool-Rotation,
• Kured für Reboots nach Linux-Updates,
• cloud-native Node Image Upgrades,
• immutable Nodes mit Packer, Image Builder, Talos oder Cluster API,
• GitOps-gesteuerte Wartungsjobs.

Automatisierung ist sinnvoll, wenn sie PDBs, Kapazität, Wartungsfenster und Alert-Suppression berücksichtigt.

18. Kubernetes-Upgrades

18.1. Upgrade-Grundsätze

• Überspringe keine Minor-Versionen, wenn dein Tooling oder Provider das nicht ausdrücklich unterstützt.
• Upgrade zuerst Control Plane, dann Add-ons, dann Nodes. Die genaue Reihenfolge hängt von Distribution und Provider ab.
• Prüfe Version-Skew-Regeln für API Server, kubelet, kube-proxy, Controller, Scheduler und kubectl.
• Prüfe entfernte oder veraltete API-Versionen vor dem Upgrade.
• Prüfe CNI, CSI, Ingress, cert-manager, OPA/Gatekeeper/Kyverno, External Secrets, Argo CD/Flux und Monitoring-Komponenten.
• Plane Node-Drain und Kapazität.
• Halte einen Rollforward-Plan bereit. Rollback bei Kubernetes-Minor-Upgrades ist oft nicht trivial.

18.2. Upgrade-Reihenfolge als Diagramm

flowchart TD
    A[Release Notes und Version Skew prüfen] --> B[Staging-Upgrade testen]
    B --> C[Backups und Restore-Punkt prüfen]
    C --> D[API Deprecations prüfen]
    D --> E[Add-on-Kompatibilität prüfen]
    E --> F[Control Plane aktualisieren]
    F --> G[Core Add-ons aktualisieren]
    G --> H[Node Pools aktualisieren]
    H --> I[Workloads und SLOs validieren]
    I --> J[Git/IaC/Runbooks aktualisieren]

18.3. API-Deprecations prüfen

kubectl api-resources
kubectl get --raw /metrics | grep apiserver_requested_deprecated_apis || true
kubectl get events -A --sort-by=.lastTimestamp | grep -i deprecated || true

# Mit pluto oder kubent, falls installiert
pluto detect-files -d ./k8s
kubent

18.4. kubeadm-Upgrade-Muster

Beispielmuster für ein Minor-Upgrade, stark vereinfacht:

# Auf erstem Control-Plane-Node
sudo apt-mark unhold kubeadm
sudo apt update
sudo apt install -y kubeadm=1.36.1-1.1
sudo apt-mark hold kubeadm

kubeadm version
sudo kubeadm upgrade plan
sudo kubeadm upgrade apply v1.36.1

sudo apt-mark unhold kubelet kubectl
sudo apt install -y kubelet=1.36.1-1.1 kubectl=1.36.1-1.1
sudo apt-mark hold kubelet kubectl
sudo systemctl daemon-reload
sudo systemctl restart kubelet

# Danach weitere Control-Plane-Nodes und Worker sequenziell:
sudo kubeadm upgrade node

Node drainen und aktualisieren:

NODE=<node-name>
kubectl drain "$NODE" --ignore-daemonsets --delete-emptydir-data --timeout=10m
# Auf dem Node kubeadm/kubelet/kubectl aktualisieren
sudo kubeadm upgrade node
sudo systemctl restart kubelet
kubectl uncordon "$NODE"

18.5. EKS-Upgrade-Muster

CLUSTER=demo-eks
REGION=eu-central-1
TARGET=1.36

aws eks describe-cluster --name "$CLUSTER" --region "$REGION"   --query 'cluster.{name:name,version:version,status:status,endpoint:endpoint}'

# Control Plane Upgrade starten
aws eks update-cluster-version   --name "$CLUSTER"   --region "$REGION"   --kubernetes-version "$TARGET"

# Status beobachten
aws eks describe-update --name "$CLUSTER" --region "$REGION" --update-id <update-id>

# Kubeconfig aktualisieren
aws eks update-kubeconfig --name "$CLUSTER" --region "$REGION"

# Managed Node Group aktualisieren
eksctl upgrade nodegroup   --cluster "$CLUSTER"   --name <node-group-name>   --region "$REGION"

Prüfe nach EKS-Upgrades:

• EKS Add-ons wie VPC CNI, CoreDNS, kube-proxy, EBS CSI,
• IAM Roles for Service Accounts oder Pod Identity,
• Security Groups, Load Balancer Controller,
• Managed Node Groups, Fargate Profiles,
• CloudWatch/AMP/ADOT-Konfiguration.

18.6. AKS-Upgrade-Muster

RG=rg-kubernetes
CLUSTER=demo-aks
TARGET=1.36.1

az aks show -g "$RG" -n "$CLUSTER" --query '{name:name,kubernetesVersion:kubernetesVersion,powerState:powerState.code}'
az aks get-upgrades -g "$RG" -n "$CLUSTER" -o table

# Control Plane und Node Pools aktualisieren
az aks upgrade   -g "$RG"   -n "$CLUSTER"   --kubernetes-version "$TARGET"   --yes

# Kubeconfig aktualisieren
az aks get-credentials -g "$RG" -n "$CLUSTER" --overwrite-existing

# Node Images separat aktualisieren, falls vorgesehen
az aks nodepool upgrade   -g "$RG"   --cluster-name "$CLUSTER"   -n <nodepool>   --node-image-only

Prüfe nach AKS-Upgrades:

• Azure CNI oder Kubenet/Azure CNI Overlay,
• CSI Driver für Disk/File,
• Azure Monitor Agent,
• Managed Identity und Workload Identity,
• Ingress Controller, Application Gateway Ingress Controller oder Gateway-Komponenten,
• Planned Maintenance und Auto-Upgrade-Einstellungen.

18.7. GKE-Upgrade-Muster

PROJECT=demo-project
REGION=europe-west3
CLUSTER=demo-gke
TARGET=1.36.1-gke.100

gcloud container clusters describe "$CLUSTER"   --region "$REGION"   --project "$PROJECT"   --format='value(currentMasterVersion,currentNodeVersion,status)'

# Control Plane
gcloud container clusters upgrade "$CLUSTER"   --region "$REGION"   --project "$PROJECT"   --master   --cluster-version "$TARGET"

# Node Pool
gcloud container clusters upgrade "$CLUSTER"   --region "$REGION"   --project "$PROJECT"   --node-pool <nodepool>   --cluster-version "$TARGET"

gcloud container clusters get-credentials "$CLUSTER" --region "$REGION" --project "$PROJECT"

Prüfe nach GKE-Upgrades:

• Release Channel und Maintenance Windows,
• Node Auto-Upgrades und Surge Settings,
• GKE Dataplane, Ingress/Gateway Controller,
• Cloud Logging/Monitoring,
• Workload Identity,
• CSI Driver und Backup for GKE.

18.8. kind, minikube und k3d aktualisieren

Lokale Cluster sind oft besser neu zu erstellen als live zu aktualisieren.

# kind
kind get clusters
kind export logs --name demo ./kind-logs-demo || true
kind delete cluster --name demo
kind create cluster --name demo --image kindest/node:v1.36.1

# minikube
minikube profile list
minikube update-check
minikube delete -p demo
minikube start -p demo --kubernetes-version=v1.36.1 --driver=docker

# k3d
k3d cluster list
k3d cluster delete demo
k3d cluster create demo --image rancher/k3s:v1.36.1-k3s1 -p "8080:80@loadbalancer"

18.9. k3s, RKE2, k0s und Talos

Dokumentiere immer:

• Zielversion,
• unterstützte Upgrade-Pfade,
• etcd/Control-Plane-Backup,
• Add-on-Kompatibilität,
• Drain-Strategie,
• Validierung nach jedem Node.

19. Add-on- und Operator-Lifecycle

19.1. Kritische Add-ons

19.2. Add-on-Upgrade-Runbook

1. Release Notes lesen.
2. CRD-Änderungen identifizieren.
3. Backup der CRDs und Custom Resources erzeugen.
4. Webhooks und Admission-Policies prüfen.
5. Staging-Upgrade durchführen.
6. Metriken und Logs prüfen.
7. Produktives Wartungsfenster nutzen.
8. Nach dem Upgrade Rollout, Webhooks, CRDs und Events prüfen.

# CRDs sichern
kubectl get crd -o yaml > crds-before.yaml
kubectl get validatingwebhookconfiguration,mutatingwebhookconfiguration -o yaml > webhooks-before.yaml

# Helm-Release prüfen
helm list -A
helm history <release> -n <namespace>
helm template <release> <chart> -n <namespace> -f values.yaml > rendered.yaml
kubectl apply --dry-run=server -f rendered.yaml

# Upgrade
helm upgrade --install <release> <chart> -n <namespace> -f values.yaml
kubectl rollout status deployment/<controller> -n <namespace> --timeout=180s

19.3. CRD-Risiken

CRDs sind API-Erweiterungen. Fehlerhafte CRD- oder Webhook-Updates können Deployments im ganzen Cluster blockieren. Prüfe besonders:

• Konvertierungs-Webhooks,
• entfernte Felder,
• nicht kompatible Custom Resources,
• Validierungsregeln,
• Finalizer,
• Controller-Versionen,
• Backup/Restore-Fähigkeit von Custom Resources.

20. Node- und Betriebssystemwartung

20.1. Node-Wartung mit Drain

sequenceDiagram
    participant Op as Operator
    participant API as Kubernetes API
    participant Node as Node
    participant Sched as Scheduler
    participant Pods as Pods

    Op->>API: cordon node
    API->>Node: keine neuen Pods schedulen
    Op->>API: drain node
    API->>Pods: evict Pods gemäß PDB
    Sched->>API: Ersatz-Pods auf anderen Nodes planen
    Op->>Node: OS/Runtime patchen oder rebooten
    Op->>API: uncordon node
    Sched->>Node: neue Pods wieder zulassen

20.2. Drain-Fallen

20.3. Reboot-Runbook

NODE=<node-name>

kubectl get node "$NODE" -o wide
kubectl describe node "$NODE" | egrep 'Taints|Conditions|Capacity|Allocatable' -A5
kubectl get pods -A -o wide --field-selector spec.nodeName="$NODE"

kubectl cordon "$NODE"
kubectl drain "$NODE" --ignore-daemonsets --delete-emptydir-data --timeout=15m

# Node rebooten
ssh "$NODE" 'sudo reboot'

# Warten und validieren
kubectl get node "$NODE" -w
kubectl uncordon "$NODE"
kubectl get pods -A -o wide --field-selector spec.nodeName="$NODE"

20.4. Immutable Node Rotation

Bei Cloud- und Cluster-API-Umgebungen ist Node-Replacement oft sauberer als In-Place-Patching:

1. neues Node Image bauen,
2. neue Node Pool / MachineDeployment-Version erstellen,
3. kleine Anzahl Nodes hinzufügen,
4. Workloads drainen,
5. alte Nodes entfernen,
6. Kapazität und Kosten prüfen.

Dieses Modell reduziert Konfigurationsdrift und macht Rollback über alte Node Pools einfacher.

21. Zertifikate, Secrets und Schlüsselmaterial

21.1. Zertifikatsinventar

21.2. kubeadm-Zertifikate prüfen

sudo kubeadm certs check-expiration
sudo kubeadm certs renew --help

21.3. cert-manager prüfen

kubectl get certificate,certificaterequest,order,challenge -A
kubectl describe certificate <name> -n <namespace>
kubectl logs -n cert-manager deploy/cert-manager --tail=100

21.4. Secrets-Betrieb

• Base64 in Kubernetes Secrets ist keine Verschlüsselung.
• Aktiviere Encryption at Rest für Kubernetes Secrets, wo du Control Plane betreibst.
• Nutze externe Secret-Systeme für produktive Secrets: Vault, AWS Secrets Manager, Azure Key Vault, Google Secret Manager, External Secrets Operator, SOPS.
• Vermeide Secrets in Helm-Values, Pipeline-Logs und Support-Bundles.
• Rotationen müssen Workloads neu laden oder neu starten.
• Prüfe RBAC: Wer darf Secrets lesen?

kubectl get secrets -A
kubectl auth can-i get secrets -n demo
kubectl auth can-i get secrets -n demo --as system:serviceaccount:demo:demo-api

21.5. Secret-Rotation-Runbook

1. Neues Secret im Secret-System erzeugen.
2. Kubernetes Secret aktualisieren oder ExternalSecret synchronisieren lassen.
3. Workload-Restart oder Hot-Reload auslösen.
4. Funktion fachlich validieren.
5. Altes Secret deaktivieren.
6. Audit und Zugriff prüfen.

kubectl rollout restart deployment/demo-api -n demo
kubectl rollout status deployment/demo-api -n demo --timeout=180s

22. Storage-Operations

22.1. Storage-Betriebsfragen

• Welche StorageClass ist Standard?
• Gibt es Retain/Delete-Reclaim-Policies?
• Unterstützt der CSI-Treiber Snapshots?
• Sind Volumes zonengebunden?
• Wie wird Volume-Expansion durchgeführt?
• Sind Backups applikationskonsistent?
• Wie erkennst du volle PVCs?
• Wie werden PVs beim Namespace-Löschen geschützt?

22.2. Storage-Triage

kubectl get storageclass
kubectl get pvc -A
kubectl get pv
kubectl get volumesnapshotclass 2>/dev/null || true
kubectl get volumesnapshot -A 2>/dev/null || true
kubectl get volumeattachment -A 2>/dev/null || true
kubectl describe pvc <pvc> -n <namespace>
kubectl get events -n <namespace> --sort-by=.lastTimestamp | tail -80

22.3. PVC voll

NS=demo
POD=$(kubectl get pod -n $NS -l app.kubernetes.io/name=demo-api -o jsonpath='{.items[0].metadata.name}')
kubectl exec -n $NS "$POD" -- df -h
kubectl describe pvc data -n $NS

Mögliche Maßnahmen:

• Anwendung bereinigen,
• Retention reduzieren,
• PVC expandieren, wenn StorageClass es erlaubt,
• Daten auf neues Volume migrieren,
• Storage-Backend erweitern,
• Backup vor gefährlichen Änderungen erstellen.

22.4. PVC expandieren

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: data
  namespace: demo
spec:
  resources:
    requests:
      storage: 100Gi

Danach prüfen:

kubectl get pvc data -n demo -w
kubectl describe pvc data -n demo

22.5. StatefulSet-Wartung

Bei StatefulSets beachte:

• stabile Pod-Namen,
• stabile PVC-Zuordnung,
• geordnete Rollouts,
• Datenreplikation auf Anwendungsebene,
• Backup vor Schema- oder Versionänderungen,
• klare Sequenz für Primaries/Replicas.

23. Netzwerk-, DNS- und Ingress-Operations

23.1. Netzwerkebenen

flowchart TD
    Client[Client / Browser / API Consumer] --> DNS[DNS]
    DNS --> LB[Load Balancer]
    LB --> Ingress[Ingress Controller oder Gateway]
    Ingress --> Service[Kubernetes Service]
    Service --> EndpointSlice[EndpointSlices]
    EndpointSlice --> Pod[Pod IP]
    Pod --> CNI[CNI Dataplane]
    Pod --> Egress[Egress, NAT, Firewall, Proxy]

23.2. Netzwerk-Triage

NS=demo
kubectl get svc,endpoints,endpointslices -n $NS
kubectl get ingress -A
kubectl get gateway,httproute -A 2>/dev/null || true
kubectl get networkpolicy -A
kubectl get pods -n kube-system -o wide

# DNS-Test
kubectl run net-debug -n $NS --rm -it --image=busybox:1.36 --restart=Never -- sh
# im Pod:
# nslookup kubernetes.default.svc.cluster.local
# nslookup demo-api.demo.svc.cluster.local
# wget -S -O- http://demo-api.demo.svc.cluster.local

23.3. Service ohne Endpoints

Ursachen:

• Service-Selector passt nicht zu Pod-Labels,
• Pods sind nicht Ready,
• falscher Namespace,
• EndpointSlices werden nicht erzeugt,
• Portname oder TargetPort falsch.

kubectl get svc demo-api -n demo -o yaml
kubectl get pods -n demo --show-labels
kubectl get endpoints,endpointslices -n demo -l kubernetes.io/service-name=demo-api
kubectl describe pod -n demo -l app.kubernetes.io/name=demo-api

23.4. Ingress/Gateway-Betrieb

Prüfe:

• DNS zeigt auf richtigen Load Balancer,
• Load Balancer ist provisioniert,
• IngressClass oder GatewayClass stimmt,
• Zertifikat ist gültig,
• Service hat Endpoints,
• Controller-Logs zeigen keinen Routingfehler,
• NetworkPolicies erlauben Traffic.

kubectl get ingress -A
kubectl describe ingress demo-api -n demo
kubectl get ingressclass
kubectl logs -n ingress-nginx deploy/ingress-nginx-controller --tail=100 2>/dev/null || true

kubectl get gatewayclass,gateway,httproute -A 2>/dev/null || true
kubectl describe httproute demo-api -n demo 2>/dev/null || true

23.5. WSL und Windows-Hosts-Datei im Betrieb

Wenn du Kubernetes lokal in WSL betreibst, läuft Edge auf Windows, nicht in Linux. Für browserfreundliche lokale Namen musst du unter Umständen die Windows-Hosts-Datei pflegen:

# PowerShell als Administrator
notepad C:\Windows\System32\drivers\etc\hosts

Aus WSL heraus liegt die Datei typischerweise unter:

sudo cp /mnt/c/Windows/System32/drivers/etc/hosts /mnt/c/Windows/System32/drivers/etc/hosts.bak.$(date +%F-%H%M%S)
# Bearbeitung braucht Windows-Administratorrechte. Bei Fehlern PowerShell als Administrator nutzen.

Beispiel-Einträge:

127.0.0.1 demo.local
127.0.0.1 grafana.local
127.0.0.1 prometheus.local

Betriebsregel: Hosts-Datei-Änderungen sind lokale Konfiguration. Dokumentiere sie im Lab-Runbook, aber behandle sie nicht als produktives DNS.

24. Security Operations

24.1. Security-Betriebsschichten

flowchart TD
    Identity[Identität und Zugriff] --> RBAC[RBAC Least Privilege]
    RBAC --> Admission[Admission Policies]
    Admission --> PodSecurity[Pod Security Standards]
    PodSecurity --> Runtime[Runtime Security]
    Runtime --> Network[NetworkPolicies und Egress]
    Network --> Secrets[Secrets und Schlüssel]
    Secrets --> Audit[Audit Logs]
    Audit --> Response[Incident Response]

24.2. Wiederkehrende Security-Prüfungen

24.3. RBAC Review

kubectl get clusterrolebinding -o wide
kubectl get rolebinding -A -o wide
kubectl get serviceaccount -A
kubectl auth can-i '*' '*' --as system:serviceaccount:demo:demo-api -n demo
kubectl auth can-i get secrets --as system:serviceaccount:demo:demo-api -n demo

24.4. Pod Security Review

kubectl get ns --show-labels | grep pod-security || true
kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.namespace}{"/"}{.metadata.name}{" privileged="}{range .spec.containers[*]}{.securityContext.privileged}{" "}{end}{"
"}{end}'

24.5. Incident Response bei Secret-Leak

1. Leak bestätigen, aber Secret nicht weiter verbreiten.
2. Betroffenen Zugriff sofort rotieren oder deaktivieren.
3. Workloads mit neuem Secret aktualisieren.
4. Audit Logs prüfen.
5. Persistente Artefakte bereinigen: Git, CI-Logs, Tickets, Chat, Support-Bundles.
6. Ursache beheben: RBAC, Logging, Pipeline-Masking, Secret-Scanner.
7. Postmortem dokumentieren.

25. Kapazität, Performance und Kosten

25.1. Kapazitätsdimensionen

25.2. Requests und Limits prüfen

kubectl top pods -A --containers 2>/dev/null || true
kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.namespace}{"/"}{.metadata.name}{" "}{range .spec.containers[*]}{.name}{" req.cpu="}{.resources.requests.cpu}{" req.mem="}{.resources.requests.memory}{" lim.cpu="}{.resources.limits.cpu}{" lim.mem="}{.resources.limits.memory}{"; "}{end}{"
"}{end}'

25.3. Kostenfallen

• Services vom Typ LoadBalancer, die niemand mehr nutzt.
• PVCs/PVs mit Retain, die nach Namespace-Löschung liegen bleiben.
• Snapshots ohne Lifecycle.
• Logging-Retention zu lang oder Debug-Logs zu laut.
• Überdimensionierte Node Pools.
• HPA ohne Cluster Autoscaler oder mit zu hohen Requests.
• NAT Gateway, Datenverkehr und Cross-Zone-Traffic in Clouds.

25.4. Kapazitätsreview

kubectl get nodes -o wide
kubectl describe nodes | egrep 'Name:|Allocatable:|Allocated resources:' -A10
kubectl get hpa -A
kubectl get pdb -A
kubectl get pvc -A
kubectl get svc -A --field-selector spec.type=LoadBalancer 2>/dev/null || true

26. GitOps- und Release-Operations

26.1. GitOps-Betriebsmodell

flowchart LR
    Dev[Änderung im Git] --> PR[Pull Request]
    PR --> Checks[CI, Tests, Policy, Security]
    Checks --> Merge[Merge]
    Merge --> GitOps[Argo CD oder Flux]
    GitOps --> K8s[Kubernetes API]
    K8s --> Status[Status, Events, Health]
    Status --> GitOps
    GitOps --> Alert[Drift oder Sync Fehler]

26.2. GitOps-Regeln

• Produktion wird nicht direkt mit kubectl edit verändert.
• Hotfixes im Cluster werden sofort in Git nachgezogen.
• Jede Applikation hat Owner, Health Checks und Sync-Strategie.
• Secrets liegen nicht im Klartext in Git.
• CRDs und Operatoren haben eigene Rollout-Sequenz.
• Automatischer Sync ist nicht für jede Ressource sinnvoll.
• Prune ist gefährlich, wenn Ownership nicht sauber ist.

26.3. Argo CD Betrieb

argocd app list
argocd app get demo-api
argocd app diff demo-api
argocd app sync demo-api
argocd app wait demo-api --health --timeout 180
kubectl get applications -n argocd
kubectl logs -n argocd deploy/argocd-application-controller --tail=100

26.4. Flux Betrieb

flux get sources all -A
flux get kustomizations -A
flux get helmreleases -A
flux reconcile source git <source-name> -n flux-system
flux reconcile kustomization <name> -n flux-system
kubectl logs -n flux-system deploy/kustomize-controller --tail=100

26.5. Release-Gates

Vor Produktion:

• Build reproduzierbar,
• Image signiert oder zumindest gescannt,
• Manifeste serverseitig validiert,
• Policy-Checks bestanden,
• Rollout in Stage erfolgreich,
• SLO-Dashboard bereit,
• Rollback getestet,
• DB-Migration mit Rückweg bewertet,
• Backup oder Snapshot vorhanden,
• Kommunikationsfenster geklärt.

27. Umgebungsspezifische Operations

27.1. WSL2 unter Windows 11

Day-2-Schwerpunkte:

• WSL-Version, Distribution und Docker-Integration prüfen,
• Windows-/WSL-Netzwerk und Port-Mapping verstehen,
• Windows-Hosts-Datei für Edge-Zugriff pflegen,
• lokale Cluster regelmäßig neu erstellen,
• keine produktiven Secrets in der Lab-Umgebung,
• Speicherverbrauch von Docker Desktop und WSL kontrollieren.

wsl -l -v
wsl --status
wsl --shutdown

kubectl config get-contexts
docker ps
kind get clusters
minikube profile list
k3d cluster list

27.2. kind

Betriebsansatz:

• Cluster als kurzlebig behandeln,
• Konfiguration in kind-config.yaml versionieren,
• Images lokal laden,
• PortMappings dokumentieren,
• Testdaten nicht als dauerhaft betrachten.

kind get clusters
kind export logs --name demo ./kind-logs-demo
kind load docker-image ghcr.io/example/demo-api:1.2.3 --name demo
kubectl cluster-info --context kind-demo

27.3. minikube

minikube profile list
minikube status -p demo
minikube addons list -p demo
minikube service list -p demo
minikube tunnel -p demo
minikube logs -p demo

Achte im Betrieb auf:

• laufende minikube tunnel-Prozesse,
• Treiberwechsel,
• lokale Ressourcenlimits,
• Add-on-Versionen,
• Profilnamen.

27.4. k3d

k3d cluster list
k3d node list
k3d kubeconfig get demo
k3d cluster delete demo

k3d eignet sich für schnelle k3s-Labs. Für persistente Daten musst du Volumes bewusst mounten und sichern.

27.5. Lokale VM mit VirtualBox/VMware/Vagrant

Day-2-Schwerpunkte:

• VM-Snapshots vor riskanten Änderungen,
• Host-only/NAT/Bridged-Netz dokumentieren,
• Uhrzeit/NTP prüfen,
• Disk-Auslastung überwachen,
• kubelet und Runtime als Systemdienste prüfen,
• Vagrantfile und Provisioning-Skripte versionieren.

vagrant status
vagrant snapshot list
vagrant snapshot save cp1 before-upgrade-$(date +%F)
vagrant ssh cp1

27.6. Remote-VM

Zusätzlich prüfen:

• SSH-Zugriff und Notfallzugang,
• Provider-Firewall und lokale Firewall,
• feste IPs und DNS,
• Provider-Snapshots,
• Offsite-Backup,
• Kosten für laufende VMs, Disks und Snapshots.

ssh <user>@<node>
sudo ufw status verbose 2>/dev/null || true
sudo firewall-cmd --list-all 2>/dev/null || true

27.7. Bare Metal

Day-2-Schwerpunkte:

• Hardware-Monitoring,
• Firmware und BIOS/BMC-Versionen,
• RAID-/Disk-Gesundheit,
• lokale und externe Storage-Backups,
• Ersatzteil- und Node-Kapazität,
• physischer Zugriff und Out-of-Band-Management,
• klare Drain- und Austauschprozesse.

sudo smartctl -a /dev/sda 2>/dev/null || true
sudo ipmitool sensor 2>/dev/null || true
sudo journalctl -p warning -n 200 --no-pager

27.8. kubeadm

Du bist verantwortlich für:

• Control Plane,
• etcd,
• Zertifikate,
• kubelet,
• Container Runtime,
• CNI/CSI,
• API- und Node-Upgrades,
• Backups und Restore.

sudo kubeadm certs check-expiration
sudo kubeadm upgrade plan
sudo crictl ps | grep kube
kubectl get --raw='/readyz?verbose'

27.9. Managed Kubernetes: EKS, AKS und GKE

Day-2-Schwerpunkte:

• Provider-Versionen und Support-Fenster,
• Node Pools und Node Images,
• Managed Add-ons,
• Cloud IAM und Workload Identity,
• Cloud Load Balancer und DNS,
• Cloud Logging/Monitoring,
• Backup und DR für Workloads,
• Kostenkontrolle.

# EKS
aws eks list-clusters
aws eks describe-cluster --name <cluster> --region <region>
aws eks list-addons --cluster-name <cluster> --region <region>

# AKS
az aks list -o table
az aks show -g <rg> -n <cluster>
az aks get-upgrades -g <rg> -n <cluster> -o table

# GKE
gcloud container clusters list
gcloud container clusters describe <cluster> --region <region>
gcloud container operations list --region <region>

27.10. Talos

Talos trennt OS-Management stark von klassischem SSH-Betrieb. Operations laufen über talosctl und MachineConfig.

talosctl health
talosctl dashboard
talosctl service kubelet
talosctl logs kubelet
talosctl get members

27.11. OpenShift

OpenShift bringt integrierte Cluster-Operatoren, Security Context Constraints, internes Monitoring und einen eigenen Upgrade-Flow mit.

oc get clusterversion
oc get clusteroperators
oc adm upgrade
oc get co
oc get nodes

28. Runbook-Katalog für häufige Störungen

Dieses Kapitel liefert kompakte, wiederverwendbare Runbooks. Passe Kommandos, Namespaces und Tooling an deine Umgebung an.

28.1. Pod Pending

Symptom: Pods werden nicht geplant.

Häufige Ursachen:

• zu wenig CPU oder Memory
• NodeSelector/Affinity passt nicht
• Taint ohne Toleration
• PVC Pending
• ImagePull ist noch nicht relevant, weil Pod nicht gestartet wurde

Erste Kommandos:

kubectl describe pod <pod> -n <namespace>
kubectl get events -n <namespace> --sort-by=.lastTimestamp
kubectl describe nodes
kubectl get pvc -n <namespace>

Entscheidung:

• Wenn die Ursache auf Konfiguration zeigt, korrigiere Git/Manifest und rolle erneut aus.
• Wenn die Ursache auf Infrastruktur zeigt, eskaliere an Plattform, Cloud oder Storage/Netzwerk-Owner.
• Wenn Datenverlust möglich ist, stoppe Experimente und prüfe Backup-/Restore-Pfad.
• Dokumentiere Ursache, Wirkung, Behebung und Verbesserung am Alert oder Runbook.

28.2. CrashLoopBackOff

Symptom: Container startet, beendet sich und wird wiederholt neu gestartet.

Häufige Ursachen:

• Anwendungsfehler
• fehlende Konfiguration
• Secret fehlt
• Probe zu aggressiv
• Migration schlägt fehl

Erste Kommandos:

kubectl logs <pod> -n <namespace> --previous
kubectl describe pod <pod> -n <namespace>
kubectl get events -n <namespace> --sort-by=.lastTimestamp

Entscheidung:

• Wenn die Ursache auf Konfiguration zeigt, korrigiere Git/Manifest und rolle erneut aus.
• Wenn die Ursache auf Infrastruktur zeigt, eskaliere an Plattform, Cloud oder Storage/Netzwerk-Owner.
• Wenn Datenverlust möglich ist, stoppe Experimente und prüfe Backup-/Restore-Pfad.
• Dokumentiere Ursache, Wirkung, Behebung und Verbesserung am Alert oder Runbook.

28.3. ImagePullBackOff

Symptom: Kubernetes kann das Container-Image nicht laden.

Häufige Ursachen:

• falscher Image-Name
• Tag fehlt
• Registry nicht erreichbar
• ImagePullSecret falsch
• Rate Limit

Erste Kommandos:

kubectl describe pod <pod> -n <namespace>
kubectl get secret -n <namespace>
kubectl get events -n <namespace> --sort-by=.lastTimestamp

Entscheidung:

• Wenn die Ursache auf Konfiguration zeigt, korrigiere Git/Manifest und rolle erneut aus.
• Wenn die Ursache auf Infrastruktur zeigt, eskaliere an Plattform, Cloud oder Storage/Netzwerk-Owner.
• Wenn Datenverlust möglich ist, stoppe Experimente und prüfe Backup-/Restore-Pfad.
• Dokumentiere Ursache, Wirkung, Behebung und Verbesserung am Alert oder Runbook.

28.4. Service ohne Endpoints

Symptom: Service routet nicht zu Pods.

Häufige Ursachen:

• Selector passt nicht
• Pods nicht Ready
• Port falsch
• Namespace falsch

Erste Kommandos:

kubectl get svc,endpoints,endpointslices -n <namespace>
kubectl get pods -n <namespace> --show-labels
kubectl describe svc <service> -n <namespace>

Entscheidung:

• Wenn die Ursache auf Konfiguration zeigt, korrigiere Git/Manifest und rolle erneut aus.
• Wenn die Ursache auf Infrastruktur zeigt, eskaliere an Plattform, Cloud oder Storage/Netzwerk-Owner.
• Wenn Datenverlust möglich ist, stoppe Experimente und prüfe Backup-/Restore-Pfad.
• Dokumentiere Ursache, Wirkung, Behebung und Verbesserung am Alert oder Runbook.

28.5. DNS im Cluster defekt

Symptom: Service-Namen werden nicht aufgelöst.

Häufige Ursachen:

• CoreDNS nicht bereit
• NetworkPolicy blockiert DNS
• Upstream DNS defekt
• NodeLocal DNS Cache Problem

Erste Kommandos:

kubectl get pods -n kube-system -l k8s-app=kube-dns
kubectl logs -n kube-system -l k8s-app=kube-dns
kubectl run dns-debug --rm -it --image=busybox:1.36 --restart=Never -- nslookup kubernetes.default.svc.cluster.local

Entscheidung:

• Wenn die Ursache auf Konfiguration zeigt, korrigiere Git/Manifest und rolle erneut aus.
• Wenn die Ursache auf Infrastruktur zeigt, eskaliere an Plattform, Cloud oder Storage/Netzwerk-Owner.
• Wenn Datenverlust möglich ist, stoppe Experimente und prüfe Backup-/Restore-Pfad.
• Dokumentiere Ursache, Wirkung, Behebung und Verbesserung am Alert oder Runbook.

28.6. Ingress routet nicht

Symptom: Externer HTTP/HTTPS-Traffic erreicht den Service nicht.

Häufige Ursachen:

• DNS falsch
• Load Balancer nicht bereit
• IngressClass falsch
• Service ohne Endpoints
• TLS-Secret fehlt
• Controllerfehler

Erste Kommandos:

kubectl get ingress -A
kubectl describe ingress <name> -n <namespace>
kubectl logs -n <ingress-namespace> deploy/<controller> --tail=100
curl -vk https://<host>

Entscheidung:

• Wenn die Ursache auf Konfiguration zeigt, korrigiere Git/Manifest und rolle erneut aus.
• Wenn die Ursache auf Infrastruktur zeigt, eskaliere an Plattform, Cloud oder Storage/Netzwerk-Owner.
• Wenn Datenverlust möglich ist, stoppe Experimente und prüfe Backup-/Restore-Pfad.
• Dokumentiere Ursache, Wirkung, Behebung und Verbesserung am Alert oder Runbook.

28.7. Gateway API Route nicht akzeptiert

Symptom: HTTPRoute oder Gateway wird nicht wirksam.

Häufige Ursachen:

• GatewayClass fehlt
• Listener passt nicht
• Route nicht attached
• AllowedRoutes blockiert
• ReferenceGrant fehlt

Erste Kommandos:

kubectl get gatewayclass,gateway,httproute -A
kubectl describe httproute <route> -n <namespace>
kubectl describe gateway <gateway> -n <namespace>

Entscheidung:

• Wenn die Ursache auf Konfiguration zeigt, korrigiere Git/Manifest und rolle erneut aus.
• Wenn die Ursache auf Infrastruktur zeigt, eskaliere an Plattform, Cloud oder Storage/Netzwerk-Owner.
• Wenn Datenverlust möglich ist, stoppe Experimente und prüfe Backup-/Restore-Pfad.
• Dokumentiere Ursache, Wirkung, Behebung und Verbesserung am Alert oder Runbook.

28.8. PVC Pending

Symptom: PersistentVolumeClaim wird nicht gebunden.

Häufige Ursachen:

• StorageClass fehlt
• Provisioner defekt
• Zone/Topology passt nicht
• Quota überschritten
• CSI Controller fehlerhaft

Erste Kommandos:

kubectl describe pvc <pvc> -n <namespace>
kubectl get storageclass
kubectl get events -n <namespace> --sort-by=.lastTimestamp
kubectl get pods -n kube-system | grep csi

Entscheidung:

• Wenn die Ursache auf Konfiguration zeigt, korrigiere Git/Manifest und rolle erneut aus.
• Wenn die Ursache auf Infrastruktur zeigt, eskaliere an Plattform, Cloud oder Storage/Netzwerk-Owner.
• Wenn Datenverlust möglich ist, stoppe Experimente und prüfe Backup-/Restore-Pfad.
• Dokumentiere Ursache, Wirkung, Behebung und Verbesserung am Alert oder Runbook.

28.9. Node NotReady

Symptom: Node ist nicht bereit.

Häufige Ursachen:

• kubelet defekt
• CNI defekt
• Runtime defekt
• DiskPressure
• MemoryPressure
• Netzwerk getrennt

Erste Kommandos:

kubectl describe node <node>
ssh <node> 'sudo systemctl status kubelet --no-pager'
ssh <node> 'sudo journalctl -u kubelet -n 200 --no-pager'
ssh <node> 'sudo crictl ps -a'

Entscheidung:

• Wenn die Ursache auf Konfiguration zeigt, korrigiere Git/Manifest und rolle erneut aus.
• Wenn die Ursache auf Infrastruktur zeigt, eskaliere an Plattform, Cloud oder Storage/Netzwerk-Owner.
• Wenn Datenverlust möglich ist, stoppe Experimente und prüfe Backup-/Restore-Pfad.
• Dokumentiere Ursache, Wirkung, Behebung und Verbesserung am Alert oder Runbook.

28.10. API Server langsam oder nicht erreichbar

Symptom: Kubernetes API antwortet langsam oder gar nicht.

Häufige Ursachen:

• etcd langsam
• API-Last
• Webhook hängt
• Netzwerkproblem
• Control-Plane-Ressourcen erschöpft

Erste Kommandos:

kubectl get --raw='/readyz?verbose'
kubectl get --raw='/metrics' | grep apiserver_request
sudo crictl logs $(sudo crictl ps --name kube-apiserver -q | head -1)

Entscheidung:

• Wenn die Ursache auf Konfiguration zeigt, korrigiere Git/Manifest und rolle erneut aus.
• Wenn die Ursache auf Infrastruktur zeigt, eskaliere an Plattform, Cloud oder Storage/Netzwerk-Owner.
• Wenn Datenverlust möglich ist, stoppe Experimente und prüfe Backup-/Restore-Pfad.
• Dokumentiere Ursache, Wirkung, Behebung und Verbesserung am Alert oder Runbook.

28.11. Admission Webhook blockiert Deployments

Symptom: Apply oder Rollout hängt an Webhook-Fehlern.

Häufige Ursachen:

• Webhook-Service nicht erreichbar
• TLS-Zertifikat abgelaufen
• failurePolicy Fail
• Operator defekt

Erste Kommandos:

kubectl get validatingwebhookconfiguration,mutatingwebhookconfiguration
kubectl get svc -A | grep webhook
kubectl get certificates -A
kubectl get events -A --sort-by=.lastTimestamp | grep -i webhook

Entscheidung:

• Wenn die Ursache auf Konfiguration zeigt, korrigiere Git/Manifest und rolle erneut aus.
• Wenn die Ursache auf Infrastruktur zeigt, eskaliere an Plattform, Cloud oder Storage/Netzwerk-Owner.
• Wenn Datenverlust möglich ist, stoppe Experimente und prüfe Backup-/Restore-Pfad.
• Dokumentiere Ursache, Wirkung, Behebung und Verbesserung am Alert oder Runbook.

28.12. HPA skaliert nicht

Symptom: Horizontal Pod Autoscaler reagiert nicht.

Häufige Ursachen:

• metrics-server fehlt
• Requests fehlen
• Metrik nicht verfügbar
• maxReplicas erreicht

Erste Kommandos:

kubectl get hpa -A
kubectl describe hpa <hpa> -n <namespace>
kubectl top pods -n <namespace>
kubectl get apiservice | grep metrics

Entscheidung:

• Wenn die Ursache auf Konfiguration zeigt, korrigiere Git/Manifest und rolle erneut aus.
• Wenn die Ursache auf Infrastruktur zeigt, eskaliere an Plattform, Cloud oder Storage/Netzwerk-Owner.
• Wenn Datenverlust möglich ist, stoppe Experimente und prüfe Backup-/Restore-Pfad.
• Dokumentiere Ursache, Wirkung, Behebung und Verbesserung am Alert oder Runbook.

28.13. OOMKilled

Symptom: Container wird wegen Memory-Limit beendet.

Häufige Ursachen:

• Memory Leak
• Limit zu niedrig
• Requests/Limits falsch
• Node MemoryPressure

Erste Kommandos:

kubectl describe pod <pod> -n <namespace>
kubectl logs <pod> -n <namespace> --previous
kubectl top pod <pod> -n <namespace> --containers

Entscheidung:

• Wenn die Ursache auf Konfiguration zeigt, korrigiere Git/Manifest und rolle erneut aus.
• Wenn die Ursache auf Infrastruktur zeigt, eskaliere an Plattform, Cloud oder Storage/Netzwerk-Owner.
• Wenn Datenverlust möglich ist, stoppe Experimente und prüfe Backup-/Restore-Pfad.
• Dokumentiere Ursache, Wirkung, Behebung und Verbesserung am Alert oder Runbook.

28.14. CPU Throttling

Symptom: Container wird durch CPU-Limits ausgebremst.

Häufige Ursachen:

• Limit zu niedrig
• Lastspitzen
• ungünstiges Threading
• fehlende Requests

Erste Kommandos:

Prometheus: container_cpu_cfs_throttled_periods_total
kubectl top pod <pod> -n <namespace> --containers
kubectl describe pod <pod> -n <namespace>

Entscheidung:

• Wenn die Ursache auf Konfiguration zeigt, korrigiere Git/Manifest und rolle erneut aus.
• Wenn die Ursache auf Infrastruktur zeigt, eskaliere an Plattform, Cloud oder Storage/Netzwerk-Owner.
• Wenn Datenverlust möglich ist, stoppe Experimente und prüfe Backup-/Restore-Pfad.
• Dokumentiere Ursache, Wirkung, Behebung und Verbesserung am Alert oder Runbook.

28.15. Backup fehlgeschlagen

Symptom: Backup-Job oder Velero-Backup ist fehlgeschlagen.

Häufige Ursachen:

• Object Storage nicht erreichbar
• Berechtigung fehlt
• VolumeSnapshotClass fehlt
• Timeout
• zu große Datenmenge

Erste Kommandos:

velero backup get
velero backup describe <backup> --details
velero backup logs <backup>
kubectl logs -n velero deploy/velero --tail=200

Entscheidung:

• Wenn die Ursache auf Konfiguration zeigt, korrigiere Git/Manifest und rolle erneut aus.
• Wenn die Ursache auf Infrastruktur zeigt, eskaliere an Plattform, Cloud oder Storage/Netzwerk-Owner.
• Wenn Datenverlust möglich ist, stoppe Experimente und prüfe Backup-/Restore-Pfad.
• Dokumentiere Ursache, Wirkung, Behebung und Verbesserung am Alert oder Runbook.

28.16. Restore unvollständig

Symptom: Objekte oder Daten fehlen nach Restore.

Häufige Ursachen:

• Namespace-Mapping falsch
• CRDs fehlen
• StorageClass fehlt
• Secrets fehlen
• PV-Snapshot nicht wiederhergestellt

Erste Kommandos:

velero restore get
velero restore describe <restore> --details
kubectl get all,pvc,secret,configmap -n <namespace>
kubectl get events -n <namespace> --sort-by=.lastTimestamp

Entscheidung:

• Wenn die Ursache auf Konfiguration zeigt, korrigiere Git/Manifest und rolle erneut aus.
• Wenn die Ursache auf Infrastruktur zeigt, eskaliere an Plattform, Cloud oder Storage/Netzwerk-Owner.
• Wenn Datenverlust möglich ist, stoppe Experimente und prüfe Backup-/Restore-Pfad.
• Dokumentiere Ursache, Wirkung, Behebung und Verbesserung am Alert oder Runbook.

28.17. GitOps OutOfSync

Symptom: GitOps meldet Drift oder Sync-Fehler.

Häufige Ursachen:

• manuelle Änderung im Cluster
• Webhook blockiert
• CRD fehlt
• Prune gefährlich
• Helm-Template-Fehler

Erste Kommandos:

argocd app get <app>
argocd app diff <app>
flux get kustomizations -A
kubectl get events -A --sort-by=.lastTimestamp | tail -100

Entscheidung:

• Wenn die Ursache auf Konfiguration zeigt, korrigiere Git/Manifest und rolle erneut aus.
• Wenn die Ursache auf Infrastruktur zeigt, eskaliere an Plattform, Cloud oder Storage/Netzwerk-Owner.
• Wenn Datenverlust möglich ist, stoppe Experimente und prüfe Backup-/Restore-Pfad.
• Dokumentiere Ursache, Wirkung, Behebung und Verbesserung am Alert oder Runbook.

28.18. Zertifikat läuft ab

Symptom: TLS- oder Kubernetes-Zertifikat nähert sich Ablauf.

Häufige Ursachen:

• cert-manager Renewal defekt
• Issuer nicht erreichbar
• kubeadm certs nicht erneuert
• ACME Challenge fehlerhaft

Erste Kommandos:

kubectl get certificates -A
kubectl describe certificate <cert> -n <namespace>
sudo kubeadm certs check-expiration

Entscheidung:

• Wenn die Ursache auf Konfiguration zeigt, korrigiere Git/Manifest und rolle erneut aus.
• Wenn die Ursache auf Infrastruktur zeigt, eskaliere an Plattform, Cloud oder Storage/Netzwerk-Owner.
• Wenn Datenverlust möglich ist, stoppe Experimente und prüfe Backup-/Restore-Pfad.
• Dokumentiere Ursache, Wirkung, Behebung und Verbesserung am Alert oder Runbook.

28.19. NetworkPolicy blockiert Traffic

Symptom: Verbindungen zwischen Pods oder zu DNS funktionieren nicht.

Häufige Ursachen:

• Default-Deny ohne Allow
• DNS-Egress fehlt
• Labels passen nicht
• CNI unterstützt Policy nicht

Erste Kommandos:

kubectl get networkpolicy -n <namespace>
kubectl describe networkpolicy <policy> -n <namespace>
kubectl run net-debug --rm -it --image=busybox:1.36 --restart=Never -- sh

Entscheidung:

• Wenn die Ursache auf Konfiguration zeigt, korrigiere Git/Manifest und rolle erneut aus.
• Wenn die Ursache auf Infrastruktur zeigt, eskaliere an Plattform, Cloud oder Storage/Netzwerk-Owner.
• Wenn Datenverlust möglich ist, stoppe Experimente und prüfe Backup-/Restore-Pfad.
• Dokumentiere Ursache, Wirkung, Behebung und Verbesserung am Alert oder Runbook.

28.20. Log-Ingestion zu teuer oder zu laut

Symptom: Logging-Backend wächst stark oder verursacht hohe Kosten.

Häufige Ursachen:

• Debug-Logs aktiv
• zu viele Labels
• keine Retention
• keine Exclusions
• Access Logs ungefiltert

Erste Kommandos:

Backend-Ingestion-Metriken prüfen
kubectl logs --tail
Prometheus/Loki/Cloud-Kosten-Dashboard prüfen

Entscheidung:

• Wenn die Ursache auf Konfiguration zeigt, korrigiere Git/Manifest und rolle erneut aus.
• Wenn die Ursache auf Infrastruktur zeigt, eskaliere an Plattform, Cloud oder Storage/Netzwerk-Owner.
• Wenn Datenverlust möglich ist, stoppe Experimente und prüfe Backup-/Restore-Pfad.
• Dokumentiere Ursache, Wirkung, Behebung und Verbesserung am Alert oder Runbook.

29. Checklisten

29.1. Produktionsreife-Checkliste

29.2. Backup-Checkliste

• Backup-Ziel ist außerhalb des Clusters.
• Backup-Ziel ist verschlüsselt.
• Zugriff auf Backup ist getrennt von Cluster-Admin-Zugriff.
• Retention ist definiert.
• Restore wurde getestet.
• Backups erzeugen Alerts bei Fehlern.
• Secrets und Schlüsselmaterial sind berücksichtigt.
• Datenbanken haben app-konsistente Backups.
• Backup-Kosten werden überwacht.

29.3. Upgrade-Checkliste

• Zielversion ist unterstützt.
• Version-Skew ist geprüft.
• Release Notes sind gelesen.
• API-Deprecations sind geprüft.
• Add-on-Kompatibilität ist geprüft.
• Staging-Upgrade war erfolgreich.
• Backup und Restore-Punkt sind vorhanden.
• Wartungsfenster ist kommuniziert.
• PDBs und Kapazität sind geprüft.
• Rollback/Rollforward ist dokumentiert.
• Nachkontrolle ist definiert.

29.4. Incident-Checkliste

• Severity festlegen.
• Betroffene Services und Kundenwirkung bestimmen.
• Aktuellen Zustand sichern: Events, Logs, Metriken, Screenshots, relevante Manifeste.
• Keine destruktiven Befehle ohne Backup/Rückweg.
• Owner und On-Call informieren.
• Mitigation durchführen.
• Stabilität messen.
• Postmortem erstellen.
• Alerts, Runbooks oder Architektur verbessern.

30. Workshop-Labs

30.1. Lab: Cluster-Triage in 10 Minuten

Ziel: Du erkennst grundlegende Clusterprobleme systematisch.

Aufgaben:

1. Prüfe Kontext und Nodes.
2. Liste nicht laufende Pods.
3. Sortiere Events nach Zeit.
4. Prüfe kube-system.
5. Prüfe Ressourcen mit kubectl top.
6. Dokumentiere drei Findings und ihre Priorität.

30.2. Lab: CrashLoopBackOff beheben

1. Rolle einen fehlerhaften Pod aus.
2. Prüfe describe, Logs und Events.
3. Korrigiere ConfigMap oder Startbefehl.
4. Rolle neu aus.
5. Ergänze einen Alert und ein Runbook.

30.3. Lab: Backup und Restore mit Velero

1. Installiere Velero in einem Lab-Cluster.
2. Erzeuge Namespace, Deployment, Service und PVC.
3. Erstelle ein Backup.
4. Lösche den Namespace.
5. Stelle ihn wieder her.
6. Prüfe fachlich, ob die Daten stimmen.

30.4. Lab: Node Drain und Wartung

1. Erstelle ein Deployment mit drei Replicas und PDB.
2. Drain einen Node.
3. Prüfe, ob der Workload verfügbar bleibt.
4. Simuliere Reboot oder Patch.
5. Uncordon den Node.
6. Passe PDB und Ressourcen an, falls Drain blockiert.

30.5. Lab: Kubernetes-Upgrade-Probe

1. Erstelle einen nichtproduktiven Cluster.
2. Installiere Monitoring und ein Beispiel-Add-on.
3. Prüfe API-Deprecations.
4. Führe ein Patch- oder Minor-Upgrade durch.
5. Validiere Workloads, DNS, Ingress, Storage und Alerts.
6. Dokumentiere Dauer, Fehler und Verbesserungen.

30.6. Lab: Alerting verbessern

1. Installiere Prometheus/Alertmanager.
2. Erzeuge einen CrashLoop.
3. Schreibe eine PrometheusRule.
4. Füge Runbook-Annotation hinzu.
5. Prüfe, ob Alert, Dashboard und Runbook zusammenpassen.

30.7. Lab: DR-Übung

1. Definiere RTO/RPO für eine Demo-App.
2. Sichere Git-Zustand, Kubernetes-Ressourcen und PVC.
3. Stelle in einem neuen Namespace oder Cluster wieder her.
4. Messe Zeit bis zur Funktionsfähigkeit.
5. Bewerte Abweichung zum RTO/RPO.

31. Anhänge: Kommandos, Manifeste und Skripte

31.1. Day-2-Healthcheck-Skript

Speichere das folgende Skript als k8s-day2-healthcheck.sh und führe es gegen den gewünschten Kontext aus.

#!/usr/bin/env bash
set -euo pipefail

NS_FILTER="${1:-}"
TS="$(date +%F-%H%M%S)"
OUT="k8s-healthcheck-$TS"
mkdir -p "$OUT"

run() {
  local name="$1"
  shift
  echo "==> $name"
  ("$@" > "$OUT/$name.txt" 2>&1) || true
}

run context kubectl config current-context
run version kubectl version
run nodes kubectl get nodes -o wide
run pods-all kubectl get pods -A -o wide
run events kubectl get events -A --sort-by=.lastTimestamp
run namespaces kubectl get ns --show-labels
run pdb kubectl get pdb -A
run hpa kubectl get hpa -A
run pvc kubectl get pvc -A
run storageclass kubectl get storageclass
run ingress kubectl get ingress -A
run networkpolicy kubectl get networkpolicy -A
run apiservices kubectl get apiservice
run readyz kubectl get --raw=/readyz?verbose
run livez kubectl get --raw=/livez?verbose
run top-nodes kubectl top nodes
run top-pods kubectl top pods -A

if command -v velero >/dev/null 2>&1; then
  run velero-backups velero backup get
  run velero-schedules velero schedule get
fi

if [ -n "$NS_FILTER" ]; then
  run namespace-all kubectl get all -n "$NS_FILTER" -o wide
  run namespace-events kubectl get events -n "$NS_FILTER" --sort-by=.lastTimestamp
fi

tar czf "$OUT.tgz" "$OUT"
echo "Healthcheck geschrieben: $OUT.tgz"

31.2. etcd-Backup-Skript für kubeadm

#!/usr/bin/env bash
set -euo pipefail

BACKUP_DIR="${BACKUP_DIR:-/var/backups/etcd}"
RETENTION_DAYS="${RETENTION_DAYS:-14}"
TS="$(date +%F-%H%M%S)"
SNAPSHOT="$BACKUP_DIR/etcd-snapshot-$TS.db"

sudo mkdir -p "$BACKUP_DIR"
sudo ETCDCTL_API=3 etcdctl snapshot save "$SNAPSHOT" \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key

sudo ETCDCTL_API=3 etcdctl snapshot status "$SNAPSHOT" --write-out=table
sudo sha256sum "$SNAPSHOT" | sudo tee "$SNAPSHOT.sha256" >/dev/null
sudo find "$BACKUP_DIR" -type f -name 'etcd-snapshot-*.db' -mtime +"$RETENTION_DAYS" -print -delete

echo "etcd Snapshot erstellt: $SNAPSHOT"

31.3. Velero-Schedule-Beispiel

velero schedule create cluster-daily \
  --schedule="0 2 * * *" \
  --ttl 720h

velero schedule create critical-hourly \
  --schedule="0 * * * *" \
  --include-namespaces critical-apps \
  --ttl 168h

velero backup get
velero schedule get

31.4. NetworkPolicy für DNS und App-Traffic

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-dns-and-ingress-to-app
  namespace: demo
spec:
  podSelector:
    matchLabels:
      app.kubernetes.io/name: demo-api
  policyTypes:
    - Ingress
    - Egress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: ingress-nginx
      ports:
        - protocol: TCP
          port: 8080
  egress:
    - to:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: kube-system
      ports:
        - protocol: UDP
          port: 53
        - protocol: TCP
          port: 53

31.5. Abschlussprüfung nach Wartung

kubectl get nodes -o wide
kubectl get pods -A --field-selector=status.phase!=Running
kubectl get events -A --sort-by=.lastTimestamp | tail -100
kubectl get deploy,sts,ds -A
kubectl get hpa,pdb -A
kubectl get pvc -A
kubectl get ingress -A
kubectl get certificates -A 2>/dev/null || true
kubectl get --raw='/readyz?verbose' 2>/dev/null || true

Bewerte danach:

• Gibt es neue Alerts?
• Sind SLO-Dashboards stabil?
• Sind Backups nach der Wartung weiterhin erfolgreich?
• Sind GitOps-Anwendungen synchron?
• Sind Kosten oder Ressourcen unerwartet gestiegen?
• Muss ein Runbook angepasst werden?

32. Quellen und weiterführende Dokumentation

Diese Unterlage ist als Workshop- und Betriebsreferenz formuliert. Für reale Produktionsumgebungen musst du zusätzlich die jeweils aktuellen Hersteller- und Projektseiten prüfen.

• Kubernetes Dokumentation: Cluster Administration, Observability, Logging, Metrics, Probes, kubeadm Upgrade, Version Skew und etcd-Betrieb: https://kubernetes.io/docs/
• Kubernetes Release-Informationen: https://kubernetes.io/releases/
• etcd Disaster Recovery: https://etcd.io/docs/
• Velero Dokumentation: https://velero.io/docs/
• Prometheus Dokumentation: https://prometheus.io/docs/
• Alertmanager Dokumentation: https://prometheus.io/docs/alerting/latest/alertmanager/
• OpenTelemetry Dokumentation: https://opentelemetry.io/docs/
• AWS EKS Dokumentation: https://docs.aws.amazon.com/eks/
• Azure AKS Dokumentation: https://learn.microsoft.com/azure/aks/
• Google GKE Dokumentation: https://cloud.google.com/kubernetes-engine/docs
• Grafana Loki Dokumentation: https://grafana.com/docs/loki/
• Argo CD Dokumentation: https://argo-cd.readthedocs.io/
• Flux Dokumentation: https://fluxcd.io/flux/
• cert-manager Dokumentation: https://cert-manager.io/docs/
• External Secrets Operator Dokumentation: https://external-secrets.io/

Schlussbemerkung

Day-2 Operations sind ein kontinuierlicher Regelkreis. Ein guter Kubernetes-Betrieb entsteht nicht durch ein einzelnes Tool, sondern durch saubere Zuständigkeiten, überprüfbare Backups, getestete Restores, kontrollierte Upgrades, gute Beobachtbarkeit und klare Runbooks. Nutze lokale Umgebungen wie WSL, kind, minikube und k3d, um diese Abläufe gefahrlos zu üben. Übertrage sie anschließend bewusst und angepasst auf VM-, Bare-Metal- und Cloud-Cluster.