Что произойдет при обновлении image в Deployment?

Процесс обновления образа (image) в Kubernetes Deployment

При обновлении образа в Deployment Kubernetes инициирует стратегический процесс обновления, называемый rolling update. Это ключевой механизм для бесшокового развертывания новых версий приложений. Рассмотрим детальный пошаговый процесс и его последствия.

Последовательность событий при обновлении

1. Изменение манифеста: Вы обновляете поле spec.template.spec.containers[].image в манифесте Deployment (например, с myapp:v1.0 на myapp:v1.1) и применяете изменения через kubectl apply -f deployment.yaml или используете команду kubectl set image deployment/myapp-deployment myapp-container=myapp:v1.1.

2. Запуск процесса обновления:

    *   Контроллер **Deployment** в `kube-controller-manager` обнаруживает изменение в желаемом состоянии (`spec.template`).
    *   Он не изменяет существующие Pod напрямую. Вместо этого он создает новый **ReplicaSet**.
    *   Новый ReplicaSet получает шаблон Pod с обновленным образом.

1. Постепенная замена Pod (Rolling Update):

    *   По умолчанию стратегия обновления — `RollingUpdate`.
    *   Новый ReplicaSet начинает масштабироваться от 0 до желаемого количества реплик (`replicas`), в то время как старый ReplicaSet масштабируется вниз до 0.
    *   Процесс управляется двумя ключевыми параметрами:
        *   `maxUnavailable`: Максимальное количество Pod, которые могут быть недоступны во время обновления (по умолчанию 25%). Это определяет, насколько быстро можно удалять старые Pod.
        *   `maxSurge`: Максимальное количество Pod, которые могут быть созданы сверх желаемого количества (по умолчанию 25%). Это определяет, насколько быстро можно создавать новые Pod.

1. Readiness Probe и доступность сервиса:

    *   Критически важную роль играют проверки жизнеспособности (**Readiness Probes**). Новый Pod будет принимать трафик от **Service** только после успешного прохождения `readinessProbe`.
    *   Это гарантирует, что пользователи не будут перенаправлены на еще не готовые к работе экземпляры.

Пример процесса на практике

Представим Deployment с 4 репликами (replicas: 4) и настройками по умолчанию.

# Фрагмент манифеста Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-deployment
spec:
  replicas: 4
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1       # Можно создать на 1 Pod больше, чем 4
      maxUnavailable: 0 # Всегда должно быть доступно 4 Pod
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp-container
        image: myapp:v1.0 # Меняем на myapp:v1.1
        readinessProbe:
          httpGet:
            path: /health
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 5

Пошаговый сценарий обновления:

• Шаг 1: Применен новый образ. Создается новый ReplicaSet.
• Шаг 2: Создается 1 новый Pod (с myapp:v1.1), так как maxSurge: 1. Теперь всего 5 Pod (4 старых + 1 новый).
• Шаг 3: Новый Pod проходит readinessProbe. Service начинает отправлять ему часть трафика.
• Шаг 4: Удаляется 1 старый Pod (так как maxUnavailable: 0, сначала надо создать новый). Теперь 4 Pod (3 старых + 1 новый).
• Шаг 5-...: Цикл повторяется: создается новый Pod, после его готовности удаляется старый. Количество доступных Pod никогда не падает ниже 4.
• Финальное состояние: Имеется 4 новых Pod (управляемых новым ReplicaSet). Старый ReplicaSet масштабирован до 0, но НЕ удален (для возможности отката).

Важные технические аспекты и последствия

• История обновлений (Rollback History): Deployment по умолчанию хранит историю ReplicaSet (revisionHistoryLimit, обычно 10). Это позволяет мгновенно откатиться к предыдущей версии командой:

  kubectl rollout undo deployment/myapp-deployment
  

• Идемпотентность и консистентность: Весь процесс контролируется state-машиной в контроллере Deployment, что гарантирует согласованность состояния кластера даже при сбоях.

• Влияние на хранилище (Persistent Volumes): Если Pod используют PersistentVolumeClaims (PVC), их поведение зависит от политики восстановления (persistentVolumeReclaimPolicy) и режима доступа (accessModes). Обычно новый Pod, созданный в том же узле, может подключить тот же том, но это требует тщательного планирования для stateful-нагрузок.

• Сетевые политики и Service Mesh: В кластерах с сетевыми политиками (Calico, Cilium) или Service Mesh (Istio) обновление может вызвать временные перебои в сетевых правилах, пока sidecar-контейнеры или политики не будут применены к новым Pod.

• Мониторинг процесса: Процесс можно отслеживать командами:

  kubectl rollout status deployment/myapp-deployment
  kubectl get replicasets -l app=myapp  # Просмотр старых и новых ReplicaSet
  

Заключение

Обновление образа в Deployment — это не просто "перезапись контейнера", а оркестрируемый процесс замены состояния, обеспечивающий высокую доступность приложения. Он включает создание новых Pod, их валидацию через пробы, постепенное переключение трафика и сохранение возможности отката. Понимание механики maxSurge, maxUnavailable и критической роли Readiness Probes является фундаментальным для эффективного управления жизненным циклом приложений в Kubernetes. Для stateful-приложений или workloads с особыми требованиями к сессиям иногда применяются альтернативные стратегии (Recreate или Blue/Green развертывания через несколько Deployment).