Mitä ovat Deploymentit ja ReplicaSetit, ja miten rolling updatet ja rollbackit toimivat?

Question

IT Interview Practice · Accepted Answer

**Deployment** on vakiokontrolleri tilattomien sovellusten ajamiseen. Se hallitsee **ReplicaSetejä**, ja ReplicaSet pitää tietyn määrän identtisiä Podeja käynnissä. Muokkaat Deploymentia; se orkestroi **rolling updatet** ja **rollbackit** puolestasi.

## Hierarkia

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

## Deployment-manifesti

```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 4
  selector:
    matchLabels: { app: web }
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1      # enintään 1 Pod alhaalla päivityksen aikana
      maxSurge: 1            # enintään 1 ylimääräinen Pod halutun määrän yli
  template:
    metadata:
      labels: { app: web }
    spec:
      containers:
        - name: web
          image: myapp:1.0
          ports:
            - containerPort: 8080
```

## Rolling update: nollakatkoinen versionvaihto

```bash
kubectl set image deployment/web web=myapp:2.0   # laukaise rolling update
kubectl rollout status deployment/web            # seuraa edistymistä
```

```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 kun julkaisu menee pieleen

```bash
kubectl rollout history deployment/web       # listaa revisiot
kubectl rollout undo deployment/web          # palaa edelliseen revisioon
kubectl rollout undo deployment/web --to-revision=3
```

Koska vanha ReplicaSet säilytetään (skaalattuna nollaan), rollback on nopea: Kubernetes vain skaalaa edellisen ReplicaSetin takaisin ylös ja uuden alas.

## Skaalaus

```bash
kubectl scale deployment/web --replicas=10   # muuta haluttua määrää
```

## Miksi se on tärkeää

Deploymentit ovat työjuhta tilattomien sovellusten ajamiseen Kubernetesissa, joten niiden ja niiden ReplicaSet-suhteen ymmärtäminen on olennaista, arkista tietoa. Kerroksellisuus on avaininsight: hallitset **Deploymentia**, joka omistaa **ReplicaSetejä** (yhden versiota kohti), ja kukin ReplicaSet takaa, että tietty määrä identtisiä Podeja on käynnissä — ketju reconciliation-looppeja, jotka yhdessä tuottavat itsekorjauksen ja vakaan replikamäärän. Todellinen voima on siinä, miten Deployment käsittelee muutosta: **rolling update** luo uuden ReplicaSetin ja siirtää Podeja vanhasta uuteen vähitellen, `maxSurgen` ja `maxUnavailablen` ohjaamana, joten kapasiteetti säilyy ja — yhdistettynä readiness-probeihin, jotka portittavat mitkä Podit saavat liikennettä — julkaisu tapahtuu **ilman katkoa**. Koska edellinen ReplicaSet säilytetään (skaalattuna nollaan eikä poistettuna), **rollback** on nopea ja turvallinen: `kubectl rollout undo` yksinkertaisesti skaalaa vanhan version takaisin ylös ja huonon alas, mikä on juuri se mihin tartut kun julkaisu käyttäytyy huonosti. Näiden mekaniikkojen ymmärtäminen — plus miten skaalata (`kubectl scale`) ja tarkastaa edistymistä (`kubectl rollout status/history`) — on perustavaa ohjelmiston turvalliselle toimittamiselle Kubernetesissa, ja heijastaa deklaratiivista, kontrolleriohjattua mallia, joka määrittää miten alusta toimii tuotannossa.

Hierarkia

Deployment-manifesti

Rolling update: nollakatkoinen versionvaihto

Rollback kun julkaisu menee pieleen

Skaalaus

Miksi se on tärkeää

Aiheeseen liittyvät kysymykset