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

Question

IT Interview Practice · Accepted Answer

En **Deployment** er standard-controlleren til at køre stateless apps. Den administrerer **ReplicaSets**, og et ReplicaSet holder et angivet antal identiske Pods kørende. Du redigerer Deployment'en; den orkestrerer **rolling updates** og **rollbacks** for dig.

## Hierarkiet

```text
Deployment  → erklærer ønsket tilstand + update-strategi (det DU administrerer)
   └── ReplicaSet  → sikrer at N identiske Pods findes (én pr. app-version)
          └── Pod  → Pod → Pod ...  (de faktiske kørende kopier)

Ved hver ny version opretter Deployment'en et NYT 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      # højst 1 Pod nede under updaten
      maxSurge: 1            # højst 1 ekstra Pod ud over ønsket antal
  template:
    metadata:
      labels: { app: web }
    spec:
      containers:
        - name: web
          image: myapp:1.0
          ports:
            - containerPort: 8080
```

## Rolling update: versionsskift uden downtime

```bash
kubectl set image deployment/web web=myapp:2.0   # udlø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), nu 5 i alt (surge)
      ███ █       gamle nede på 3, ny er Ready
      ...flyt gradvist...
  v2: ████        (slut: 4 nye Pods, gammelt ReplicaSet skaleret til 0)
Trafik går kun til Pods, der består deres readiness probe → ingen downtime.
```

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

```bash
kubectl rollout history deployment/web       # list revisioner
kubectl rollout undo deployment/web          # rul tilbage til forrige revision
kubectl rollout undo deployment/web --to-revision=3
```

Fordi det gamle ReplicaSet beholdes (skaleret til 0), er en rollback hurtig: Kubernetes skalerer bare det forrige ReplicaSet op igen og det nye ned.

## Skalering

```bash
kubectl scale deployment/web --replicas=10   # ændr ønsket antal
```

## Hvorfor det betyder noget

Deployments er arbejdshesten til at køre stateless applikationer på Kubernetes, så det er essentiel hverdagsviden at forstå dem og deres forhold til ReplicaSets. Lagdelingen er den centrale indsigt: du administrerer en **Deployment**, som ejer **ReplicaSets** (ét pr. version), og hvert ReplicaSet garanterer, at et angivet antal identiske Pods kører — en kæde af reconciliation-loops, der tilsammen leverer self-healing og et stabilt antal replicas. Den egentlige styrke ligger i, hvordan Deployment'en håndterer ændringer: en **rolling update** opretter et nyt ReplicaSet og flytter gradvist Pods fra gammel til ny, styret af `maxSurge` og `maxUnavailable`, så kapaciteten bevares og — kombineret med readiness probes, der afgør, hvilke Pods der modtager trafik — sker releasen med **nul downtime**. Fordi det forrige ReplicaSet bevares (skaleret til nul i stedet for slettet), er en **rollback** hurtig og sikker: `kubectl rollout undo` skalerer simpelthen den gamle version op igen og den fejlbehæftede ned, hvilket er præcis, hvad man griber til, når en release opfører sig forkert. At forstå denne mekanik — plus hvordan man skalerer (`kubectl scale`) og inspicerer fremdrift (`kubectl rollout status/history`) — er fundamentalt for at levere software sikkert på Kubernetes og afspejler den deklarative, controller-drevne model, der definerer, hvordan platformen fungerer i production.

Hierarkiet

Et Deployment-manifest

Rolling update: versionsskift uden downtime

Rollback når en release går galt

Skalering

Hvorfor det betyder noget

Relaterede spørgsmål