Kas yra Deployment'ai ir ReplicaSet'ai ir kaip veikia rolling updates bei rollbacks?

Question

IT Interview Practice · Accepted Answer

**Deployment'as** yra standartinis controller'is stateless aplikacijoms paleisti. Jis valdo **ReplicaSet'us**, o ReplicaSet'as palaiko nurodytą skaičių identiškų Pod'ų veikiančių. Jūs redaguojate Deployment'ą; jis už jus orkestruoja **rolling updates** ir **rollbacks**.

## Hierarchija

```text
Deployment  → deklaruoja pageidaujamą būseną + atnaujinimo strategiją (tai, ką JŪS valdote)
   └── ReplicaSet  → užtikrina, kad egzistuotų N identiškų Pod'ų (po vieną kiekvienai app versijai)
          └── Pod  → Pod → Pod ...  (tikrosios veikiančios kopijos)

Kiekvienai naujai versijai Deployment'as sukuria NAUJĄ ReplicaSet'ą ir palaipsniui perkelia Pod'us.
```

## Deployment'o manifest'as

```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 4
  selector:
    matchLabels: { app: web }
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1      # daugiausiai 1 Pod'as neveikiantis atnaujinimo metu
      maxSurge: 1            # daugiausiai 1 papildomas Pod'as virš pageidaujamo skaičiaus
  template:
    metadata:
      labels: { app: web }
    spec:
      containers:
        - name: web
          image: myapp:1.0
          ports:
            - containerPort: 8080
```

## Rolling update: versijos keitimas be prastovų

```bash
kubectl set image deployment/web web=myapp:2.0   # paleisti rolling update
kubectl rollout status deployment/web            # stebėti eigą
```

```text
maxSurge=1, maxUnavailable=1, replicas=4:
  v1: ████        (pradžia: 4 seni Pod'ai)
      █████       paleidžiamas 1 naujas (v2), dabar iš viso 5 (surge)
      ███ █       seni sumažėja iki 3, naujas jau Ready
      ...palaipsniui perkeliama...
  v2: ████        (pabaiga: 4 nauji Pod'ai, senas ReplicaSet sumažintas iki 0)
Srautas eina tik į Pod'us, praėjusius savo readiness probe → jokių prastovų.
```

## Rollback, kai išleidimas nepavyksta

```bash
kubectl rollout history deployment/web       # išvardyti revizijas
kubectl rollout undo deployment/web          # grįžti prie ankstesnės revizijos
kubectl rollout undo deployment/web --to-revision=3
```

Kadangi senas ReplicaSet'as išsaugomas (sumažintas iki 0), rollback yra greitas: Kubernetes tiesiog padidina ankstesnį ReplicaSet'ą ir sumažina naująjį.

## Mastelio keitimas (scaling)

```bash
kubectl scale deployment/web --replicas=10   # pakeisti pageidaujamą skaičių
```

## Kodėl tai svarbu

Deployment'ai yra pagrindinis „darbinis arklys" stateless aplikacijoms Kubernetes'e paleisti, tad suprasti juos ir jų ryšį su ReplicaSet'ais yra esminė, kasdienė žinia. Sluoksniavimas yra pagrindinė įžvalga: jūs valdote **Deployment'ą**, kuris valdo **ReplicaSet'us** (po vieną kiekvienai versijai), ir kiekvienas ReplicaSet'as garantuoja, kad veikia nurodytas skaičius identiškų Pod'ų — derinimo ciklų grandinė, kuri kartu suteikia savaiminį atsistatymą ir stabilų replikų skaičių. Tikroji galia slypi tame, kaip Deployment'as tvarko pokyčius: **rolling update** sukuria naują ReplicaSet'ą ir palaipsniui perkelia Pod'us iš seno į naują, valdomas `maxSurge` ir `maxUnavailable`, tad pajėgumas išsaugomas ir — kartu su readiness probe, kurios lemia, kurie Pod'ai gauna srautą — išleidimas įvyksta **be prastovų**. Kadangi ankstesnis ReplicaSet'as išsaugomas (sumažintas iki nulio, o ne ištrintas), **rollback** yra greitas ir saugus: `kubectl rollout undo` tiesiog padidina seną versiją ir sumažina blogąją — būtent to griebiatės, kai išleidimas elgiasi netinkamai. Šių mechanizmų supratimas — plius kaip keisti mastelį (`kubectl scale`) ir tikrinti eigą (`kubectl rollout status/history`) — yra pamatas saugiai išleisti programinę įrangą Kubernetes'e ir atspindi deklaratyvų, controller'ių valdomą modelį, apibrėžiantį, kaip platforma veikia production aplinkoje.

Hierarchija

Deployment'o manifest'as

Rolling update: versijos keitimas be prastovų

Rollback, kai išleidimas nepavyksta

Mastelio keitimas (scaling)

Kodėl tai svarbu

Susiję klausimai