22 Deployments und ReplicaSets

Deployments und ReplicaSets bilden das Rückgrat der Anwendungsorchestrierung in OpenShift und implementieren deklarative Mechanismen für Container-Lifecycle-Management. Diese Konstrukte abstrahieren komplexe Orchestrierungslogik und ermöglichen zuverlässige, skalierbare Anwendungsbereitstellung mit minimalen operativen Eingriffen.

22.1 Die Beziehung zwischen Deployments und ReplicaSets

Deployments fungieren als übergeordnete Abstraktionsebene, die gewünschte Anwendungszustände definiert, während ReplicaSets die operative Implementierung dieser Zustände gewährleisten. Diese hierarchische Struktur ermöglicht sowohl strategische Konfiguration als auch taktische Ausführung von Container-Management-Operationen.

Ein Deployment erstellt und verwaltet ReplicaSets automatisch basierend auf Änderungen in der Deployment-Spezifikation. Diese Controller-basierte Architektur gewährleistet kontinuierliche Konvergenz zwischen gewünschtem und aktuellem Systemzustand durch Reconciliation-Loops.

22.1.1 Praktisches Beispiel der Hierarchie

apiVersion: apps/v1
kind: Deployment
metadata:
  name: webapp-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: webapp
  template:
    metadata:
      labels:
        app: webapp
    spec:
      containers:
      - name: webapp
        image: nginx:1.20
        ports:
        - containerPort: 80

Dieses Deployment erstellt automatisch ein ReplicaSet, das wiederum drei Pod-Instanzen verwaltet. ReplicaSets übernehmen die direkte Pod-Verwaltung und implementieren Überwachungs- und Wiederherstellungsmechanismen für einzelne Container-Instanzen. Diese operative Ebene abstrahiert komplexe Pod-Lifecycle-Management-Details von Anwendungsentwicklern.

22.2 Deployment-Strategien

OpenShift unterstützt verschiedene Deployment-Strategien für unterschiedliche Anwendungsanforderungen. Die Wahl der Strategie beeinflusst sowohl Verfügbarkeit während Updates als auch Ressourcenverbrauch.

22.2.1 Rolling Updates

Rolling Deployment-Strategien ermöglichen unterbrechungsfreie Anwendungsupdates durch schrittweisen Austausch alter Container-Instanzen mit neuen Versionen. Diese Strategie minimiert Service-Unterbrechungen und ermöglicht kontinuierliche Verfügbarkeit während Updates.

spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 1

Konfigurationsparameter: - maxUnavailable: Maximale Anzahl Pods, die während des Updates nicht verfügbar sein dürfen - maxSurge: Maximale Anzahl zusätzlicher Pods, die während des Updates erstellt werden dürfen

22.2.2 Blue-Green-Deployments

Blue-Green-Deployment-Muster können über Deployment-Konfigurationen implementiert werden, wobei vollständige Umgebungsreplikation instantane Umschaltung zwischen Versionen ermöglicht. Diese Strategie eignet sich für kritische Anwendungen, die absolute Verfügbarkeit erfordern.

Implementierung: Zwei separate Deployments (Blue und Green) laufen parallel, Service-Selector wird zwischen den Versionen umgeschaltet.

22.2.3 Canary-Deployments

Canary-Deployments ermöglichen graduellen Traffic-Shift zu neuen Anwendungsversionen durch parallele Deployment-Instanzen. Diese risikominimierende Strategie unterstützt A/B-Testing und Performance-Validierung vor vollständiger Ausrollung.

Praktische Umsetzung: Schrittweise Erhöhung der Replica-Anzahl der neuen Version bei gleichzeitiger Reduzierung der alten Version.

22.3 Skalierung und Replica-Management

Horizontale Skalierung erfolgt über Replica-Count-Anpassungen in Deployment-Spezifikationen. Diese deklarative Skalierung ermöglicht sowohl manuelle als auch automatisierte Kapazitätsanpassung basierend auf Last- oder Performance-Metriken.

22.3.1 Manuelle Skalierung

# Skalierung über CLI
oc scale deployment webapp-deployment --replicas=5

# Skalierung über YAML-Update
spec:
  replicas: 5

22.3.2 Automatische Skalierung

Horizontal Pod Autoscaler (HPA) kann mit Deployments konfiguriert werden:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: webapp-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: webapp-deployment
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70

22.3.3 Desired State Management

ReplicaSets implementieren Desired State Management für Pod-Replicas und gewährleisten kontinuierliche Übereinstimmung zwischen konfigurierter und tatsächlicher Pod-Anzahl. Ausgefallene Pods werden automatisch ersetzt, um Verfügbarkeits-SLAs zu erfüllen.

22.3.4 Pod Disruption Budgets

Pod Disruption Budgets können mit Deployments konfiguriert werden, um minimale verfügbare Replica-Anzahl während Wartungsoperationen zu garantieren:

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: webapp-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: webapp

22.4 Ressourcen-Management

Resource Requests und Limits definieren CPU- und Memory-Anforderungen für Deployment-Pods und ermöglichen Scheduler-basierte Platzierungsentscheidungen. Diese Spezifikationen gewährleisten angemessene Ressourcenallokation und verhindern Resource Starvation.

22.4.1 Ressourcen-Spezifikation

spec:
  containers:
  - name: webapp
    image: nginx:1.20
    resources:
      requests:
        cpu: "100m"
        memory: "128Mi"
      limits:
        cpu: "500m"
        memory: "512Mi"

22.4.2 Quality of Service Klassen

Quality of Service-Klassifikationen ergeben sich automatisch aus Resource-Spezifikationen:

22.4.3 Node-Platzierung

Node Affinity und Anti-Affinity-Regeln können in Deployment-Templates definiert werden:

spec:
  template:
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: node-type
                operator: In
                values: ["compute"]
        podAntiAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - weight: 100
            podAffinityTerm:
              labelSelector:
                matchExpressions:
                - key: app
                  operator: In
                  values: ["webapp"]
              topologyKey: kubernetes.io/hostname

22.5 Health Checks und Lifecycle-Management

Health Checks sind essentiell für zuverlässige Anwendungsbereitstellung und automatisierte Fehlerbehebung. OpenShift bietet verschiedene Probe-Typen für unterschiedliche Überwachungsszenarien.

22.5.1 Probe-Arten

Readiness Probes bestimmen, wann neue Pod-Instanzen Traffic empfangen können:

spec:
  containers:
  - name: webapp
    readinessProbe:
      httpGet:
        path: /health
        port: 8080
      initialDelaySeconds: 10
      periodSeconds: 5

Liveness Probes identifizieren defekte Pods für Restart:

spec:
  containers:
  - name: webapp
    livenessProbe:
      httpGet:
        path: /alive
        port: 8080
      initialDelaySeconds: 30
      periodSeconds: 10
      failureThreshold: 3

Startup Probes adressieren Anwendungen mit langen Initialisierungszeiten:

spec:
  containers:
  - name: webapp
    startupProbe:
      httpGet:
        path: /startup
        port: 8080
      initialDelaySeconds: 10
      periodSeconds: 5
      failureThreshold: 12  # 60 Sekunden Startup-Zeit

22.5.2 Lifecycle Hooks

Lifecycle Hooks ermöglichen Anwendungscode-Ausführung bei Pod-Start und vor Pod-Terminierung:

spec:
  containers:
  - name: webapp
    lifecycle:
      postStart:
        exec:
          command: ["/bin/sh", "-c", "echo 'Container started' > /var/log/startup.log"]
      preStop:
        exec:
          command: ["/bin/sh", "-c", "nginx -s quit"]

22.6 Storage-Integration

Volume Mount-Konfigurationen in Deployment-Templates ermöglichen Persistent Storage-Anbindung für stateful Anwendungen. Diese Integration abstrahiert Storage-Komplexität und ermöglicht portable Anwendungsdefinitionen.

22.6.1 Persistent Volume Claims

spec:
  template:
    spec:
      containers:
      - name: webapp
        volumeMounts:
        - name: webapp-storage
          mountPath: /var/www/html
      volumes:
      - name: webapp-storage
        persistentVolumeClaim:
          claimName: webapp-pvc

22.6.2 Init Container

Init Container können in Deployments definiert werden, um Storage-Initialisierung oder Anwendungsvorbereitung durchzuführen:

spec:
  template:
    spec:
      initContainers:
      - name: setup
        image: busybox
        command: ['sh', '-c', 'cp -r /source/* /destination/']
        volumeMounts:
        - name: webapp-storage
          mountPath: /destination
      containers:
      - name: webapp
        # ... Hauptcontainer-Konfiguration

22.6.3 Shared Volumes

Shared Volume-Konfigurationen ermöglichen Datenaustausch zwischen Containern innerhalb derselben Pod-Instanz:

spec:
  template:
    spec:
      containers:
      - name: webapp
        volumeMounts:
        - name: shared-data
          mountPath: /shared
      - name: sidecar
        volumeMounts:
        - name: shared-data
          mountPath: /data
      volumes:
      - name: shared-data
        emptyDir: {}

22.7 Rollback und Versions-Management

Deployment-Revision-History ermöglicht Rollback zu vorherigen Anwendungsversionen bei Problemen oder Fehlern. Diese Version-Control-Funktionalität auf Deployment-Ebene unterstützt schnelle Wiederherstellung und Risk Mitigation.

22.7.1 Rollback-Operationen

# Rollback zum vorherigen Deployment
oc rollout undo deployment/webapp-deployment

# Rollback zu spezifischer Revision
oc rollout undo deployment/webapp-deployment --to-revision=2

# Status des Rollouts prüfen
oc rollout status deployment/webapp-deployment

# Rollout-Historie anzeigen
oc rollout history deployment/webapp-deployment

22.7.2 Revision-Limits

Revision Limits begrenzen die Anzahl gespeicherter ReplicaSet-Versionen:

spec:
  revisionHistoryLimit: 10  # Standard: 10

22.7.3 Annotations und Labels

Annotations und Labels auf Deployment- und ReplicaSet-Ebene ermöglichen Metadaten-Management:

metadata:
  name: webapp-deployment
  labels:
    app: webapp
    tier: frontend
    environment: production
  annotations:
    deployment.kubernetes.io/revision: "3"
    kubernetes.io/change-cause: "Update to nginx 1.20"

22.8 Service Discovery Integration

Selector-basierte Pod-Identifikation verbindet Deployments mit Service-Definitionen für automatische Service Discovery. Diese lose Kopplung ermöglicht flexible Service-Topologien und vereinfacht Anwendungsarchitektur-Evolution.

22.8.1 Service-Deployment-Kopplung

# Service-Definition
apiVersion: v1
kind: Service
metadata:
  name: webapp-service
spec:
  selector:
    app: webapp  # Muss mit Deployment-Labels übereinstimmen
  ports:
  - port: 80
    targetPort: 8080

---
# Deployment mit entsprechenden Labels
apiVersion: apps/v1
kind: Deployment
metadata:
  name: webapp-deployment
spec:
  selector:
    matchLabels:
      app: webapp
  template:
    metadata:
      labels:
        app: webapp  # Service-Selector-Match

22.8.2 Label-basierte Gruppierung

Label-basierte Gruppierung unterstützt komplexe Service-Mesh-Konfigurationen und Traffic-Routing-Strategien:

metadata:
  labels:
    app: webapp
    version: v2
    tier: frontend
    track: stable

Diese Metadaten-gesteuerte Architektur ermöglicht sophisticated Traffic Management ohne Code-Änderungen und unterstützt Service Mesh-Implementierungen wie Istio oder OpenShift Service Mesh.

22.9 Best Practices für Deployment-Management

22.9.1 Deployment-Konfiguration

Rolling Update-Parameter sollten an Anwendungscharakteristika angepasst werden: - Schnell startende Anwendungen: maxSurge: 50%, maxUnavailable: 0 - Ressourcen-intensive Anwendungen: maxSurge: 1, maxUnavailable: 1

Health Checks sollten realistisch konfiguriert werden: - initialDelaySeconds basierend auf tatsächlicher Startup-Zeit - periodSeconds häufig genug für zeitnahe Erkennung - failureThreshold tolerant genug für temporäre Probleme

22.9.2 Monitoring und Observability

Wichtige Metriken für Deployment-Monitoring: - Pod-Restart-Rate (indiziert Anwendungsprobleme) - Rollout-Dauer (Performance-Indikator) - Resource-Utilization (Skalierungsgrund) - Readiness-Probe-Erfolgsrate (Service-Qualität)