Deployment-Strategien

Deployment-Strategien definieren systematische Ansätze für Anwendungsbereitstellung und -aktualisierung in OpenShift-Umgebungen, wobei verschiedene Trade-offs zwischen Verfügbarkeit, Risiko, Ressourcenverbrauch und Update-Geschwindigkeit balanciert werden. Diese strategischen Frameworks ermöglichen organisationsspezifische Optimierung von Change Management-Prozessen entsprechend Business-Requirements und Technical Constraints.

28.1 Die vier Hauptstrategien im Überblick

Jede Deployment-Strategie hat spezifische Vor- und Nachteile, die sie für unterschiedliche Anwendungsszenarien geeignet machen. Die Wahl der richtigen Strategie hängt von Faktoren wie Verfügbarkeitsanforderungen, Ressourcenbudget, Risikotoleranz und Anwendungsarchitektur ab.

[Diagramm: Deployment-Strategien-Matrix mit Downtime vs. Ressourcenverbrauch vs. Komplexität]

28.1.1 Strategien-Vergleich

Strategie	Downtime	Ressourcen	Komplexität	Rollback-Zeit	Verwendung
Rolling	Keine	Normal	Niedrig	Langsam	Standard-Deployments
Recreate	Kurz	Minimal	Sehr niedrig	Langsam	Legacy-Apps, Entwicklung
Blue-Green	Keine	Doppelt	Mittel	Sofort	Kritische Services
Canary	Keine	Normal+	Hoch	Schnell	Risikoreiche Updates

28.2 Rolling Deployments: Der Standard-Ansatz

Rolling Deployment-Strategien implementieren graduelle Anwendungsaktualisierungen durch schrittweisen Austausch alter Instanzen mit neuen Versionen während kontinuierlicher Service-Verfügbarkeit. Diese inkrementelle Herangehensweise minimiert Service-Unterbrechungen und ermöglicht frühe Fehlererkennung mit begrenztem Blast-Radius.

28.2.1 Rolling Update-Konfiguration

apiVersion: apps/v1
kind: Deployment
metadata:
  name: webapp
spec:
  replicas: 6
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 2    # Max 2 Pods gleichzeitig down
      maxSurge: 2         # Max 2 zusätzliche Pods während Update
  template:
    spec:
      containers:
      - name: webapp
        image: webapp:v2.0
        readinessProbe:    # Kritisch für Rolling Updates
          httpGet:
            path: /health
            port: 8080
          initialDelaySeconds: 10
          periodSeconds: 5

28.2.2 Parameter-Tuning für verschiedene Szenarien

rollingUpdate:
  maxUnavailable: 50%    # Hälfte der Pods kann gleichzeitig down sein
  maxSurge: 50%         # Doppelte Kapazität während Update

rollingUpdate:
  maxUnavailable: 1      # Nur 1 Pod gleichzeitig down
  maxSurge: 1           # Nur 1 zusätzlicher Pod

rollingUpdate:
  maxUnavailable: 0      # Kein Pod darf down sein
  maxSurge: 2           # Neue Pods vor Terminierung alter Pods

28.2.3 Rolling Update überwachen

# Update-Status verfolgen
oc rollout status deployment/webapp

# Update-Historie anzeigen
oc rollout history deployment/webapp

# Laufendes Update pausieren
oc rollout pause deployment/webapp

# Update fortsetzen
oc rollout resume deployment/webapp

# Rollback zum vorherigen Stand
oc rollout undo deployment/webapp

28.3 Recreate Strategy: Einfach aber mit Downtime

Recreate-Strategien terminieren alle bestehenden Instanzen vor Erstellung neuer Versionen, wodurch temporäre Service-Unterbrechungen entstehen aber Ressourcenverbrauch minimiert wird. Diese Strategie eignet sich für Anwendungen, die gleichzeitige Versionskoexistenz nicht unterstützen oder absolute State-Konsistenz erfordern.

28.3.1 Recreate-Konfiguration

apiVersion: apps/v1
kind: Deployment
metadata:
  name: legacy-app
spec:
  strategy:
    type: Recreate
  template:
    spec:
      containers:
      - name: legacy-app
        image: legacy-app:v2.0
        volumeMounts:
        - name: shared-data
          mountPath: /data
      volumes:
      - name: shared-data
        persistentVolumeClaim:
          claimName: shared-pvc  # ReadWriteOnce PVC

28.3.2 Wann Recreate verwenden?

Geeignet für: - Legacy-Anwendungen ohne Clustering-Support - Anwendungen mit ReadWriteOnce-Volumes - Entwicklungs- und Testumgebungen - Single-Instance-Datenbanken - Batch-Jobs und Scheduled Tasks

spec:
  template:
    spec:
      # Schnellerer Container-Start
      containers:
      - name: app
        image: app:v2.0
        imagePullPolicy: IfNotPresent  # Image bereits gecached
      # Image bereits auf Nodes vorziehen
      initContainers:
      - name: cache-warmer
        image: app:v2.0
        command: ['echo', 'Image cached']

28.4 Blue-Green Deployments: Zero-Downtime mit doppelten Ressourcen

Blue-Green Deployment-Pattern implementieren parallele Produktions-Environments mit instantanem Traffic-Switch zwischen Versionen. Diese Strategie eliminiert Deployment-Downtime und ermöglicht schnelle Rollbacks, erfordert jedoch doppelte Ressourcenkapazität.

28.4.1 Blue-Green Setup-Beispiel

# Blue Deployment (aktuelle Produktion)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: webapp-blue
  labels:
    app: webapp
    version: blue
spec:
  replicas: 3
  selector:
    matchLabels:
      app: webapp
      version: blue
  template:
    metadata:
      labels:
        app: webapp
        version: blue
    spec:
      containers:
      - name: webapp
        image: webapp:v1.9

---
# Green Deployment (neue Version)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: webapp-green
  labels:
    app: webapp
    version: green
spec:
  replicas: 3
  selector:
    matchLabels:
      app: webapp
      version: green
  template:
    metadata:
      labels:
        app: webapp
        version: green
    spec:
      containers:
      - name: webapp
        image: webapp:v2.0

---
# Service (Traffic-Switch-Point)
apiVersion: v1
kind: Service
metadata:
  name: webapp-service
spec:
  selector:
    app: webapp
    version: blue    # Switch to 'green' for cutover
  ports:
  - port: 80
    targetPort: 8080

28.4.2 Blue-Green Deployment-Prozess

# 1. Green Environment deployen
oc apply -f webapp-green-deployment.yaml

# 2. Green Environment testen (interner Service)
oc expose deployment webapp-green --name=webapp-green-service
oc port-forward service/webapp-green-service 8081:80

# Test: curl http://localhost:8081/health

# 3. Traffic auf Green umschalten
oc patch service webapp-service -p '{"spec":{"selector":{"version":"green"}}}'

# 4. Blue Environment cleanup (nach Bestätigung)
oc delete deployment webapp-blue

# Rollback falls nötig (zurück zu Blue)
oc patch service webapp-service -p '{"spec":{"selector":{"version":"blue"}}}'

28.4.3 Database-Synchronisation bei Blue-Green

# Database Migration Job vor Green Deployment
apiVersion: batch/v1
kind: Job
metadata:
  name: db-migration-v2
spec:
  template:
    spec:
      containers:
      - name: migrator
        image: webapp:v2.0
        command: ['npm', 'run', 'migrate-forward-compatible']
        env:
        - name: DATABASE_URL
          valueFrom:
            secretKeyRef:
              name: db-credentials
              key: url
      restartPolicy: Never

28.5 Canary Deployments: Risikokontrollierte Einführung

Canary-Deployment-Ansätze dirigieren schrittweise Traffic-Anteile zu neuen Versionen für risikominimierte Validierung vor vollständiger Ausrollung. Diese progressive Exposure-Strategie unterstützt A/B-Testing und Performance-Validierung mit kontrollierten User-Gruppen.

28.5.1 Einfacher Canary-Setup

# Stable Deployment (95% Traffic)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: webapp-stable
spec:
  replicas: 19    # 95% der gewünschten Kapazität
  selector:
    matchLabels:
      app: webapp
      track: stable
  template:
    metadata:
      labels:
        app: webapp
        track: stable
        version: v1.9
    spec:
      containers:
      - name: webapp
        image: webapp:v1.9

---
# Canary Deployment (5% Traffic)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: webapp-canary
spec:
  replicas: 1     # 5% der gewünschten Kapazität
  selector:
    matchLabels:
      app: webapp
      track: canary
  template:
    metadata:
      labels:
        app: webapp
        track: canary
        version: v2.0
    spec:
      containers:
      - name: webapp
        image: webapp:v2.0

---
# Service für beide Tracks
apiVersion: v1
kind: Service
metadata:
  name: webapp-service
spec:
  selector:
    app: webapp    # Matched beide: stable und canary
  ports:
  - port: 80
    targetPort: 8080

28.5.2 Progressive Canary-Rollout

# Phase 1: 5% Canary Traffic
oc scale deployment webapp-stable --replicas=19
oc scale deployment webapp-canary --replicas=1

# Metriken überwachen
oc logs -l track=canary --tail=100
curl -s http://webapp-service/metrics | grep error_rate

# Phase 2: 25% Canary Traffic (bei guten Metriken)
oc scale deployment webapp-stable --replicas=15
oc scale deployment webapp-canary --replicas=5

# Phase 3: 50% Canary Traffic
oc scale deployment webapp-stable --replicas=10
oc scale deployment webapp-canary --replicas=10

# Phase 4: Vollständige Promotion
oc scale deployment webapp-stable --replicas=0
oc scale deployment webapp-canary --replicas=20

# Cleanup: Stable-Deployment entfernen
oc delete deployment webapp-stable

28.5.3 Automatisierter Canary mit Flagger (Istio/Service Mesh)

apiVersion: flagger.app/v1beta1
kind: Canary
metadata:
  name: webapp-canary
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: webapp
  service:
    port: 80
    targetPort: 8080
  analysis:
    interval: 1m
    threshold: 5
    maxWeight: 50
    stepWeight: 10
    metrics:
    - name: request-success-rate
      thresholdRange:
        min: 99
      interval: 1m
    - name: request-duration
      thresholdRange:
        max: 500
      interval: 30s
    webhooks:
    - name: acceptance-test
      type: pre-rollout
      url: http://test-runner.test/
    - name: load-test
      url: http://load-tester.test/
      timeout: 5s
      metadata:
        cmd: "hey -z 1m -q 10 -c 2 http://webapp.default:80/"

28.6 A/B Testing und Feature Flags

A/B Testing erweitert Canary-Deployments um gezielte Benutzer-Segmentierung für wissenschaftliche Validierung von Features oder Änderungen.

28.6.1 Header-basiertes A/B Testing

# Istio VirtualService für A/B Testing
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: webapp-ab-test
spec:
  hosts:
  - webapp.company.com
  http:
  - match:
    - headers:
        user-type:
          exact: "premium"
    route:
    - destination:
        host: webapp-service
        subset: v2
      weight: 100
  - route:
    - destination:
        host: webapp-service
        subset: v1
      weight: 90
    - destination:
        host: webapp-service
        subset: v2
      weight: 10

---
# DestinationRule für Subsets
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: webapp-destination
spec:
  host: webapp-service
  subsets:
  - name: v1
    labels:
      version: v1.9
  - name: v2
    labels:
      version: v2.0

28.6.2 Feature Flags mit External Config

# ConfigMap für Feature Flags
apiVersion: v1
kind: ConfigMap
metadata:
  name: feature-flags
data:
  features.json: |
    {
      "new-checkout-flow": {
        "enabled": true,
        "rollout": 25,
        "audience": ["beta-users"]
      },
      "improved-search": {
        "enabled": false,
        "rollout": 0
      }
    }

---
# Deployment mit Feature Flag Volume
spec:
  template:
    spec:
      containers:
      - name: webapp
        volumeMounts:
        - name: feature-config
          mountPath: /app/config
        env:
        - name: FEATURE_CONFIG_PATH
          value: "/app/config/features.json"
      volumes:
      - name: feature-config
        configMap:
          name: feature-flags

28.7 Failure Recovery und Monitoring

Robuste Deployment-Strategien erfordern automatisierte Failure-Detection und Recovery-Mechanismen für schnelle Problembehebung.

28.7.1 Automatischer Rollback-Trigger

# Deployment mit automatischem Rollback
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: webapp-rollout
spec:
  replicas: 20
  strategy:
    canary:
      analysis:
        templates:
        - templateName: success-rate
        args:
        - name: service-name
          value: webapp-service
      steps:
      - setWeight: 10
      - pause: {duration: 2m}
      - setWeight: 20
      - pause: {duration: 2m}
      - setWeight: 50
      - pause: {duration: 2m}
  selector:
    matchLabels:
      app: webapp

---
# AnalysisTemplate für Metriken
apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
  name: success-rate
spec:
  metrics:
  - name: success-rate
    interval: 10s
    count: 12
    successCondition: result[0] >= 0.95
    failureLimit: 3
    provider:
      prometheus:
        address: http://prometheus.monitoring:9090
        query: |
          sum(rate(http_requests_total{service="{{args.service-name}}",status!~"5.."}[1m])) /
          sum(rate(http_requests_total{service="{{args.service-name}}"}[1m]))

28.7.2 Health Check-Amplification

# Verstärkte Health Checks während Deployments
containers:
- name: webapp
  livenessProbe:
    httpGet:
      path: /health
      port: 8080
    # Verschärfte Settings während Deployment
    initialDelaySeconds: 10    # Statt 30
    periodSeconds: 5          # Statt 15
    timeoutSeconds: 2         # Statt 5
    failureThreshold: 2       # Statt 3
  readinessProbe:
    httpGet:
      path: /ready
      port: 8080
    initialDelaySeconds: 5
    periodSeconds: 2          # Sehr häufig während Deployment
    timeoutSeconds: 1

28.7.3 Monitoring-Dashboard für Deployments

# Deployment-Metriken sammeln
# Error Rate während Deployment
sum(rate(http_requests_total{status=~"5.."}[1m])) by (version)

# Response Time P95
histogram_quantile(0.95, 
  sum(rate(http_request_duration_seconds_bucket[1m])) by (le, version)
)

# Pod Restart Rate
sum(increase(kube_pod_container_status_restarts_total[1m])) by (pod)

# Deployment Progress
(kube_deployment_status_replicas_ready / kube_deployment_spec_replicas) * 100

28.8 Multi-Environment Promotion

Strukturierte Promotion-Pfade gewährleisten schrittweise Validierung von Changes durch verschiedene Umgebungen bis zur Produktion.

28.8.1 GitOps-basierte Promotion-Pipeline

# Argo CD Application für automatische Promotion
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: webapp-promotion
spec:
  project: default
  source:
    repoURL: https://github.com/company/webapp-config
    path: environments
    targetRevision: HEAD
    helm:
      valueFiles:
      - dev/values.yaml      # Start in Development
  destination:
    server: https://kubernetes.default.svc
    namespace: webapp-dev
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
      allowEmpty: false

---
# Promotion-Trigger via Image Updater
apiVersion: argoproj.io/v1alpha1
kind: ImageUpdateAutomation
metadata:
  name: webapp-image-update
spec:
  sourceRef:
    kind: GitRepository
    name: webapp-config
  interval: 1m
  update:
    strategy: Semver
    path: "./environments"
  commit:
    author:
      email: gitops@company.com
      name: GitOps Bot
    messageTemplate: |
      Promote {{range .Updated.Images}}{{println .}}{{end}}

28.8.2 Environment-spezifische Rollback-Strategien

# Development: Schnelle Rollbacks
oc rollout undo deployment/webapp -n webapp-dev

# Staging: Koordinierter Rollback mit Tests
oc rollout undo deployment/webapp -n webapp-staging
oc wait --for=condition=available deployment/webapp -n webapp-staging
./run-smoke-tests.sh staging

# Production: Mehrstufiger Rollback-Prozess
# 1. Traffic auf Previous Version umleiten
oc patch service webapp-service -p '{"spec":{"selector":{"version":"previous"}}}'

# 2. Deployment rollback
oc rollout undo deployment/webapp -n webapp-prod

# 3. Validierung
./run-production-health-check.sh

# 4. Incident Documentation
echo "Rollback completed at $(date)" >> rollback-log.txt

28.9 Ressourcen-Optimierung für Deployment-Strategien

Verschiedene Deployment-Strategien haben unterschiedliche Ressourcenanforderungen, die bei der Cluster-Kapazitätsplanung berücksichtigt werden müssen.

28.9.1 Ressourcen-Overhead nach Strategie

Rolling Updates: - Overhead: 1-2 zusätzliche Pods während Update - Dauer: 2-10 Minuten je nach maxSurge/maxUnavailable - Memory-Spike: Temporär +20-50% während Update

Blue-Green: - Overhead: 100% zusätzliche Ressourcen - Dauer: Sekunden für Switch, Stunden für Test-Phase - Memory-Spike: Dauerhaft doppelt bis Cleanup

Canary: - Overhead: 5-50% zusätzliche Ressourcen während Test - Dauer: Stunden bis Tage für vollständige Promotion - Memory-Spike: Gradueller Anstieg über Zeit

28.9.2 Resource-Aware Deployment-Scheduling

# Deployment mit Resource-Awareness
spec:
  template:
    spec:
      containers:
      - name: webapp
        resources:
          requests:
            cpu: "500m"
            memory: "1Gi"
          limits:
            cpu: "2"
            memory: "4Gi"
      # Placement auf Nodes mit ausreichend Kapazität
      nodeSelector:
        node.kubernetes.io/instance-type: "m5.large"
      tolerations:
      - key: "deployment"
        operator: "Equal"
        value: "allowed"
        effect: "NoSchedule"

28.9.3 Deployment-Performance-Tuning

# Cluster-Kapazität vor Major Deployment prüfen
oc describe nodes | grep -A 5 "Allocated resources"

# Image-Pull-Zeit reduzieren
oc create job image-puller --image=webapp:v2.0 \
  --dry-run=client -o yaml | \
  sed 's/Never/IfNotPresent/' | \
  oc apply -f -

# Parallel Deployment für mehrere Services
for app in frontend backend api; do
  oc rollout restart deployment/$app &
done
wait

# Deployment-Completion warten
for app in frontend backend api; do
  oc rollout status deployment/$app
done

28 Deployment-Strategien