Was sind Deployments und ReplicaSets, und wie funktionieren rolling updates und rollbacks?

Question

IT Interview Practice · Accepted Answer

Ein **Deployment** ist der Standard-Controller für den Betrieb stateless Anwendungen. Es verwaltet **ReplicaSets**, und ein ReplicaSet hält eine festgelegte Anzahl identischer Pods am Laufen. Du bearbeitest das Deployment; es orchestriert **rolling updates** und **rollbacks** für dich.

## Die Hierarchie

```text
Deployment  → declares desired state + update strategy (the thing YOU manage)
   └── ReplicaSet  → ensures N identical Pods exist (one per app version)
          └── Pod  → Pod → Pod ...  (the actual running copies)

On each new version, the Deployment creates a NEW ReplicaSet and shifts Pods over.
```

## Ein Deployment-Manifest

```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 4
  selector:
    matchLabels: { app: web }
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1      # höchstens 1 Pod während des Updates ausgefallen
      maxSurge: 1            # höchstens 1 zusätzlicher Pod über der gewünschten Anzahl
  template:
    metadata:
      labels: { app: web }
    spec:
      containers:
        - name: web
          image: myapp:1.0
          ports:
            - containerPort: 8080
```

## Rolling update: Versionswechsel ohne Downtime

```bash
kubectl set image deployment/web web=myapp:2.0   # ein rolling update auslösen
kubectl rollout status deployment/web            # Fortschritt beobachten
```

```text
maxSurge=1, maxUnavailable=1, replicas=4:
  v1: ████        (Start: 4 alte Pods)
      █████       1 neuen (v2) hochfahren, jetzt insgesamt 5 (surge)
      ███ █       alte auf 3 reduziert, neuer ist Ready
      ...schrittweise verschieben...
  v2: ████        (Ende: 4 neue Pods, altes ReplicaSet auf 0 skaliert)
Traffic geht nur an Pods, die ihre readiness probe bestehen → keine Downtime.
```

## Rollback, wenn ein Release schiefgeht

```bash
kubectl rollout history deployment/web       # Revisionen auflisten
kubectl rollout undo deployment/web          # zur vorherigen Revision zurückrollen
kubectl rollout undo deployment/web --to-revision=3
```

Weil das alte ReplicaSet erhalten bleibt (auf 0 skaliert), ist ein Rollback schnell: Kubernetes skaliert einfach das vorherige ReplicaSet wieder hoch und das neue herunter.

## Skalierung

```bash
kubectl scale deployment/web --replicas=10   # gewünschte Anzahl ändern
```

## Warum es wichtig ist

Deployments sind das Arbeitspferd für den Betrieb stateless Anwendungen auf Kubernetes, daher ist das Verständnis von ihnen und ihrer Beziehung zu ReplicaSets essenzielles Alltagswissen. Die Schichtung ist die zentrale Einsicht: Du verwaltest ein **Deployment**, das **ReplicaSets** besitzt (eines pro Version), und jedes ReplicaSet garantiert, dass eine festgelegte Anzahl identischer Pods läuft — eine Kette von reconciliation loops, die zusammen self-healing und eine stabile Replica-Anzahl liefern. Die eigentliche Stärke liegt darin, wie das Deployment Änderungen behandelt: Ein **rolling update** erstellt ein neues ReplicaSet und verschiebt Pods schrittweise von alt zu neu, gesteuert von `maxSurge` und `maxUnavailable`, sodass Kapazität erhalten bleibt und — kombiniert mit readiness probes, die entscheiden, welche Pods Traffic erhalten — das Release **ohne Downtime** erfolgt. Weil das vorherige ReplicaSet erhalten bleibt (auf null skaliert statt gelöscht), ist ein **rollback** schnell und sicher: `kubectl rollout undo` skaliert einfach die alte Version wieder hoch und die fehlerhafte herunter — genau das, wonach du greifst, wenn ein Release sich schlecht verhält. Diese Mechanik zu verstehen — plus wie man skaliert (`kubectl scale`) und den Fortschritt prüft (`kubectl rollout status/history`) — ist grundlegend, um Software sicher auf Kubernetes auszuliefern, und spiegelt das deklarative, controllergetriebene Modell wider, das definiert, wie die Plattform in Produktion arbeitet.

Die Hierarchie

Ein Deployment-Manifest

Rolling update: Versionswechsel ohne Downtime

Rollback, wenn ein Release schiefgeht

Skalierung

Warum es wichtig ist

Ähnliche Fragen