Настройка 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 и полной совместимости.