Kaj so Deployments in ReplicaSets ter kako delujejo postopne posodobitve (rolling updates) in povrnitve (rollbacks)?

Question

IT Interview Practice · Accepted Answer

**Deployment** je standardni krmilnik za poganjanje aplikacij brez stanja (stateless). Upravlja **ReplicaSete**, ReplicaSet pa vzdržuje določeno število enakih Podov v teku. Vi urejate Deployment; ta za vas orkestrira **postopne posodobitve (rolling updates)** in **povrnitve (rollbacks)**.

## Hierarhija

```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      # med posodobitvijo je nedostopen največ 1 Pod
      maxSurge: 1            # največ 1 dodaten Pod nad želenim številom
  template:
    metadata:
      labels: { app: web }
    spec:
      containers:
        - name: web
          image: myapp:1.0
          ports:
            - containerPort: 8080
```

## Postopna posodobitev: sprememba različice brez izpada

```bash
kubectl set image deployment/web web=myapp:2.0   # sproži postopno posodobitev
kubectl rollout status deployment/web            # spremljaj napredek
```

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

## Povrnitev, ko gre izdaja narobe

```bash
kubectl rollout history deployment/web       # naštej revizije
kubectl rollout undo deployment/web          # povrni na prejšnjo revizijo
kubectl rollout undo deployment/web --to-revision=3
```

Ker se stari ReplicaSet ohrani (skaliran na 0), je povrnitev hitra: Kubernetes le znova poveča prejšnji ReplicaSet in zmanjša novega.

## Skaliranje

```bash
kubectl scale deployment/web --replicas=10   # spremeni želeno število
```

## Zakaj je to pomembno

Deployments so delovni konj za poganjanje aplikacij brez stanja na Kubernetesu, zato je njihovo razumevanje in razumevanje njihovega odnosa do ReplicaSetov bistveno, vsakdanje znanje. Ključni uvid je plastenje: vi upravljate **Deployment**, ki ima v lasti **ReplicaSete** (enega na različico), vsak ReplicaSet pa zagotavlja, da teče določeno število enakih Podov — veriga usklajevalnih zank, ki skupaj zagotavljajo samodejno okrevanje in stabilno število replik. Prava moč je v tem, kako Deployment obravnava spremembe: **postopna posodobitev** ustvari nov ReplicaSet in postopoma prestavlja Pode s starega na novega, uravnavana z `maxSurge` in `maxUnavailable`, tako da se zmogljivost ohrani in — v kombinaciji z readiness probe, ki nadzira, kateri Podi prejemajo promet — izdaja poteka **brez izpada**. Ker se prejšnji ReplicaSet ohrani (skaliran na nič namesto izbrisan), je **povrnitev** hitra in varna: `kubectl rollout undo` preprosto znova poveča staro različico in zmanjša pokvarjeno, kar je natanko tisto, po čemer posežete, ko se izdaja obnaša napačno. Razumevanje teh mehanizmov — plus kako skalirati (`kubectl scale`) in pregledovati napredek (`kubectl rollout status/history`) — je temeljno za varno dostavljanje programske opreme na Kubernetesu in odraža deklarativni model, ki ga poganjajo krmilniki in ki opredeljuje delovanje platforme v produkciji.

Hierarhija

Manifest Deploymenta

Postopna posodobitev: sprememba različice brez izpada

Povrnitev, ko gre izdaja narobe

Skaliranje

Zakaj je to pomembno

Povezana vprašanja