Deployment и ReplicaSet в Kubernetes

Pod — это разовая единица. Deployment — это механизм, который гарантирует, что нужное количество подов всегда работает, умеет их обновлять и откатывать изменения.

Что такое Deployment и зачем он нужен

ReplicaSet следит за тем, чтобы заданное количество идентичных подов было запущено в любой момент. Если Pod упал — ReplicaSet создаст новый. Если узел вышел из строя — поды переедут.

Deployment — это надстройка над ReplicaSet. Он добавляет:

• Управление версиями (история ревизий)
• Rolling update: обновление без простоя
• Rollback: откат к предыдущей версии одной командой

Обычно ты никогда не создаёшь ReplicaSet напрямую — только через Deployment.

Описание желаемого состояния

Kubernetes работает по принципу desired state (желаемое состояние). Ты описываешь, как должна выглядеть система, а K8s сам приводит её к этому виду и поддерживает.

Ты:  "Хочу 3 реплики nginx:1.25"
K8s: [запускает 3 пода]
     [один упал] → [создаёт новый]
     [узел умер] → [переносит поды]

Это декларативный подход в противовес императивному («создай контейнер», «перезапусти», «добавь ещё один»).

YAML пример Deployment

# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
  labels:
    app: my-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
        - name: app
          image: nginx:1.25
          ports:
            - containerPort: 80
          resources:
            requests:
              memory: "64Mi"
              cpu: "100m"
            limits:
              memory: "128Mi"
              cpu: "250m"

Важные части:

• replicas: 3 — сколько подов должно работать
• selector.matchLabels — по каким меткам Deployment находит «свои» поды
• template — шаблон пода. Метки шаблона должны совпадать с selector

# Применить
kubectl apply -f deployment.yaml

# Проверить
kubectl get deployments
# NAME     READY   UP-TO-DATE   AVAILABLE   AGE
# my-app   3/3     3            3           1m

kubectl get pods
# NAME                      READY   STATUS    RESTARTS   AGE
# my-app-7d4b8f9c6-abcd1    1/1     Running   0          1m
# my-app-7d4b8f9c6-efgh2    1/1     Running   0          1m
# my-app-7d4b8f9c6-ijkl3    1/1     Running   0          1m

Rolling Update стратегия

По умолчанию Deployment использует стратегию RollingUpdate:

spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1   # максимум 1 Pod может быть недоступен
      maxSurge: 1         # максимум 1 лишний Pod сверх replicas

При обновлении образа:

1. Создаётся новый Pod с новым образом
2. Ждёт пока он станет Ready
3. Гасится один старый Pod
4. Повторяет для всех реплик

В любой момент приложение доступно.

# Обновить образ
kubectl set image deployment/my-app app=nginx:1.26

# Следить за процессом
kubectl rollout status deployment/my-app
# Waiting for deployment "my-app" rollout to finish: 1 out of 3 new replicas have been updated...
# Waiting for deployment "my-app" rollout to finish: 2 out of 3 new replicas have been updated...
# deployment "my-app" successfully rolled out

Альтернативная стратегия — Recreate: гасит все старые поды, потом поднимает новые. Есть простой, зато не нужна совместимость версий.

kubectl rollout: история и откат

# История ревизий Deployment
kubectl rollout history deployment/my-app
# REVISION  CHANGE-CAUSE
# 1         <none>
# 2         kubectl set image deployment/my-app app=nginx:1.26

# Детали конкретной ревизии
kubectl rollout history deployment/my-app --revision=2

# Откатиться на предыдущую версию
kubectl rollout undo deployment/my-app

# Откатиться на конкретную ревизию
kubectl rollout undo deployment/my-app --to-revision=1

# Приостановить rolling update
kubectl rollout pause deployment/my-app

# Возобновить
kubectl rollout resume deployment/my-app

Чтобы история сохранялась с описанием, добавь аннотацию:

kubectl annotate deployment/my-app kubernetes.io/change-cause="upgrade to nginx 1.26"

HorizontalPodAutoscaler

HPA автоматически масштабирует количество реплик в зависимости от нагрузки.

# hpa.yaml
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: my-app-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-app
  minReplicas: 2
  maxReplicas: 10
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70

kubectl apply -f hpa.yaml

# Следить за состоянием HPA
kubectl get hpa
# NAME          REFERENCE         TARGETS   MINPODS   MAXPODS   REPLICAS
# my-app-hpa   Deployment/my-app  45%/70%   2         10        3

При CPU > 70% HPA добавит реплики. При спаде нагрузки — уберёт, но не меньше minReplicas.

Для работы HPA требуется Metrics Server в кластере:

kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml