Deployment і ReplicaSet

Після модуля ви зможете пояснити зв’язок Deployment, ReplicaSet і Pod, розрахувати параметри RollingUpdate, спостерігати revisions, виконувати 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 містить обидві revisions.

Навмисно вкажіть відсутній 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.