49 Wartung und Updates

Wartung und Updates in OpenShift implementieren strukturierte Lifecycle-Management-Prozesse für Plattformstabilität, Sicherheits-Patch-Management und Feature-Evolution durch koordinierte Wartungsfenster und risikominimierende Update-Strategien. Diese operativen Exzellenz-Frameworks gewährleisten Business-Kontinuität während Plattform-Evolution und Sicherheits-Compliance-Wartung.

49.1 Grundlagen des Platform-Lifecycle-Management

OpenShift-Versionierung folgt Semantic-Versioning-Prinzipien mit Major-, Minor- und Patch-Release-Klassifikationen für klare Change-Impact-Kommunikation. Diese Versionierungsstrategie ermöglicht informierte Update-Entscheidungen basierend auf Change-Scope und Risikobewertung.

49.1.1 Versionierungs-Schema

Version-Typ Format Beispiel Änderungsumfang
Major X.0.0 4.0.0 → 5.0.0 Breaking Changes, neue Architektur
Minor X.Y.0 4.12.0 → 4.13.0 Neue Features, API-Erweiterungen
Patch X.Y.Z 4.12.5 → 4.12.6 Bugfixes, Sicherheits-Updates

49.1.2 Update-Channel-Management

Update-Channel-Management implementiert verschiedene Update-Streams mit unterschiedlichen Stabilitäts- und Feature-Release-Zyklen. Fast-Channels bieten frühen Zugang zu neuen Features, während Stable-Channels sich auf getestete Sicherheits-Updates konzentrieren.

# Verfügbare Update-Channels anzeigen
oc get clusterversion version -o yaml | grep availableUpdates -A 20

# Update-Channel wechseln
oc patch clusterversion version --type merge -p '{"spec":{"channel":"stable-4.13"}}'

Update-Channel-Strategien:

[Diagramm: Update-Lifecycle-Management mit Planning, Testing, Deployment und Validation]

49.1.3 Cluster Version Operator (CVO)

Der Cluster Version Operator automatisiert Plattform-Komponenten-Updates durch koordinierte Rolling-Updates mit Health-Validierung und Rollback-Fähigkeiten. Diese Operator-gesteuerten Updates gewährleisten systematische Plattform-Evolution.

# Update-Status überprüfen
oc get clusterversion
oc describe clusterversion version

# Update-Progress monitoren
oc get clusteroperators

49.2 Sicherheits-Patch-Management

49.2.1 Security-Update-Priorisierung

Sicherheits-Update-Priorisierung implementiert risikobasierte Update-Zeitplanung für kritische Sicherheits-Patches und CVE-Response. Diese Priorisierung gewährleistet rechtzeitige Sicherheitsissuebehebung.

CVE-Severity-Matrix:

CVSS-Score Severity Update-Zeitfenster Testing-Umfang
9.0-10.0 Critical 24-48h Minimal Testing
7.0-8.9 High 1 Woche Reduziertes Testing
4.0-6.9 Medium 2-4 Wochen Standard Testing
0.1-3.9 Low Nächstes Window Vollständiges Testing

49.2.2 Vulnerability-Assessment-Integration

Vulnerability-Assessment überwacht Plattform-Komponenten für bekannte Schwachstellen und implementiert automatisierte Patch-Empfehlungen.

# CVE-Status für Images prüfen
oc get images -o json | jq '.items[] | select(.dockerImageMetadata.Config.Labels."io.openshift.build.commit.id")'

# Security-Scanning-Ergebnisse anzeigen
oc describe images sha256:abcd1234... | grep -A 10 "vulnerabilities"

49.2.3 Emergency-Patch-Procedures

Notfall-Patch-Verfahren definieren beschleunigte Update-Workflows für kritische Sicherheitsissues mit reduzierten Testing-Zyklen.

Emergency-Patch-Workflow: 1. Risikobewertung: CVSS-Score und Exploitability-Assessment 2. Stakeholder-Benachrichtigung: Security-, Operations- und Business-Teams 3. Patch-Validierung: Minimale funktionale Tests 4. Rollout-Planung: Staged Deployment mit Monitoring 5. Rollback-Bereitschaft: Automatische Rollback-Trigger

49.3 Rolling-Update-Strategien

49.3.1 Control Plane Updates

Control-Plane-Update-Orchestrierung koordiniert Master-Node-Updates mit minimaler API-Verfügbarkeits-Auswirkung durch sequenzielle Komponenten-Updates.

# Control Plane Update initiieren
oc adm upgrade --to=4.13.12

# Update-Fortschritt überwachen
watch -n 5 "oc get clusteroperators | grep -v 'True.*False.*False'"

# Update-History anzeigen
oc get clusterversion version -o yaml | grep -A 20 history

49.3.2 Worker Node Updates

Worker-Node-Update-Koordination implementiert systematische Node-Updates mit Workload-Drainage und Pod-Rescheduling.

# Node für Update vorbereiten
oc adm drain worker-node-1 --ignore-daemonsets --delete-emptydir-data

# Node-Update-Status prüfen
oc get nodes -l node.openshift.io/os_id=rhcos -o wide

# Node nach Update wieder aktivieren
oc adm uncordon worker-node-1

Worker-Update-Prozess:

Phase Dauer Aktivitäten Monitoring
Drainage 5-15 min Pod-Eviction, Workload-Migration Pod-Status, Service-Verfügbarkeit
Update 15-30 min OS-Update, Reboot, Service-Startup Node-Status, System-Logs
Validation 5-10 min Health-Checks, Workload-Scheduling Cluster-Health, Performance-Metriken

49.3.3 Operator-Update-Management

Operator-Updates koordinieren Custom-Operator-Updates mit Anwendungslebenszyklus-Überlegungen.

# Operator-Updates anzeigen
oc get csv -A | grep -v Succeeded

# Spezifischen Operator aktualisieren
oc patch subscription my-operator -n my-namespace --type merge \
  -p '{"spec":{"channel":"stable","installPlanApproval":"Automatic"}}'

49.4 Pre-Update-Validierung und Testing

49.4.1 Compatibility-Testing

Kompatibilitätstests implementieren Update-Kompatibilitätsverifikation für Anwendungs-Workloads und Custom-Komponenten.

# Anwendungskompatibilität testen
oc get deployments -A -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.template.spec.containers[0].image}{"\n"}{end}'

# Custom Resources auf Kompatibilität prüfen
oc get crd -o custom-columns=NAME:.metadata.name,VERSION:.spec.versions[0].name

49.4.2 Backup-Verifikation

Backup-Verifikation vor Updates gewährleistet Recovery-Fähigkeit bei Update-Fehlern oder Rollback-Anforderungen.

# etcd-Backup erstellen
oc get no -l node-role.kubernetes.io/master -o jsonpath='{.items[0].metadata.name}' | \
xargs -I {} oc debug node/{} -- chroot /host sudo -E /usr/local/bin/cluster-backup.sh /home/core/backup

# Backup-Integrität verifizieren
oc debug node/master-0 -- chroot /host \
  sudo ETCDCTL_API=3 etcdctl --cert /etc/kubernetes/static-pod-certs/secrets/etcd-all-certs/etcd-serving-metrics-master-0.crt \
  --key /etc/kubernetes/static-pod-certs/secrets/etcd-all-certs/etcd-serving-metrics-master-0.key \
  --cacert /etc/kubernetes/static-pod-certs/configmaps/etcd-serving-ca/ca-bundle.crt \
  --endpoints=https://localhost:2379 snapshot status /home/core/backup/snapshot_*.db

49.4.3 Performance-Baseline-Etablierung

Performance-Baseline-Etablierung vor Updates ermöglicht Post-Update-Performance-Vergleich und Regressionserkennung.

# Performance-Baseline sammeln
oc adm top nodes > baseline-nodes-$(date +%Y%m%d).txt
oc adm top pods -A > baseline-pods-$(date +%Y%m%d).txt

# Cluster-Metriken vor Update
oc exec -n openshift-monitoring prometheus-k8s-0 -- \
  promtool query instant 'cluster:cpu_usage_cores:sum' > cpu-baseline.txt

49.5 Post-Update-Validierung

49.5.1 Health-Check-Automatisierung

Health-Check-Automatisierung nach Updates implementiert systematische Plattform-Health-Verifikation für Update-Erfolgsbestätigung.

# Automated Health-Check-Script
#!/bin/bash
echo "=== Cluster Health Check ==="

# Cluster Operators Status
echo "Cluster Operators:"
oc get clusteroperators | grep -v "True.*False.*False" | head -5

# Node Status
echo -e "\nNode Status:"
oc get nodes | grep -v Ready | head -5

# Pod Status
echo -e "\nProblem Pods:"
oc get pods -A | grep -v Running | grep -v Completed | head -10

# API Server Responsiveness
echo -e "\nAPI Response Time:"
time oc get namespaces > /dev/null

49.5.2 Performance-Regressions-Testing

Performance-Regressions-Testing implementiert automatisierten Performance-Vergleich für Update-Impact-Assessment.

# Performance-Vergleich nach Update
echo "=== Performance Comparison ==="

# CPU-Nutzung vergleichen
echo "CPU Usage Comparison:"
echo "Before: $(cat cpu-baseline.txt)"
echo "After: $(oc exec -n openshift-monitoring prometheus-k8s-0 -- promtool query instant 'cluster:cpu_usage_cores:sum')"

# Memory-Nutzung vergleichen
echo "Memory Usage Comparison:"
oc adm top nodes --no-headers | awk '{sum+=$5} END {print "Current Memory Usage: " sum "%"}'

49.5.3 Anwendungsfunktionalitätstests

Anwendungsfunktionalitätstests validieren Anwendungsoperationen nach Plattform-Updates für End-to-End-Funktionalitätsverifikation.

# Smoke-Test-Pod
apiVersion: v1
kind: Pod
metadata:
  name: post-update-smoke-test
spec:
  restartPolicy: Never
  containers:
  - name: test
    image: curlimages/curl:latest
    command:
    - /bin/sh
    - -c
    - |
      set -e
      echo "Testing internal services..."
      curl -f http://my-service:8080/health
      echo "Testing external connectivity..."
      curl -f https://registry.redhat.io/v2/
      echo "All tests passed!"

49.6 Rollback-Strategien

49.6.1 Automatisierte Rollback-Trigger

Automatisierte Rollback-Trigger implementieren automatische Update-Rücknahme bei Health-Check-Fehlern oder Performance-Degradation.

# Rollback-Monitoring-Script
#!/bin/bash
HEALTH_THRESHOLD=80
FAILED_OPERATORS=$(oc get co | grep -v "True.*False.*False" | wc -l)

if [ $FAILED_OPERATORS -gt 3 ]; then
    echo "Critical: $FAILED_OPERATORS operators failing. Initiating rollback..."
    oc adm upgrade --to-latest=false --allow-explicit-channel
    
    # Benachrichtigung senden
    curl -X POST -H 'Content-type: application/json' \
      --data '{"text":"OpenShift rollback initiated due to operator failures"}' \
      $SLACK_WEBHOOK_URL
fi

49.6.2 Point-in-Time-Recovery

Point-in-Time-Recovery-Fähigkeiten ermöglichen granulare Rollbacks zu spezifischen Pre-Update-States.

# etcd-Snapshot-Recovery
# 1. Cluster herunterfahren
oc patch etcd cluster -p='{"spec":{"managementState":"Unmanaged"}}' --type=merge

# 2. Snapshot wiederherstellen
oc debug node/master-0 -- chroot /host \
  sudo /usr/local/bin/cluster-restore.sh /home/core/backup/snapshot_2024010112345.db

# 3. Cluster neu starten
oc patch etcd cluster -p='{"spec":{"managementState":"Managed"}}' --type=merge

49.7 Präventive Wartung

49.7.1 Resource-Cleanup-Automatisierung

Resource-Cleanup-Automatisierung implementiert regelmäßige Ressourcen-Garbage-Collection für Plattform-Health-Wartung.

# Automatisiertes Cleanup-Script
#!/bin/bash
echo "=== OpenShift Cleanup Automation ==="

# Beendete Pods löschen
oc delete pods --field-selector=status.phase=Succeeded -A

# Nicht verwendete Images bereinigen
oc adm prune images --keep-tag-revisions=3 --keep-younger-than=72h

# Build-Artefakte bereinigen
oc adm prune builds --orphans --keep-complete=5 --keep-failed=2

# Deployments bereinigen
oc adm prune deployments --keep-complete=5 --keep-failed=2

echo "Cleanup completed at $(date)"

49.7.2 Certificate-Renewal-Management

Zertifikat-Erneuerungs-Management implementiert automatisiertes Zertifikat-Lifecycle-Management für ununterbrochene Service-Operationen.

# Zertifikat-Status überwachen
oc get secrets -A -o json | jq -r '
  .items[] | 
  select(.type=="kubernetes.io/tls") | 
  "\(.metadata.namespace)/\(.metadata.name): \(.data."tls.crt" // empty)"
' | while read cert; do
  if [ -n "$cert" ]; then
    echo "$cert" | base64 -d | openssl x509 -noout -dates
  fi
done

49.7.3 Log-Rotation und Archive-Management

Log-Rotation und Archive-Management implementieren automatisches Log-Lifecycle-Management für Storage-Optimierung.

# Log-Forwarding-Konfiguration
apiVersion: logging.openshift.io/v1
kind: ClusterLogForwarder
metadata:
  name: instance
spec:
  outputs:
  - name: remote-loki
    type: loki
    url: https://loki.company.com:3100
    loki:
      tenantKey: kubernetes.namespace_name
  pipelines:
  - name: container-logs
    inputRefs:
    - application
    outputRefs:
    - remote-loki
    filterRefs:
    - json-filter

49.8 Kapazitätsplanung und Growth-Management

49.8.1 Resource-Growth-Forecasting

Resource-Growth-Forecasting nutzt historische Nutzungsdaten für prädiktive Kapazitätsplanung und Infrastrukturskalierungsentscheidungen.

# Kapazitäts-Trend-Analyse
#!/bin/bash
echo "=== Capacity Trend Analysis ==="

# 30-Tage-CPU-Trend
oc exec -n openshift-monitoring prometheus-k8s-0 -- \
  promtool query instant 'predict_linear(cluster:cpu_usage_cores:sum[30d], 86400 * 30)'

# 30-Tage-Memory-Trend  
oc exec -n openshift-monitoring prometheus-k8s-0 -- \
  promtool query instant 'predict_linear(cluster:memory_usage:sum[30d], 86400 * 30)'

# Storage-Wachstum
oc exec -n openshift-monitoring prometheus-k8s-0 -- \
  promtool query instant 'predict_linear(cluster:storage_usage:sum[30d], 86400 * 30)'

49.8.2 Kapazitäts-Alerting

# Kapazitäts-Alert-Regeln
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: capacity-alerts
spec:
  groups:
  - name: capacity.rules
    rules:
    - alert: ClusterCPUCapacityHigh
      expr: cluster:cpu_usage_cores:sum / cluster:cpu_capacity_cores:sum > 0.8
      for: 15m
      labels:
        severity: warning
      annotations:
        summary: "Cluster CPU capacity is running high"
        
    - alert: ClusterMemoryCapacityHigh
      expr: cluster:memory_usage:sum / cluster:memory_capacity:sum > 0.85
      for: 10m
      labels:
        severity: warning
      annotations:
        summary: "Cluster memory capacity is running high"

49.9 Monitoring-Integration

49.9.1 Platform-Health-Dashboards

Platform-Health-Dashboards implementieren umfassendes Plattform-Monitoring für proaktive Issue-Detection und Health-Trend-Analyse.

{
  "dashboard": {
    "title": "OpenShift Platform Health",
    "panels": [
      {
        "title": "Cluster Operators Status",
        "type": "table",
        "targets": [
          {
            "expr": "cluster_operator_conditions{condition=\"Available\"}",
            "format": "table"
          }
        ]
      },
      {
        "title": "Node Resource Utilization",
        "type": "graph",
        "targets": [
          {
            "expr": "100 * (1 - avg(rate(node_cpu_seconds_total{mode=\"idle\"}[5m])))",
            "legendFormat": "CPU Usage %"
          }
        ]
      }
    ]
  }
}

49.9.2 Predictive Maintenance Analytics

Predictive-Maintenance-Analytics nutzen Machine Learning für Failure-Prediction und präventive Wartungsplanung.

# Predictive Maintenance ConfigMap
apiVersion: v1
kind: ConfigMap
metadata:
  name: predictive-maintenance-config
data:
  config.yaml: |
    metrics:
      - name: node_failure_prediction
        query: increase(node_boot_time_seconds[1h])
        threshold: 0.1
        action: alert
      - name: disk_failure_prediction
        query: rate(node_disk_io_time_seconds_total[5m])
        threshold: 0.95
        action: maintenance_schedule

49.10 Single-Node-Wartung

49.10.1 Resource-bewusste Wartung

Resource-bewusste Wartung für Single-Node-Umgebungen implementiert Wartungsstrategien ohne Resource-Overhead.

# Single-Node-Wartungs-Script
#!/bin/bash
echo "=== Single-Node Maintenance ==="

# Resource-schonende Updates
oc patch clusterversion version --type merge -p '{"spec":{"desiredUpdate":{"force":false}}}'

# Memory-bewusstes Cleanup
oc delete pods --field-selector=status.phase=Succeeded -A
oc adm prune images --keep-tag-revisions=2 --keep-younger-than=24h

# CodeReady Containers spezifisch
if command -v crc &> /dev/null; then
    crc stop
    crc cleanup
    crc start
fi

49.10.2 Vereinfachte Update-Verfahren

Vereinfachte Update-Verfahren für Entwicklungsumgebungen reduzieren Update-Komplexität für Lernszenarien.

# Vereinfachtes CRC-Update
#!/bin/bash
echo "Updating CodeReady Containers..."

# Backup der aktuellen Konfiguration
crc config view > crc-config-backup.txt

# Update durchführen
crc stop
crc delete -f
# Neue CRC-Version installieren
crc setup
crc start

echo "Update completed. Restore projects manually if needed."

49.11 Compliance und Audit-Integration

49.11.1 Maintenance-Audit-Trails

Maintenance-Audit-Trails implementieren umfassende Wartungsaktivitäts-Protokollierung für Compliance-Reporting.

# Audit-Logging-Konfiguration
apiVersion: config.openshift.io/v1
kind: APIServer
metadata:
  name: cluster
spec:
  audit:
    profile: WriteRequestBodies
    customRules:
    - level: Request
      resources:
      - group: ""
        resources: ["pods", "services"]
      - group: "apps"
        resources: ["deployments", "replicasets"]

49.11.2 Change-Management-Integration

Change-Management-Integration implementiert formale Change-Approval-Prozesse für kontrollierte Plattform-Änderungen.

# GitOps-basiertes Change Management
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: cluster-config
spec:
  source:
    repoURL: https://git.company.com/openshift-config
    path: clusters/production
    targetRevision: main
  destination:
    server: https://kubernetes.default.svc
  syncPolicy:
    automated:
      prune: false
      selfHeal: false
    syncOptions:
    - CreateNamespace=false
    - ApplyOutOfSyncOnly=true

49.12 Performance-Impact-Minimierung

49.12.1 Wartungsfenster-Optimierung

Wartungsfenster-Optimierung implementiert strategische Wartungszeit-Planung für minimalen Business-Impact.

# Wartungsfenster-Planer
#!/bin/bash
# Beste Wartungszeiten basierend auf historischer Last ermitteln
oc exec -n openshift-monitoring prometheus-k8s-0 -- \
  promtool query instant 'avg_over_time(cluster:cpu_usage_cores:sum[7d])' | \
  awk 'BEGIN{min=100} {if($2<min && $2>0){min=$2; time=$1}} END{print "Optimal maintenance window: " time}'

49.12.2 Service-Verfügbarkeits-Wartung

Service-Verfügbarkeits-Wartung implementiert Zero-Downtime-Wartungsstrategien für kritische Service-Kontinuität.

# PodDisruptionBudget für kritische Services
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: critical-app-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: critical-app
      tier: frontend

49.12.3 Performance-Impact-Monitoring

Performance-Impact-Monitoring während Wartungsoperationen implementiert Echtzeit-Impact-Assessment für adaptive Wartungsanpassung.