Maintenance und Upgrades

Die regelmäßige Wartung der ayedo Software Delivery Plattform ist essentiell für Sicherheit, Stabilität und Compliance. Dieses Dokument beschreibt die operativen Verfahren für Patching, Updates und Upgrades.

Überblick

Die ayedo SDP und darauf laufende Software unterscheiden fünf Wartungszüge. Die Züge nicht in einem Schritt mischen.

OS-Patching: Sicherheits-Updates der Node-Betriebssysteme
Platform-Primitives: CNI, Ingress, Cert-Manager, Policy — nur mit Cluster-Owner
Platform Stack / Dependencies: Harbor, Datenbanken, Observability, Velero
Kubernetes-Upgrades: Kubernetes-Version-Updates
Anwendungsrelease: die Fachanwendung (eigener Tag, eigener Rollback)

Wer Software auf einem bereitgestellten Cluster ausliefert, besitzt Zug 5 und oft Zug 3 — nicht automatisch Zug 1 und 4. Air-Gap: Air-Gap-Auslieferung.

Compliance-Anforderungen

Viele Regulierungen erfordern regelmäßige Security-Patches und System-Updates:

Norm	Control	Anforderung
ISO 27001	Annex A 12.6.1	Management of Technical Vulnerabilities
ISO 27001	Annex A 8.19	Change Management
BSI IT-Grundschutz	APP.4.4.A21	Regelmäßige Updates von K8s und Workloads
GDPR	Art. 32	Availability and Resilience
NIS2	Requirement (d)	Business Continuity Management

Voraussetzungen

Bevor Sie Wartungsarbeiten durchführen:

[x] Plattform läuft stabil (siehe Troubleshooting)
[x] Cluster ist korrekt dimensioniert (siehe Kapazitätsplanung)
[x] Backup-Strategie ist implementiert (siehe Disaster Recovery)
[x] Monitoring-Alerts sind konfiguriert (siehe User Alerts)
[x] Incident-Response-Plan existiert (siehe Runbooks)

Wartungsebenen

1. OS-Patching der Nodes

Häufigkeit: Wöchentlich (automatisch) oder monatlich (manuell)

Beschreibung: Security-Patches für Ubuntu/CentOS/RHEL auf Kubernetes-Nodes

Automatisches Patching

Empfohlene Methode via Unattended Upgrades (Ubuntu):

# Auf allen Nodes
sudo apt install unattended-upgrades
sudo dpkg-reconfigure --priority=low unattended-upgrades

Konfiguration in /etc/apt/apt.conf.d/50unattended-upgrades:

Unattended-Upgrade::Allowed-Origins {
    "${distro_id}:${distro_codename}-security";
};
Unattended-Upgrade::Automatic-Reboot "false";

- **Foundation / On-Prem (`k8s-1.27`)**: Manuelle Reboots im Wartungsfenster oder `polycrate run k8s restart-k3s`
- **Worker an k3s-server**: wie Foundation — Drain/Reboot der Agent-Hosts; die Controlplane ist ein Pod (Recreate)

Node-Reboots On-Premises

Für On-Premises-Deployments werden Node-Reboots manuell während Wartungsfenstern durchgeführt:

# Node cordon (keine neuen Pods schedulen)
kubectl cordon <node-name>

# Pods evakuieren
kubectl drain <node-name> --ignore-daemonsets --delete-emptydir-data

# Node rebooten
ssh <node> sudo reboot

# Warten bis Node ready
kubectl wait --for=condition=ready node/<node-name> --timeout=300s

# Node uncordon
kubectl uncordon <node-name>

# Warten bis Pods neu gescheduled sind
kubectl get pods -A --field-selector spec.nodeName=<node-name>

Node-Reboots (Worker / Foundation)

OS-Updates auf Linux-Hosts (Foundation oder Worker, die an eine k3s-server-CP gejoint sind) koordiniert ihr: Cordon → Drain → Reboot → Uncordon, oder polycrate run k8s restart-k3s auf dem k8s-1.27-Block.

Die Controlplane selbst (k3s-server) ist ein Deployment mit Recreate — kein Node-Reboot, sondern Pod-Rollout (polycrate run k3s-server install / Status).

Monitoring:

# Node-Status überwachen
kubectl get nodes -o wide

# Node-Events prüfen
kubectl get events --field-selector involvedObject.kind=Node

2. Platform Stack Upgrades

Häufigkeit: Quartalsweise oder bei kritischen Security-Fixes

Beschreibung: Updates der ayedo-Komponenten (Grafana, VictoriaMetrics, Harbor, etc.)

Pre-Upgrade Checklist

[ ] Benutzer benachrichtigen (z.B. via Slack, E-Mail)
[ ] Changelog prüfen: Neue Features, Breaking Changes, Migration-Guides
[ ] Staging-Upgrade durchführen (falls Staging-Environment vorhanden)

[ ] Backup erstellen:

# Velero-Backup
velero backup create pre-upgrade-$(date +%Y%m%d) --wait

# Backup-Status prüfen
velero backup describe pre-upgrade-$(date +%Y%m%d)

[ ] System-Status prüfen:

# Alle Pods healthy?
kubectl get pods -A | grep -vE "Running|Completed"

# Nodes ready?
kubectl get nodes

# Persistent Volumes bound?
kubectl get pv,pvc -A

# Recent alerts?
kubectl get prometheusrules -A

[ ] Alerting pausieren (Grafana Alerting Silences):

# Via Grafana Alerting UI oder API
curl -X POST https://alertmanager.example.com/api/v2/silences \
  -d '{"matchers":[{"name":"alertname","value":".*","isRegex":true}],"startsAt":"2025-01-15T10:00:00Z","endsAt":"2025-01-15T12:00:00Z","createdBy":"admin","comment":"Platform Upgrade"}'

Upgrade-Prozedur

Schritt-für-Schritt:

Block-Versionen aktualisieren

Bearbeiten Sie die workspace.poly und aktualisieren Sie die gewünschten Block-Versionen:

# workspace.poly
blocks:
  # Beispiel: Grafana upgraden von 11.3.0 auf 11.4.0
  - name: grafana
    from: cargo.ayedo.cloud/ayedo/k8s/grafana:11.4.0  # <- Version aktualisiert
    kubeconfig:
      from: my-cluster

  # Beispiel: VictoriaMetrics upgraden
  - name: victoria-metrics
    from: cargo.ayedo.cloud/ayedo/k8s/victoriametrics:1.106.0  # <- Version aktualisiert
    kubeconfig:
      from: my-cluster

  # Source Control & CI/CD
  - name: gitlab
    from: cargo.ayedo.cloud/ayedo/k8s/gitlab:17.7.0  # <- Version aktualisiert
    kubeconfig:
      from: my-cluster

  # Application Delivery
  - name: argocd
    from: cargo.ayedo.cloud/ayedo/k8s/argocd:2.13.0  # <- Version aktualisiert
    kubeconfig:
      from: my-cluster

  # Secrets Management
  - name: vault
    from: cargo.ayedo.cloud/ayedo/k8s/openbao:1.18.0  # <- Version aktualisiert
    kubeconfig:
      from: my-cluster

  # Andere Blöcke bleiben auf aktueller Version
  - name: harbor
    from: cargo.ayedo.cloud/ayedo/k8s/harbor:2.11.0  # <- Keine Änderung
    kubeconfig:
      from: my-cluster

!!! tip "Modulare Upgrades" Sie müssen nicht alle Komponenten gleichzeitig upgraden. Die SDP ist so konzipiert, dass Komponenten in unterschiedlichen Versionen miteinander funktionieren können. Dies ermöglicht schrittweise, kontrollierte Upgrade-Pfade.

!!! warning "Kritische Komponenten" Bei Upgrades von GitLab, Argo CD und OpenBao sollten Sie besonders vorsichtig sein, da diese Komponenten zentral für die Entwickler-Workflows sind. Führen Sie Upgrades dieser Komponenten vorzugsweise außerhalb der Geschäftszeiten durch.

Block-Versionen pullen

cd ayedo-platform-workspace

# Neue Block-Versionen herunterladen
polycrate blocks pull

Migration-Guides prüfen

Prüfen Sie die Block-spezifischen Changelogs und Breaking Changes:

# Beispiel: Grafana Changelog prüfen
cat ~/.polycrate/blocks/cargo.ayedo.cloud/ayedo/k8s/grafana/11.4.0/CHANGELOG.md

Upgrade durchführen

# Dry-run (zeigt geplante Änderungen)
polycrate workflows run upgrade --dry-run

# Upgrade ausführen
polycrate workflows run upgrade

Upgrade-Validierung

# Alle Pods healthy?
kubectl get pods -A | grep -vE "Running|Completed"

# Neue Versionen deployed?
kubectl get deployments -A -o custom-columns=NAME:.metadata.name,IMAGE:.spec.template.spec.containers[0].image

# Services erreichbar?
curl -I https://grafana.example.com
curl -I https://harbor.example.com
curl -I https://gitlab.example.com
curl -I https://argocd.example.com
curl -I https://vault.example.com

# GitLab-Spezifische Validierung
kubectl exec -n gitlab gitlab-toolbox-<pod> -- gitlab-rake gitlab:check SANITIZE=true

# ArgoCD-Spezifische Validierung
kubectl get applications -n argocd
argocd app list

# OpenBao-spezifische Validierung
kubectl exec -n vault vault-0 -- vault status

Post-Upgrade Checklist

[ ] System-Status prüfen:
```
kubectl get pods,nodes,pvc -A
```
[ ] Logins testen:
Grafana: https://grafana.example.com
Harbor: https://harbor.example.com
[ ] Monitoring prüfen:
Metriken werden gesammelt
Logs werden aggregiert
Alerts funktionieren
[ ] Alerting reaktivieren (Silences löschen)
[ ] Benutzer benachrichtigen (Upgrade abgeschlossen)
[ ] Incident dokumentieren (falls Issues auftraten)

3. Kubernetes-Upgrades

Häufigkeit: Halbjährlich oder bei kritischen Kubernetes-CVEs

Beschreibung: Kubernetes Control-Plane und Worker-Nodes upgraden

Kubernetes-Upgrade-Strategie

Kubernetes-Support-Window:

Kubernetes unterstützt die letzten 3 Minor-Versionen:

Version	Release	End-of-Life
1.29	Dez 2023	Feb 2025
1.28	Aug 2023	Okt 2024
1.27	Apr 2023	Jun 2024

Pre-Upgrade Checklist

[ ] Deprecated APIs identifizieren:

# Kubernetes API-Versionen prüfen
kubectl api-resources --verbs=list -o wide

# Deprecated APIs in Cluster finden
kubectl get all -A -o json | jq -r '.items[] | select(.apiVersion | contains("v1beta")) | "\(.kind)/\(.metadata.name) in \(.metadata.namespace) uses \(.apiVersion)"'

[ ] Anwendungsentwickler benachrichtigen (4 Wochen Vorlauf)
[ ] Staging-Cluster upgraden (falls vorhanden)

[ ] Backup erstellen:

velero backup create pre-k8s-upgrade-$(date +%Y%m%d) --wait

Upgrade-Prozedur

Methode 1: Managed Kubernetes (EKS, AKS, GKE)

# AWS EKS
aws eks update-cluster-version --name ayedo-cluster --kubernetes-version 1.29

# Azure AKS
az aks upgrade --resource-group ayedo-rg --name ayedo-cluster --kubernetes-version 1.29.0

# Google GKE
gcloud container clusters upgrade ayedo-cluster --cluster-version=1.29

Methode 2: Self-Managed (kubeadm, Polycrate)

# Control-Plane upgraden
sudo kubeadm upgrade plan
sudo kubeadm upgrade apply v1.29.0

# Kubelet/kubectl upgraden
sudo apt-mark unhold kubelet kubectl
sudo apt-get update && sudo apt-get install -y kubelet=1.29.0-* kubectl=1.29.0-*
sudo apt-mark hold kubelet kubectl
sudo systemctl daemon-reload
sudo systemctl restart kubelet

# Worker-Nodes upgraden (einer nach dem anderen)
kubectl drain <node> --ignore-daemonsets --delete-emptydir-data
# ... upgrade kubelet auf Node ...
kubectl uncordon <node>

Post-Upgrade Validierung

# Kubernetes-Version prüfen
kubectl version

# Nodes ready?
kubectl get nodes -o wide

# Control-Plane healthy?
kubectl get componentstatuses

# Deprecated APIs noch in Nutzung?
kubectl get all -A -o json | jq -r '.items[] | select(.apiVersion | contains("v1beta")) | "\(.kind)/\(.metadata.name) in \(.metadata.namespace) uses \(.apiVersion)"'

Rollback-Strategie

- **Staged Rollouts**: Staging → Production
- **Rollforward**: Bei Issues in Production den Fix deployen, nicht zurückrollen
- **Snapshots nutzen**: Nur als letztes Mittel

Warum keine Rollbacks?

Stateful Applications (Datenbanken) können inkonsistent werden
Schema-Migrationen sind oft nicht rückgängig machbar
Risiko von Datenverlust und Korruption

Maintenance Windows

Empfohlene Wartungsfenster

Wartungstyp	Häufigkeit	Dauer	Downtime
OS-Patching	Wöchentlich	1-2h	Keine (rolling)
Platform-Upgrade	Quartalsweise	2-4h	< 5 Min
K8s-Upgrade	Halbjährlich	4-8h	< 15 Min

Kommunikation

4 Wochen vorher: - Ankündigung per E-Mail/Slack - Deprecated APIs kommunizieren - Breaking Changes erläutern

1 Woche vorher: - Erinnerung per E-Mail/Slack - Maintenance-Window bestätigen

24 Stunden vorher: - Letzte Erinnerung - Status-Page aktualisieren

Während Wartung: - Live-Updates via Slack - Status-Page: "Maintenance in Progress"

Nach Wartung: - Abschluss-Benachrichtigung - Issue-Report (falls notwendig)

Automatisierung

Empfohlene Tools

Tool	Zweck	Einsatz
k8s-1.27 / Worker-Hosts	Node-Lifecycle (Cordon/Drain/Reboot)	OS-Patching, `restart-k3s`
Polycrate	Deklarative Infra-Deployments	Platform-Upgrades, SDP-Deployments
Velero	Backup/Restore	Disaster Recovery

Monitoring und Alerting

Pre-Upgrade Checks

# Prometheus-Alerts prüfen
kubectl get prometheusrules -A

# Alert-Status abrufen
curl https://alertmanager.example.com/api/v2/alerts

# Grafana-Dashboards überprüfen
curl -H "Authorization: Bearer $GRAFANA_TOKEN" \
  https://grafana.example.com/api/health

Post-Upgrade Monitoring

Key-Metriken überwachen:

Pod Restart Rate: Keine abnormalen Restarts
API-Server Latency: < 100ms
etcd Latency: < 10ms
Node CPU/Memory: Keine Spikes
Persistent Volume Claims: Alle Bound

Troubleshooting

Problem: Upgrade schlägt fehl

Symptom: Pods crashen nach Upgrade.

Lösung:

Rollback zum letzten Backup:

velero restore create --from-backup pre-upgrade-20250115

Logs analysieren:

kubectl logs -n <namespace> <pod> --previous

Events prüfen:

kubectl get events -A --sort-by='.lastTimestamp'

Problem: Node bleibt nach Reboot `NotReady`

Symptom: Node kommt nach Reboot nicht zurück.

Lösung:

SSH auf Node und Logs prüfen:

ssh <node>
sudo journalctl -u kubelet -f

Kubelet neu starten:
```
sudo systemctl restart kubelet
```
Node-Status prüfen:
```
kubectl describe node <node>
```

Problem: Deprecated APIs nach Kubernetes-Upgrade

Symptom: Workloads funktionieren nicht mehr.

Lösung:

Deprecated APIs finden:

# Deprecated APIs in Cluster identifizieren
kubectl get all -A -o json | jq -r '.items[] | select(.apiVersion | contains("v1beta")) | "\(.kind)/\(.metadata.name) in \(.metadata.namespace) uses \(.apiVersion)"'

Manifests aktualisieren (z.B. networking.k8s.io/v1beta1 → networking.k8s.io/v1)

Polycrate-Blöcke aktualisieren und neu deployen:

# Block-Versionen in workspace.poly aktualisieren
# Dann Upgrade durchführen
polycrate workflows run upgrade

4. Dependencies (Datenbanken, Registry, Observability)

Häufigkeit: nach Hersteller- und CVE-Lage, entkoppelt vom App-Tag

Beschreibung: Versionierte Blöcke für PostgreSQL/CNPG, MongoDB, Redis/Valkey, Message-Broker, Harbor, Velero, VictoriaMetrics/VictoriaLogs. Tag pinnen, Backup-Probe, dann polycrate run <block> upgrade. Bei Fehler denselben Block auf den vorherigen Tag zurücksetzen — nicht die Fachanwendung mitziehen.

5. Anwendungsrelease

Häufigkeit: nach dem Release-Prozess der Anwendung

Beschreibung: Nur Image-/Block-Tag der Fachanwendung ändern. Primitives und Dependencies bleiben. Rollback = vorherigen Tag pinnen und dieselbe Upgrade-Action. Vorlagen: bereitgestellter Cluster, Air-Gap.

Weiterführende Dokumentation

Kapazitätsplanung - Cluster-Dimensionierung
Disaster Recovery
Troubleshooting - Fehlerbehebung
Runbooks - Operationale Prozeduren
User Alerts - Alert-Management

Support

Bei Fragen zu Maintenance und Upgrades:

E-Mail: support@ayedo.de
Website: ayedo.de
Discord: ayedo Discord

Maintenance und Upgrades

Maintenance und Upgrades

Überblick

Compliance-Anforderungen

Voraussetzungen

Wartungsebenen

1. OS-Patching der Nodes

Automatisches Patching

Node-Reboots On-Premises

Node-Reboots (Worker / Foundation)

2. Platform Stack Upgrades

Pre-Upgrade Checklist

Upgrade-Prozedur

Post-Upgrade Checklist

3. Kubernetes-Upgrades

Kubernetes-Upgrade-Strategie

Pre-Upgrade Checklist

Upgrade-Prozedur

Post-Upgrade Validierung

Rollback-Strategie

Maintenance Windows

Empfohlene Wartungsfenster

Kommunikation

Automatisierung

Empfohlene Tools

Monitoring und Alerting

Pre-Upgrade Checks

Post-Upgrade Monitoring

Troubleshooting

Problem: Upgrade schlägt fehl

Problem: Node bleibt nach Reboot NotReady

Problem: Deprecated APIs nach Kubernetes-Upgrade

4. Dependencies (Datenbanken, Registry, Observability)

5. Anwendungsrelease

Weiterführende Dokumentation

Support

Problem: Node bleibt nach Reboot `NotReady`