Deployment: контроллер поверх ReplicaSet

Слой над слоем

В Kubernetes контроллеры стоят матрёшкой. Pod это одна копия. ReplicaSet держит N таких копий. Deployment держит ReplicaSet и умеет ещё одну вещь сверху: обновлять версии без даунтайма.

Когда выполняется kubectl apply -f deploy.yaml, происходит так:

1. Создаётся объект Deployment.
2. Deployment-контроллер создаёт ReplicaSet с нужным template.
3. ReplicaSet-контроллер создаёт Pod по template.

Меняется образ в Deployment - контроллер создаёт новый ReplicaSet и постепенно гасит старый. У старого реплики едут к 0, у нового растут до N. Это и есть rolling update, ему посвящён отдельный урок.

Минимальный манифест

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: web
          image: nginxinc/nginx-unprivileged:1.25
          ports:
            - containerPort: 8080

Если сравнить с ReplicaSet, верхние поля почти один в один. Тот же apps/v1, тот же selector.matchLabels, тот же template. Разница только в kind: Deployment и в нескольких необязательных полях, которые появляются у Deployment.

spec.strategy

Как накатывать новую версию. Дефолт RollingUpdate (постепенно), есть ещё Recreate (погасить всё, потом поднять заново). Для RollingUpdate крутятся два параметра:

• maxSurge сколько лишних Pod сверх replicas разрешено создать на время обновления (по умолчанию 25%).
• maxUnavailable сколько Pod можно убить раньше чем поднимутся новые (по умолчанию 25%).

На старте эти поля можно не писать, дефолты разумные.

spec.revisionHistoryLimit

Сколько старых ReplicaSet хранить для отката. По умолчанию 10. Каждый старый RS висит с replicas: 0, но его манифест помнит template на момент того релиза. kubectl rollout undo использует именно их.

Что показывает kubectl

kubectl get deploy web
# NAME   READY   UP-TO-DATE   AVAILABLE   AGE
# web    3/3     3            3           20s

• READY сколько Pod прошли readiness из всего желаемого.
• UP-TO-DATE сколько Pod уже на актуальной версии template.
• AVAILABLE сколько Pod считаются доступными (Ready и стабильно держатся минимум minReadySeconds, по умолчанию 0).

Колонка	Что считает	Меньше READY, когда
READY	Pod, прошедшие readiness	никогда
UP-TO-DATE	Pod на текущем template	идёт rolling update
AVAILABLE	Ready дольше minReadySeconds	minReadySeconds больше нуля

Дальше смотрят сам ReplicaSet, который создал Deployment:

kubectl get rs -l app=web
# NAME             DESIRED   CURRENT   READY   AGE
# web-7d8c9f4b5    3         3         3       25s

Имя ReplicaSet это <deploy-name>-<хеш template>. Хэш меняется каждый раз, когда меняется template (образ, env, что угодно). Так Deployment понимает, какой RS считать новым, а какой старым.

Conditions: что говорит сам Deployment

В статусе у Deployment живёт массив conditions. Главные две:

• Available=True хватает доступных реплик (учитывая maxUnavailable).
• Progressing=True идёт обновление или старт, всё движется.

Если что-то застряло на новом ReplicaSet (например, неправильный образ не тянется), через 10 минут (progressDeadlineSeconds) Progressing перейдёт в False с reason ProgressDeadlineExceeded.

kubectl describe deploy web | grep -A2 Conditions

kubectl scale и kubectl rollout

Два самых частых действия с Deployment:

# Поменять количество реплик на лету
kubectl scale deploy web --replicas=5

# Статус последнего rollout
kubectl rollout status deploy web

# Перезапустить все Pod (новый RS с тем же template)
kubectl rollout restart deploy web

# Откатить на предыдущую ревизию
kubectl rollout undo deploy web

kubectl scale правит spec.replicas через PATCH. Deployment подхватит число и передаст в текущий ReplicaSet, тот добавит или уберёт Pod.

Что задают минимум

В реальных манифестах у Deployment почти всегда есть:

• replicas, обычно 2 или 3 для веба.
• selector.matchLabels совпадающий с метками template (без этого apply упадёт точно как у ReplicaSet).
• template.spec.containers с фиксированным тегом образа и resources.requests/limits.

ReplicaSet напрямую почти не пишут. Всегда Deployment.

Домашка

Теорию закрепляет задание на своём кластере: 3 шага с проверкой. Кластер поднимается по треку Kubernetes локально, задания лежат в репозитории k8s-practice.

./run.sh start k8s-deployment-basics     # развернуть стартовое состояние
./run.sh verify k8s-deployment-basics    # проверить текущий шаг

Коротко

• Deployment управляет ReplicaSet, а тот уже управляет Pod.
• Смена template даёт новый хеш, новый ReplicaSet и rolling update.
• READY про готовность Pod, UP-TO-DATE про соответствие текущему template.
• Застрявший rollout виден в conditions как ProgressDeadlineExceeded.
• revisionHistoryLimit определяет, сколько ревизий доступно для отката.