Vad är Deployments och ReplicaSets, och hur fungerar rolling updates och rollbacks?

Question

IT Interview Practice · Accepted Answer

En **Deployment** är standard-controllern för att köra stateless-appar. Den hanterar **ReplicaSets**, och en ReplicaSet håller ett angivet antal identiska Pods igång. Du redigerar Deployment:en; den orkestrerar **rolling updates** och **rollbacks** åt dig.

## Hierarkin

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

## Ett Deployment-manifest

```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 4
  selector:
    matchLabels: { app: web }
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1      # högst 1 Pod nere under uppdateringen
      maxSurge: 1            # högst 1 extra Pod utöver önskat antal
  template:
    metadata:
      labels: { app: web }
    spec:
      containers:
        - name: web
          image: myapp:1.0
          ports:
            - containerPort: 8080
```

## Rolling update: versionsbyte utan driftstopp

```bash
kubectl set image deployment/web web=myapp:2.0   # utlös en rolling update
kubectl rollout status deployment/web            # följ förloppet
```

```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 när en release går fel

```bash
kubectl rollout history deployment/web       # lista revisioner
kubectl rollout undo deployment/web          # rulla tillbaka till föregående revision
kubectl rollout undo deployment/web --to-revision=3
```

Eftersom den gamla ReplicaSet:en behålls (skalad till 0) går en rollback snabbt: Kubernetes skalar bara upp den föregående ReplicaSet:en igen och ner den nya.

## Skalning

```bash
kubectl scale deployment/web --replicas=10   # ändra önskat antal
```

## Varför det är viktigt

Deployments är arbetshästen för att köra stateless-applikationer på Kubernetes, så att förstå dem och deras relation till ReplicaSets är väsentlig, daglig kunskap. Skiktningen är den centrala insikten: du hanterar en **Deployment**, som äger **ReplicaSets** (en per version), och varje ReplicaSet garanterar att ett angivet antal identiska Pods körs — en kedja av reconciliation loops som tillsammans levererar self-healing och ett stabilt antal replicas. Den verkliga styrkan ligger i hur Deployment:en hanterar förändring: en **rolling update** skapar en ny ReplicaSet och flyttar Pods från gammal till ny gradvis, styrt av `maxSurge` och `maxUnavailable`, så att kapaciteten bevaras och — i kombination med readiness-probes som avgör vilka Pods som tar emot trafik — sker releasen **utan driftstopp**. Eftersom den föregående ReplicaSet:en behålls (skalad till noll snarare än raderad) är en **rollback** snabb och säker: `kubectl rollout undo` skalar helt enkelt upp den gamla versionen igen och ner den dåliga, vilket är precis vad du tar till när en release krånglar. Att förstå denna mekanik — plus hur man skalar (`kubectl scale`) och inspekterar förloppet (`kubectl rollout status/history`) — är grundläggande för att leverera mjukvara säkert på Kubernetes, och speglar den deklarativa, controller-drivna modell som definierar hur plattformen fungerar i produktion.

Hierarkin

Ett Deployment-manifest

Rolling update: versionsbyte utan driftstopp

Rollback när en release går fel

Skalning

Varför det är viktigt

Relaterade frågor