Mik azok a Deploymentek és ReplicaSetek, és hogyan működik a rolling update és a rollback?

Question

IT Interview Practice · Accepted Answer

A **Deployment** a standard controller stateless alkalmazások futtatásához. **ReplicaSeteket** kezel, egy ReplicaSet pedig egy megadott számú, egyforma Podot tart futásban. Te a Deploymentet szerkeszted; az pedig a **rolling update**-eket és **rollbackeket** orchestrálja helyetted.

## A hierarchia

```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.
```

## Egy Deployment manifest

```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 4
  selector:
    matchLabels: { app: web }
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1      # legfeljebb 1 Pod állhat le a frissítés alatt
      maxSurge: 1            # legfeljebb 1 Poddal több a kívánt számnál
  template:
    metadata:
      labels: { app: web }
    spec:
      containers:
        - name: web
          image: myapp:1.0
          ports:
            - containerPort: 8080
```

## Rolling update: leállás nélküli verzióváltás

```bash
kubectl set image deployment/web web=myapp:2.0   # rolling update kiváltása
kubectl rollout status deployment/web            # a folyamat követése
```

```text
maxSurge=1, maxUnavailable=1, replicas=4:
  v1: ████        (start: 4 old Pods)
      █████       spin up 1 new (v2), now 5 total (surge)
      ███ █       old down to 3, new is Ready
      ...gradually shift...
  v2: ████        (end: 4 new Pods, old ReplicaSet scaled to 0)
Traffic only goes to Pods that pass their readiness probe → no downtime.
```

## Rollback, amikor egy kiadás elromlik

```bash
kubectl rollout history deployment/web       # a revíziók listázása
kubectl rollout undo deployment/web          # visszaállás az előző revízióra
kubectl rollout undo deployment/web --to-revision=3
```

Mivel a régi ReplicaSet megmarad (0-ra skálázva), a rollback gyors: a Kubernetes egyszerűen visszaskálázza az előző ReplicaSetet, az újat pedig leskálázza.

## Skálázás

```bash
kubectl scale deployment/web --replicas=10   # a kívánt szám módosítása
```

## Miért fontos

A Deployment a "munkagép" stateless alkalmazások Kubernetesen való futtatásához, ezért ennek és a ReplicaSetekhez való viszonyának megértése elengedhetetlen, mindennapi tudás. A rétegzettség a kulcs felismerés: egy **Deploymentet** kezelsz, amely **ReplicaSeteket** birtokol (verziónként egyet), és minden ReplicaSet garantálja, hogy megadott számú, egyforma Pod fut — reconciliation-loopok láncolata, amelyek együtt öngyógyítást és stabil replikaszámot adnak. Az igazi erő abban van, ahogy a Deployment a változást kezeli: egy **rolling update** új ReplicaSetet hoz létre, és a Podokat fokozatosan váltja a régiről az újra, a `maxSurge` és `maxUnavailable` által szabályozva, így a kapacitás megmarad, és — a readiness probe-okkal kombinálva, amelyek eldöntik, mely Podok kapnak forgalmat — a kiadás **leállás nélkül** történik. Mivel az előző ReplicaSet megmarad (nullára skálázva, nem törölve), a **rollback** gyors és biztonságos: a `kubectl rollout undo` egyszerűen visszaskálázza a régi verziót, a rosszat pedig leskálázza — pontosan ezt kapod elő, amikor egy kiadás rosszul viselkedik. Ezeknek a mechanizmusoknak a megértése — plusz a skálázás (`kubectl scale`) és a folyamat vizsgálata (`kubectl rollout status/history`) — alapvető a szoftver biztonságos szállításához Kubernetesen, és tükrözi azt a deklaratív, controller által vezérelt modellt, amely meghatározza, hogyan működik a platform production környezetben.

A hierarchia

Egy Deployment manifest

Rolling update: leállás nélküli verzióváltás

Rollback, amikor egy kiadás elromlik

Skálázás

Miért fontos

Kapcsolódó kérdések