Deployment и ReplicaSet

После модуля вы сможете объяснить связь Deployment, ReplicaSet и Pod, рассчитать параметры RollingUpdate, наблюдать ревизии, выполнять rollback и диагностировать остановившийся rollout.

• декларативное управление stateless workload
• revision и Pod template
• maxUnavailable и maxSurge
• Progressing Conditions и безопасный rollback

Deployment управляет ReplicaSets, а ReplicaSet поддерживает количество Pods. Не редактируйте управляемый ReplicaSet вручную: Deployment снова приведёт цепочку к своему spec.

Новая revision появляется только при изменении .spec.template. Изменение replicas не создаёт revision, поэтому scaling и rollback Pod template являются разными операциями.

При RollingUpdate новый ReplicaSet постепенно увеличивается, а старый уменьшается. maxUnavailable ограничивает число недоступных Pods; maxSurge — число дополнительных Pods сверх replicas. Проценты округляются по-разному: unavailable вниз, surge вверх.

Для replicas=4, maxUnavailable=1 и maxSurge=1 во время обновления допускается не меньше трёх доступных и не больше пяти создаваемых Pods. Реальная доступность зависит от readiness.

minReadySeconds задаёт время стабильной готовности до признания Pod available. progressDeadlineSeconds ограничивает ожидание прогресса и создаёт Condition Progressing=False с reason ProgressDeadlineExceeded.

Важно: progressDeadlineSeconds не выполняет автоматический rollback. Контроллер продолжает попытки; решение об откате принимает оператор или внешняя автоматизация. revisionHistoryLimit определяет число старых ReplicaSets, доступных для rollback.

• Изменяйте Deployment, а не его ReplicaSet или Pods
• Перед rollout проверяйте capacity для maxSurge и бюджет доступности
• Используйте фиксированный проверенный image tag или digest
• Наблюдайте Deployment Conditions, ReplicaSets, Pods и Events вместе
• Не считайте timeout команды доказательством причины: найдите конкретный reason
• Перед rollback проверьте rollout history и содержимое нужной revision

Сохраните манифест как deployment.yaml. Selector и template labels совпадают; стратегия допускает один недоступный и один дополнительный Pod.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
  namespace: lab-deploy
  labels:
    app.kubernetes.io/name: web
spec:
  replicas: 4
  revisionHistoryLimit: 3
  progressDeadlineSeconds: 20
  minReadySeconds: 5
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 1
  selector:
    matchLabels:
      app.kubernetes.io/name: web
  template:
    metadata:
      labels:
        app.kubernetes.io/name: web
    spec:
      containers:
        - name: nginx
          image: nginx:1.28-alpine
          ports:
            - name: http
              containerPort: 80
          readinessProbe:
            httpGet:
              path: /
              port: http
            initialDelaySeconds: 2
            periodSeconds: 3

Создайте Deployment, дождитесь Available, обновите image и сопоставьте новую ReplicaSet с revision.

kubectl create namespace lab-deploy
kubectl apply --server-side --field-manager=course-lab -f deployment.yaml
kubectl rollout status deployment/web -n lab-deploy --timeout=120s
kubectl get deployment,replicaset,pod -n lab-deploy -o wide
kubectl get deployment web -n lab-deploy -o jsonpath='{.status.updatedReplicas}{" updated; "}{.status.availableReplicas}{" available\n"}'
kubectl annotate deployment/web -n lab-deploy kubernetes.io/change-cause='nginx 1.29-alpine'
kubectl set image deployment/web nginx=nginx:1.29-alpine -n lab-deploy
kubectl rollout status deployment/web -n lab-deploy --timeout=120s
kubectl rollout history deployment/web -n lab-deploy
kubectl get replicasets -n lab-deploy --sort-by=.metadata.creationTimestamp

Критерий: четыре Ready Pod используют nginx:1.29-alpine, новая ReplicaSet имеет четыре replicas, старая — ноль, rollout history содержит обе ревизии.

Намеренно укажите отсутствующий image. Старые Pods сохраняют доступность в пределах стратегии, а новая ReplicaSet не может завершить rollout.

kubectl annotate deployment/web -n lab-deploy kubernetes.io/change-cause='broken image' --overwrite
kubectl set image deployment/web nginx=nginx:does-not-exist -n lab-deploy
kubectl rollout status deployment/web -n lab-deploy --timeout=30s
kubectl get deployment,replicaset,pod -n lab-deploy
kubectl get deployment web -n lab-deploy -o jsonpath='{range .status.conditions[*]}{.type}{"="}{.status}{" reason="}{.reason}{"\n"}{end}'
kubectl describe deployment web -n lab-deploy
kubectl events -n lab-deploy --types=Warning
kubectl rollout history deployment/web -n lab-deploy
kubectl rollout undo deployment/web -n lab-deploy
kubectl rollout status deployment/web -n lab-deploy --timeout=120s
kubectl delete namespace lab-deploy

Диагностическая цепочка: Deployment Conditions → сравнение ReplicaSets → Pod waiting.reason → Warning Events → rollout history → rollback. ProgressDeadlineExceeded только сообщает о проблеме и сам не откатывает Deployment.

• Какое изменение создаёт новую revision?
• Чем maxSurge отличается от maxUnavailable?
• Почему Deployment может быть Available, но rollout ещё не завершён?
• Что делает progressDeadlineSeconds и чего он не делает?
• Почему revisionHistoryLimit=0 исключает rollback?

Модуль освоен, если вы прогнозируете диапазон Pods при RollingUpdate, находите активную и старую ReplicaSets, доказываете причину остановки и выполняете контролируемый rollback.