Hva er Deployments og ReplicaSets, og hvordan fungerer rolling updates og rollbacks?

Question

IT Interview Practice · Accepted Answer

En **Deployment** er standard-controlleren for å kjøre stateless apper. Den administrerer **ReplicaSets**, og en ReplicaSet holder et angitt antall identiske Pods kjørende. Du redigerer Deploymenten; den orkestrerer **rolling updates** og **rollbacks** for deg.

## Hierarkiet

```text
Deployment  → deklarerer desired state + oppdateringsstrategi (det DU administrerer)
   └── ReplicaSet  → sørger for at N identiske Pods finnes (én per app-versjon)
          └── Pod  → Pod → Pod ...  (de faktiske kjørende kopiene)

Ved hver nye versjon oppretter Deploymenten en NY ReplicaSet og flytter Pods over.
```

## Et Deployment-manifest

```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 4
  selector:
    matchLabels: { app: web }
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1      # maks 1 Pod nede under oppdateringen
      maxSurge: 1            # maks 1 ekstra Pod over ønsket antall
  template:
    metadata:
      labels: { app: web }
    spec:
      containers:
        - name: web
          image: myapp:1.0
          ports:
            - containerPort: 8080
```

## Rolling update: versjonsbytte uten nedetid

```bash
kubectl set image deployment/web web=myapp:2.0   # utløs en rolling update
kubectl rollout status deployment/web            # følg fremdriften
```

```text
maxSurge=1, maxUnavailable=1, replicas=4:
  v1: ████        (start: 4 gamle Pods)
      █████       start 1 ny (v2), nå 5 totalt (surge)
      ███ █       gamle ned til 3, ny er Ready
      ...flytt gradvis...
  v2: ████        (slutt: 4 nye Pods, gammel ReplicaSet skalert til 0)
Trafikk går kun til Pods som består sin readiness probe → ingen nedetid.
```

## Rollback når en release går galt

```bash
kubectl rollout history deployment/web       # list opp revisjoner
kubectl rollout undo deployment/web          # rull tilbake til forrige revisjon
kubectl rollout undo deployment/web --to-revision=3
```

Fordi den gamle ReplicaSet-en beholdes (skalert til 0), er en rollback rask: Kubernetes bare skalerer den forrige ReplicaSet-en opp igjen og den nye ned.

## Skalering

```bash
kubectl scale deployment/web --replicas=10   # endre ønsket antall
```

## Hvorfor det er viktig

Deployments er arbeidshesten for å kjøre stateless applikasjoner på Kubernetes, så å forstå dem og forholdet deres til ReplicaSets er essensiell, daglig kunnskap. Lagdelingen er nøkkelinnsikten: du administrerer en **Deployment**, som eier **ReplicaSets** (én per versjon), og hver ReplicaSet garanterer at et angitt antall identiske Pods kjører — en kjede av reconciliation-loops som til sammen gir self-healing og et stabilt antall replicas. Den virkelige kraften ligger i hvordan Deploymenten håndterer endring: en **rolling update** oppretter en ny ReplicaSet og flytter Pods fra gammel til ny gradvis, styrt av `maxSurge` og `maxUnavailable`, slik at kapasiteten bevares og — kombinert med readiness probes som avgjør hvilke Pods som mottar trafikk — skjer releasen **uten nedetid**. Fordi den forrige ReplicaSet-en beholdes (skalert til null i stedet for slettet), er en **rollback** rask og trygg: `kubectl rollout undo` skalerer bare den gamle versjonen opp igjen og den dårlige ned, akkurat det du griper til når en release oppfører seg dårlig. Å forstå disse mekanismene — pluss hvordan man skalerer (`kubectl scale`) og inspiserer fremdrift (`kubectl rollout status/history`) — er grunnleggende for å levere programvare trygt på Kubernetes, og gjenspeiler den deklarative, controller-drevne modellen som definerer hvordan plattformen fungerer i produksjon.

Hierarkiet

Et Deployment-manifest

Rolling update: versjonsbytte uten nedetid

Rollback når en release går galt

Skalering

Hvorfor det er viktig

Relaterte spørsmål