Što su Deploymenti i ReplicaSetovi te kako funkcioniraju rolling updates i rollbacki?

Question

IT Interview Practice · Accepted Answer

**Deployment** je standardni controller za pokretanje stateless aplikacija. Upravlja **ReplicaSetovima**, a ReplicaSet održava zadani broj identičnih Podova pokrenutima. Vi uređujete Deployment; on umjesto vas orkestrira **rolling updates** i **rollbacke**.

## Hijerarhija

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

## Manifest Deploymenta

```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 4
  selector:
    matchLabels: { app: web }
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1      # najviše 1 Pod nedostupan tijekom ažuriranja
      maxSurge: 1            # najviše 1 dodatni Pod iznad željenog broja
  template:
    metadata:
      labels: { app: web }
    spec:
      containers:
        - name: web
          image: myapp:1.0
          ports:
            - containerPort: 8080
```

## Rolling update: promjena verzije bez prekida rada

```bash
kubectl set image deployment/web web=myapp:2.0   # pokreni rolling update
kubectl rollout status deployment/web            # prati napredak
```

```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 kad izdanje pođe po zlu

```bash
kubectl rollout history deployment/web       # popis revizija
kubectl rollout undo deployment/web          # vrati na prethodnu reviziju
kubectl rollout undo deployment/web --to-revision=3
```

Budući da se stari ReplicaSet čuva (skaliran na 0), rollback je brz: Kubernetes samo ponovno skalira prethodni ReplicaSet gore, a novi dolje.

## Skaliranje

```bash
kubectl scale deployment/web --replicas=10   # promijeni željeni broj
```

## Zašto je to važno

Deploymenti su radni konj za pokretanje stateless aplikacija na Kubernetesu, pa je njihovo razumijevanje i njihova veza s ReplicaSetovima bitno, svakodnevno znanje. Slojevitost je ključan uvid: vi upravljate **Deploymentom**, koji posjeduje **ReplicaSetove** (jedan po verziji), a svaki ReplicaSet jamči da radi zadani broj identičnih Podova — lanac petlji usklađivanja koje zajedno pružaju samoizlječenje i stabilan broj replika. Prava snaga je u tome kako Deployment obrađuje promjene: **rolling update** kreira novi ReplicaSet i postupno prebacuje Podove sa starog na novi, upravljan parametrima `maxSurge` i `maxUnavailable`, pa se kapacitet očuva i — u kombinaciji s readiness probeovima koji određuju koji Podovi primaju promet — izdanje se odvija **bez prekida rada**. Budući da se prethodni ReplicaSet zadržava (skaliran na nulu umjesto da se briše), **rollback** je brz i siguran: `kubectl rollout undo` jednostavno skalira staru verziju natrag gore, a lošu dolje, što je upravo ono za čim posežete kad se izdanje ponaša loše. Razumijevanje ove mehanike — uz to kako skalirati (`kubectl scale`) i pregledati napredak (`kubectl rollout status/history`) — temeljno je za sigurno isporučivanje softvera na Kubernetesu i odražava deklarativan, controllerom vođen model koji definira kako platforma radi u produkciji.

Hijerarhija

Manifest Deploymenta

Rolling update: promjena verzije bez prekida rada

Rollback kad izdanje pođe po zlu

Skaliranje

Zašto je to važno

Povezana pitanja