Czym są Deployments i ReplicaSets oraz jak działają rolling updates i rollbacki?

Question

IT Interview Practice · Accepted Answer

**Deployment** to standardowy kontroler do uruchamiania aplikacji bezstanowych. Zarządza on **ReplicaSetami**, a ReplicaSet utrzymuje określoną liczbę identycznych Podów w działaniu. Ty edytujesz Deployment; on orkiestruje **rolling updates** i **rollbacki** za ciebie.

## Hierarchia

```text
Deployment  → deklaruje pożądany stan + strategię aktualizacji (to, czym TY zarządzasz)
   └── ReplicaSet  → zapewnia istnienie N identycznych Podów (jeden na wersję aplikacji)
          └── Pod  → Pod → Pod ...  (faktyczne działające kopie)

Przy każdej nowej wersji Deployment tworzy NOWY ReplicaSet i przenosi do niego Pody.
```

## Manifest Deploymentu

```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 4
  selector:
    matchLabels: { app: web }
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1      # najwyżej 1 Pod wyłączony podczas aktualizacji
      maxSurge: 1            # najwyżej 1 dodatkowy Pod ponad pożądaną liczbę
  template:
    metadata:
      labels: { app: web }
    spec:
      containers:
        - name: web
          image: myapp:1.0
          ports:
            - containerPort: 8080
```

## Rolling update: zmiana wersji bez przestoju

```bash
kubectl set image deployment/web web=myapp:2.0   # wyzwól rolling update
kubectl rollout status deployment/web            # obserwuj postęp
```

```text
maxSurge=1, maxUnavailable=1, replicas=4:
  v1: ████        (start: 4 stare Pody)
      █████       uruchom 1 nowy (v2), teraz łącznie 5 (surge)
      ███ █       stare spadają do 3, nowy jest Ready
      ...stopniowe przenoszenie...
  v2: ████        (koniec: 4 nowe Pody, stary ReplicaSet zeskalowany do 0)
Ruch trafia tylko do Podów, które przejdą readiness probe → brak przestoju.
```

## Rollback, gdy wydanie okaże się złe

```bash
kubectl rollout history deployment/web       # wypisz rewizje
kubectl rollout undo deployment/web          # wycofaj do poprzedniej rewizji
kubectl rollout undo deployment/web --to-revision=3
```

Ponieważ stary ReplicaSet jest zachowany (zeskalowany do 0), rollback jest szybki: Kubernetes po prostu skaluje poprzedni ReplicaSet z powrotem w górę, a nowy w dół.

## Skalowanie

```bash
kubectl scale deployment/web --replicas=10   # zmień pożądaną liczbę
```

## Dlaczego to ważne

Deploymenty są koniem roboczym do uruchamiania aplikacji bezstanowych na Kubernetes, więc zrozumienie ich i ich związku z ReplicaSetami to wiedza niezbędna i codzienna. Warstwowość jest kluczowym spostrzeżeniem: zarządzasz **Deploymentem**, który jest właścicielem **ReplicaSetów** (jeden na wersję), a każdy ReplicaSet gwarantuje, że określona liczba identycznych Podów działa — łańcuch pętli uzgadniania, które razem dostarczają self-healing i stabilną liczbę replik. Prawdziwa moc tkwi w tym, jak Deployment obsługuje zmianę: **rolling update** tworzy nowy ReplicaSet i stopniowo przenosi Pody ze starego do nowego, sterowany przez `maxSurge` i `maxUnavailable`, więc przepustowość jest zachowana i — w połączeniu z readiness probe, które decyduje, które Pody otrzymują ruch — wydanie odbywa się **bez przestoju**. Ponieważ poprzedni ReplicaSet jest zachowywany (zeskalowany do zera, a nie usuwany), **rollback** jest szybki i bezpieczny: `kubectl rollout undo` po prostu skaluje starą wersję z powrotem w górę, a wadliwą w dół, czyli dokładnie po to sięgasz, gdy wydanie zachowuje się niepoprawnie. Zrozumienie tych mechanizmów — plus jak skalować (`kubectl scale`) i podglądać postęp (`kubectl rollout status/history`) — jest fundamentalne dla bezpiecznego dostarczania oprogramowania na Kubernetes i odzwierciedla deklaratywny, sterowany przez kontrolery model, który definiuje sposób działania platformy na produkcji.

Hierarchia

Manifest Deploymentu

Rolling update: zmiana wersji bez przestoju

Rollback, gdy wydanie okaże się złe

Skalowanie

Dlaczego to ważne

Powiązane pytania