Kubernetes Rolling Update или Recreate: какую стратегию выбрать?

Описание: В прошлый раз отмена одного обновления исправила неудачную попытку обновления, и наш веб-сайт ни разу не перестал работать.
Но всегда ли скользящее обновление — правильный выбор? И сколько подов изменяется одновременно? Сегодня мы ответим на оба вопроса в режиме реального времени на нашем кластере. 🚢

В этом видео вы узнаете:
✅ Что такое стратегия обновления развертывания
✅ Как работает RollingUpdate: сначала запускается один новый под, затем отключается один старый
✅ Как работает Recreate: сначала останавливаются все старые поды, затем запускаются все новые
✅ Почему Recreate означает короткий простой и когда он все еще нужен
✅ Как увидеть свою стратегию с помощью kubectl describe deployment
✅ Что означают maxSurge и maxUnavailable, и как округляется 25% от 3 подов
✅ Как переключить развертывание на Recreate и наблюдать за ним в режиме реального времени
✅ Как выбрать между двумя вариантами

⏱️ Разделы
0:00 Ранее: два открытых вопроса
0:35 Два способа обновления: RollingUpdate и Recreate
1:33 Какую стратегию мы используем?

2:20 Максимальный пиковый спрос и максимальная недоступность
3:20 Воспроизвести в прямом эфире
4:37 Какой из них выбрать?

5:04 Краткий обзор и далее: Сервисы

🛠️ Что вам понадобится (все бесплатно)
Docker Desktop: https://www.docker.com/products/docke...
kind (Kubernetes в Docker): https://kind.sigs.k8s.io/docs/user/qu...
kubectl: https://kubernetes.io/docs/tasks/tools/
В 1-м эпизоде ​​пошагово строится кластер kind из 3 узлов («fleet»).

📚 Официальная документация
Стратегия обновления развертывания (RollingUpdate и Recreate): https://kubernetes.io/docs/concepts/w...
Max surge: https://kubernetes.io/docs/concepts/w...
Max unavailable: https://kubernetes.io/docs/concepts/w...
kubectl describe: https://kubernetes.io/docs/reference/...

💻 Команды из видео
1) Перед началом: развертывание "web" из эпизода 4
Перед началом видео мы перестраиваемся с того места, где закончился эпизод 4: nginx:1.27, затем 1.28, опечатка 1.299, отмена и файл, исправленный до версии 1.28:
apiVersion: apps/v1
kind: Deployment
metadata:
name: web
spec:
replicas: 3
selector:
matchLabels:
app: web
template:
metadata:
labels:
app: web
spec:
containers:

name: nginx
image: nginx:1.28

2) Какую стратегию мы используем?
kubectl describe deployment web
(Найдите эти две строки: "StrategyType: RollingUpdate" и "RollingUpdateStrategy: 25% max unavailable, 25% max surge". Мы их не писали: это значения по умолчанию.)

3) Переключитесь на Recreate: добавьте стратегию и обновите образ до nginx:1.29. Вот содержимое файла deployment.yaml:
apiVersion: apps/v1
kind: Deployment
metadata:
name: web
spec:
replicas: 3
strategy:
type: Recreate
selector:
matchLabels:
app: web
template:
metadata:
labels:
app: web
spec:
containers:
name: nginx
image: nginx:1.29

4) Примените изменения и наблюдайте за подами.
kubectl apply -f deployment.yaml
kubectl get pods --watch
(Все три старых пода одновременно завершают работу. Затем три новых пода показывают 0/1 ready: веб-сайт недоступен. Затем все три пода запускаются. Нажмите Ctrl+C, чтобы остановить наблюдение.)
kubectl describe deployment web
(StrategyType теперь Recreate. В событиях внизу: старый ReplicaSet уменьшился с 3 до 0, затем новый увеличился с 0) к 3.)

5) В качестве примера (не показано в видео): значения по умолчанию, которые мы никогда не записывали
стратегия:
тип: RollingUpdate
rollingUpdate:

maxSurge: 25%
maxUnavailable: 25%
При наличии 3 реплик maxSurge округляет до 1 дополнительного пода, а maxUnavailable — до 0 отсутствующих подов. Таким образом, запускается один новый под, и когда он готов, останавливается один старый под.
Пример из видео: maxUnavailable: 1 позволяет старому поду остановиться до того, как будет готов новый. Это быстрее, но на мгновение ваши пользователи будут обслуживаться только двумя подами.
Примечание: устанавливайте rollingUpdate только тогда, когда тип — RollingUpdate. При типе: Recreate, опустите rollingUpdate, иначе Kubernetes отклонит файл.

6) Выполните очистку после завершения (не показано в видео)
kubectl delete deployment web
kind delete cluster --name fleet

⏮️ Предыдущий эпизод: Откат Kubernetes: отмена неудачного обновления одной командой
⏭️ Следующий эпизод: Сервисы: стабильный адрес для ваших подов — после каждого обновления наши поды получают новые имена и новые IP-адреса. Как же пользователи находят приложение? Мы встречаем сервис ClusterIP и обращаемся к приложению по имени.

▶️ Это 5-й эпизод плейлиста «Kubernetes Explained with Ships»: эпизоды дополняют друг друга.

Что-то не было понятно, или у вас есть вопрос? Задайте его в комментариях — нет слишком простых вопросов. Если это помогло, поделитесь с другом, который изучает Kubernetes, и подпишитесь, чтобы не пропустить следующий эпизод.

Демонстрация записана на Kubernetes v1.37.0 с kind v0.33.0.

#Kubernetes #DevOps ...