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 erfordert drei Wartungsebenen:

1. OS-Patching: Sicherheits-Updates der Node-Betriebssysteme
2. Platform Stack Upgrades: Updates der ayedo-Komponenten
3. Kubernetes-Upgrades: Kubernetes-Version-Updates

Compliance-Anforderungen¶

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

Voraussetzungen¶

Bevor Sie Wartungsarbeiten durchführen:

• Plattform läuft stabil (siehe Troubleshooting)
• Cluster ist korrekt dimensioniert (siehe Kapazitätsplanung)
• Backup-Strategie ist implementiert (siehe Backup & Recovery)
• Monitoring-Alerts sind konfiguriert (siehe User Alerts)
• 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";

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 Public Cloud (Loopback)¶

In Public Cloud-Deployments mit Loopback wird das Node-Lifecycle-Management automatisch gehandhabt:

• Automatische Updates: Loopback führt OS-Updates und Reboots automatisch durch
• Koordinierte Reboots: Nodes werden nacheinander gebootet, um High Availability zu gewährleisten
• Kein manueller Eingriff: Platform-Administratoren müssen keine manuellen Reboots durchführen

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:

1. 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/vault: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, ArgoCD und Vault 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.

1. Block-Versionen pullen

   cd ayedo-platform-workspace
   
   # Neue Block-Versionen herunterladen
   polycrate blocks pull
   

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

1. Upgrade durchführen

   # Dry-run (zeigt geplante Änderungen)
   polycrate workflows run upgrade --dry-run
   
   # Upgrade ausführen
   polycrate workflows run upgrade
   

2. 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
   
   # Vault-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:

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¶

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¶

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¶

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:

1. Rollback zum letzten Backup:

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

2. Logs analysieren:

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

3. 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:

1. SSH auf Node und Logs prüfen:

   ssh <node>
   sudo journalctl -u kubelet -f
   

2. Kubelet neu starten:

   sudo systemctl restart kubelet
   

3. Node-Status prüfen:

   kubectl describe node <node>
   

Problem: Deprecated APIs nach Kubernetes-Upgrade¶

Symptom: Workloads funktionieren nicht mehr.

Lösung:

1. 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)"'
   

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

3. Polycrate-Blöcke aktualisieren und neu deployen:

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

Weiterführende Dokumentation¶

• Kapazitätsplanung - Cluster-Dimensionierung
• Backup & Recovery - 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