Что произойдет, если мы развернём приложение с помощью деплоя и затем изменим версию приложения в репликасете?

После изменения версии приложения в Deployment ресурс ReplicaSet, связанный с этим Deployment, обновится. Deployment создаст новый ReplicaSet с новой версией образа контейнера. Старый ReplicaSet постепенно масштабируется вниз, а новый ReplicaSet масштабируется вверх. Этот процесс называется rolling update (скользящее обновление) и выполняется автоматически по умолчанию.

Конкретные шаги:

1. Пользователь или CI/CD система обновляет Deployment.
2. Deployment создает новый ReplicaSet с spec, содержащим новую версию образа.
3. Новый ReplicaSet начинает создавать поды с новой версией.
4. Как только часть новых подов перейдет в состояние Ready, Deployment начинает масштабировать вниз старый ReplicaSet, удаляя поды со старой версией.
5. Процесс продолжается до тех пор, пока все поды не будут под управлением нового ReplicaSet с новой версией.
6. Старый ReplicaSet остается, но с желаемым числом реплик равным 0.

Это обеспечивает нулевое время простоя при обновлении приложения (при условии достаточных ресурсов и корректной готовности подов) и позволяет легко откатиться на предыдущую версию просто путем обновления Deployment обратно.

Пример обновления Deployment YAML:

# Обновленный Deployment YAML
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 25% # Максимальное количество подов, которое может быть создано сверх желаемого количества
      maxUnavailable: 25% # Максимальное количество подов, которое может быть недоступно во время обновления
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app-container
        image: my-registry/my-app:v1.1.0 # Изменена версия образа
        ports:
        - containerPort: 80

Прямое изменение ReplicaSet вручную крайне не рекомендуется и может привести к непредсказуемому поведению, так как Deployment будет пытаться привести состояние ReplicaSet в соответствие со своим желаемым состоянием, перезаписывая ваши изменения. Все управляемые изменения приложения должны осуществляться через ресурс Deployment.