Co jsou Deployment a ReplicaSet a jak fungují rolling updaty a rollbacky?

Question

IT Interview Practice · Accepted Answer

**Deployment** je standardní controller pro provoz bezstavových (stateless) aplikací. Řídí **ReplicaSety** a ReplicaSet udržuje běžet zadaný počet identických Podů. Vy upravujete Deployment; on za vás orchestruje **rolling updaty** a **rollbacky**.

## Hierarchie

```text
Deployment  → deklaruje požadovaný stav + strategii aktualizace (to, co řídíte VY)
   └── ReplicaSet  → zajišťuje existenci N identických Podů (jeden na verzi aplikace)
          └── Pod  → Pod → Pod ...  (skutečné běžící kopie)

Při každé nové verzi Deployment vytvoří NOVÝ ReplicaSet a přesune Pody na něj.
```

## Manifest Deploymentu

```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 4
  selector:
    matchLabels: { app: web }
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1      # max 1 Pod mimo provoz během aktualizace
      maxSurge: 1            # max 1 Pod navíc nad požadovaný počet
  template:
    metadata:
      labels: { app: web }
    spec:
      containers:
        - name: web
          image: myapp:1.0
          ports:
            - containerPort: 8080
```

## Rolling update: změna verze bez výpadku

```bash
kubectl set image deployment/web web=myapp:2.0   # spustí rolling update
kubectl rollout status deployment/web            # sleduje průběh
```

```text
maxSurge=1, maxUnavailable=1, replicas=4:
  v1: ████        (start: 4 staré Pody)
      █████       spustí se 1 nový (v2), teď celkem 5 (surge)
      ███ █       staré klesnou na 3, nový je Ready
      ...postupný přesun...
  v2: ████        (konec: 4 nové Pody, starý ReplicaSet zmenšen na 0)
Provoz jde jen na Pody, které projdou readiness probe → žádný výpadek.
```

## Rollback, když se vydání pokazí

```bash
kubectl rollout history deployment/web       # vypíše revize
kubectl rollout undo deployment/web          # vrátí zpět na předchozí revizi
kubectl rollout undo deployment/web --to-revision=3
```

Protože se starý ReplicaSet zachovává (zmenšený na 0), rollback je rychlý: Kubernetes prostě zase zvětší předchozí ReplicaSet a nový zmenší.

## Škálování (scaling)

```bash
kubectl scale deployment/web --replicas=10   # změní požadovaný počet
```

## Proč je to důležité

Deploymenty jsou tažný kůň pro provoz bezstavových aplikací na Kubernetes, takže jejich pochopení a vztah k ReplicaSetům je nezbytná, každodenní znalost. Vrstvení je klíčové: řídíte **Deployment**, který vlastní **ReplicaSety** (jeden na verzi), a každý ReplicaSet zaručuje, že běží zadaný počet identických Podů — řetězec smyček slaďování (reconciliation), které společně přinášejí self-healing a stabilní počet replik. Skutečná síla je v tom, jak Deployment zvládá změnu: **rolling update** vytvoří nový ReplicaSet a postupně přesouvá Pody ze starého na nový, řízeno pomocí `maxSurge` a `maxUnavailable`, takže kapacita zůstává zachována a — v kombinaci s readiness probe, které regulují, které Pody dostávají provoz — vydání proběhne **bez výpadku**. Protože se předchozí ReplicaSet zachovává (zmenšený na nulu, ne smazaný), **rollback** je rychlý a bezpečný: `kubectl rollout undo` prostě zase zvětší starou verzi a špatnou zmenší, což je přesně to, po čem sáhnete, když se vydání zvrtne. Pochopení této mechaniky — plus jak škálovat (`kubectl scale`) a sledovat průběh (`kubectl rollout status/history`) — je základem pro bezpečné dodávání softwaru na Kubernetes a odráží deklarativní, controllery řízený model, který definuje, jak platforma funguje v produkci.

Hierarchie

Manifest Deploymentu

Rolling update: změna verze bez výpadku

Rollback, když se vydání pokazí

Škálování (scaling)

Proč je to důležité

Související otázky