Сообщить об ошибкеКороткий ответ
При blue-green деплое одновременно существуют два идентичных по инфраструктуре окружения — текущее (например, «blue», принимает весь трафик) и новое (например, «green», с новой версией); после проверки «green» весь трафик переключается на него одномоментно через балансировщик или DNS, а «blue» остаётся как запасной вариант для быстрого отката.
Как это работает подробнее
новая версия разворачивается полностью в отдельном наборе серверов/подов, не принимая боевой трафик, пока идёт проверка (smoke-тесты, health checks). Переключение происходит изменением конфигурации роутинга (например, у Service/Ingress в Kubernetes или записи в балансировщике) — это быстрая операция по сравнению с постепенным rolling update.
Пример кода
example.yaml
# Service выбирает активное окружение через селектор label "slot"
apiVersion: v1
kind: Service
metadata:
name: myapp
spec:
selector:
app: myapp
slot: blue # переключение на green = смена этого значения на "green"Что использовать на практике
- На практике. blue-green требует вдвое больше ресурсов на время деплоя (оба окружения работают одновременно), зато даёт мгновенный откат — достаточно переключить трафик обратно на «blue». Нужно заранее продумать работу с базой данных и состоянием, чтобы оба окружения могли корректно работать с одними и теми же данными в переходный период.
- Пример. Ожидаемое поведение: после изменения `slot: blue` на `slot: green` и применения манифеста весь новый трафик через Service мгновенно направляется на поды окружения green, без постепенного перехода.
Подводные камни
- Частые ошибки. считают «blue» и «green» фиксированными названиями конкретных серверов, хотя это просто обозначение двух ролей, которые чередуются при каждом релизе; забывают, что после переключения трафика старое окружение нужно либо оставить ненадолго для отката, либо аккуратно вывести из эксплуатации, а не удалять сразу.