Что такое Deployment и ReplicaSet, и как работают rolling update и откаты?

Question

IT Interview Practice · Accepted Answer

**Deployment** — это стандартный controller для запуска stateless-приложений. Он управляет **ReplicaSet**, а ReplicaSet поддерживает работу заданного числа идентичных Pod. Вы редактируете Deployment; он оркестрирует **rolling update** и **откаты** за вас.

## Иерархия

```text
Deployment  → объявляет желаемое состояние + стратегию обновления (то, чем управляете ВЫ)
   └── ReplicaSet  → гарантирует существование N идентичных Pod (по одному на версию приложения)
          └── Pod  → Pod → Pod ...  (реальные работающие копии)

При каждой новой версии Deployment создаёт НОВЫЙ ReplicaSet и переносит Pod на него.
```

## Manifest Deployment

```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 4
  selector:
    matchLabels: { app: web }
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1      # максимум 1 Pod недоступен во время обновления
      maxSurge: 1            # максимум 1 лишний Pod сверх желаемого числа
  template:
    metadata:
      labels: { app: web }
    spec:
      containers:
        - name: web
          image: myapp:1.0
          ports:
            - containerPort: 8080
```

## Rolling update: смена версии без простоя

```bash
kubectl set image deployment/web web=myapp:2.0   # запустить rolling update
kubectl rollout status deployment/web            # следить за прогрессом
```

```text
maxSurge=1, maxUnavailable=1, replicas=4:
  v1: ████        (старт: 4 старых Pod)
      █████       поднимаем 1 новый (v2), теперь всего 5 (surge)
      ███ █       старых стало 3, новый готов (Ready)
      ...постепенный перенос...
  v2: ████        (конец: 4 новых Pod, старый ReplicaSet масштабирован в 0)
Трафик идёт только на Pod, прошедшие readiness probe → нет простоя.
```

## Откат, когда релиз оказался плохим

```bash
kubectl rollout history deployment/web       # список ревизий
kubectl rollout undo deployment/web          # откатиться к предыдущей ревизии
kubectl rollout undo deployment/web --to-revision=3
```

Поскольку старый ReplicaSet сохраняется (масштабирован в 0), откат быстрый: Kubernetes просто масштабирует предыдущий ReplicaSet обратно вверх, а новый — вниз.

## Масштабирование

```bash
kubectl scale deployment/web --replicas=10   # изменить желаемое число
```

## Почему это важно

Deployment — рабочая лошадка для запуска stateless-приложений на Kubernetes, поэтому понимание его и его связи с ReplicaSet — существенное, повседневное знание. Ключевая идея — в слоях: вы управляете **Deployment**, который владеет **ReplicaSet** (по одному на версию), а каждый ReplicaSet гарантирует работу заданного числа идентичных Pod — цепочка циклов согласования, которые вместе обеспечивают самовосстановление и стабильное число реплик. Настоящая сила — в том, как Deployment обрабатывает изменения: **rolling update** создаёт новый ReplicaSet и постепенно переносит Pod со старого на новый, управляемый параметрами `maxSurge` и `maxUnavailable`, так что пропускная способность сохраняется и — в сочетании с readiness probe, которые определяют, какие Pod получают трафик, — релиз происходит **без простоя**. Поскольку предыдущий ReplicaSet сохраняется (масштабируется в ноль, а не удаляется), **откат** быстр и безопасен: `kubectl rollout undo` просто масштабирует старую версию обратно вверх, а плохую — вниз, и это именно то, к чему вы прибегаете, когда релиз ведёт себя плохо. Понимание этих механик — плюс того, как масштабировать (`kubectl scale`) и проверять прогресс (`kubectl rollout status/history`), — фундаментально для безопасной поставки ПО на Kubernetes и отражает декларативную, управляемую контроллерами модель, определяющую то, как платформа работает в production.

Иерархия

Manifest Deployment

Rolling update: смена версии без простоя

Откат, когда релиз оказался плохим

Масштабирование

Почему это важно

Похожие вопросы