Настройка Rolling Update деплоя для веб-приложения

При обновлении веб-приложения на продакшене пользователи часто теряют доступ или получают ошибки 503. Представьте: выкатили новую версию, а половина запросов упала с таймаутом — база не успела переключиться. Стандартный подход «остановить → заменить → запустить» не подходит для сервисов с требованиями SLA 99.9%. Мы настраиваем Rolling Update — стратегию, исключающую простой при минимальных затратах ресурсов. Наш опыт — 10+ лет в DevOps, внедрение rolling update для fintech и e-commerce с миллионной аудиторией.

Почему Rolling Update — лучший выбор для zero-downtime деплоя?

Rolling Update заменяет инстансы постепенно: сначала обновляется 1–2 пода, проверяется их здоровье, затем следующие. В отличие от Blue-Green, не требует двойных ресурсов, а в сравнении с Recreate — не останавливает все поды одновременно. Это даёт баланс между затратами и отказоустойчивостью. Rolling Update в 2 раза быстрее Blue-Green по времени развёртывания, а при правильной конфигурации downtime отсутствует полностью.

Rolling Update даёт наилучшее соотношение цены и надёжности для большинства продакшен-систем. Подтверждение — Rolling release в Wikipedia, где rolling update рекомендуется как default-стратегия.

Как настроить Rolling Update в Kubernetes?

# deployment.yaml apiVersion: apps/v1 kind: Deployment metadata: name: myapp spec: replicas: 6 strategy: type: RollingUpdate rollingUpdate: maxSurge: 2 maxUnavailable: 1 minReadySeconds: 30 selector: matchLabels: { app: myapp } template: metadata: labels: { app: myapp } spec: containers: - name: myapp image: registry.example.com/myapp:v1.1.0 readinessProbe: httpGet: path: /health/ready port: 8080 initialDelaySeconds: 10 periodSeconds: 5 failureThreshold: 3 livenessProbe: httpGet: path: /health/live port: 8080 initialDelaySeconds: 30 periodSeconds: 10 terminationGracePeriodSeconds: 60 

kubectl set image deployment/myapp myapp=registry.example.com/myapp:v1.2.0 kubectl rollout status deployment/myapp kubectl rollout history deployment/myapp kubectl rollout undo deployment/myapp kubectl rollout undo deployment/myapp --to-revision=3 

Что такое graceful shutdown и зачем он нужен?

Корректное завершение процессов — критично для zero-downtime. При получении SIGTERM приложение должно завершить активные запросы, закрыть соединения и освободить ресурсы. Если приложение не успевает завершиться за терминационный период, Kubernetes принудительно убивает его, что приводит к потере запросов.

// Node.js/Express — корректное завершение при SIGTERM process.on('SIGTERM', async () => { console.log('SIGTERM received, shutting down gracefully'); server.close(() => { console.log('HTTP server closed'); }); await new Promise(resolve => setTimeout(resolve, 30_000)); await db.destroy(); process.exit(0); }); 

Как проверить готовность приложения?

Readiness-проба должна проверять зависимые сервисы: БД, кеш, очередь. Пример на Laravel:

// Laravel — health check routes Route::get('/health/live', function () { return response()->json(['status' => 'ok']); }); Route::get('/health/ready', function () { try { DB::connection()->getPdo(); Cache::store()->get('health-check'); } catch (\Exception $e) { return response()->json(['status' => 'not ready', 'error' => $e->getMessage()], 503); } return response()->json(['status' => 'ready']); }); 

Как обеспечить совместимость базы данных при Rolling Update?

При сосуществовании двух версий схема БД должна быть совместима с обеими. Жёсткое правило — миграции запускаются до деплоя нового кода и только backward-compatible. Запрещено сразу переименовывать или удалять колонки, менять типы данных без промежуточных шагов.

Рекомендуется трёхэтапный деплой: сначала добавить новую колонку (nullable) или новую таблицу. Затем заполнить новые поля, переключить код на их использование. И только в третьей итерации удалить старые колонки или таблицы. Такой подход исключает ошибки совместимости при одновременной работе двух версий.

Типичные проблемы при настройке Rolling Update

Одна из частых ошибок — слишком маленький maxSurge или maxUnavailable, что затягивает деплой. Например, если maxSurge=1, а реплик 10, то обновление займёт 10 раундов. Правильно выбирать эти параметры исходя из общего числа реплик и допустимой скорости развёртывания. Другая проблема — некорректные readiness-пробы: они должны проверять реальную готовность приложения, а не просто возвращать 200. Если проба не включает проверку БД, новый под может начать принимать трафик до того, как база инициализирована, что приведёт к ошибкам 500. Также часто забывают настроить terminationGracePeriodSeconds: если приложение не успевает завершиться до принудительного SIGKILL, активные запросы теряются. Рекомендуется устанавливать значение не менее 30 секунд.

Что входит в настройку Rolling Update?

• Анализ текущей инфраструктуры и архитектуры приложения
• Конфигурация Kubernetes Deployment или Docker Swarm service
• Написание корректных readiness- и liveness-проб
• Доработка graceful shutdown (SIGTERM, завершение запросов)
• Разработка стратегии backward-compatible миграций
• Тестирование на staging-окружении с нагрузкой
• Документация настроек и регламентов
• Обучение команды работе с Rolling Update

Процесс работы

1. Аналитика: изучаем текущий стэк, инфраструктуру, процессы деплоя
2. Проектирование: выбираем параметры Rolling Update, health checks
3. Реализация: настраиваем оркестратор, пишем пробы, graceful shutdown
4. Тестирование: проверяем на staging с нагрузочным тестированием
5. Деплой: катим на production, мониторим первые 24 часа

Сроки реализации

Свяжитесь с нами для консультации — оценим ваш проект за 2 дня. Закажите настройку Rolling Update у профессионалов. Получите готовое решение с гарантией нулевого downtime и полной совместимости.