Налаштування Rolling Update деплою для веб-застосунку

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

Чому Rolling Update — найкращий вибір для zero-downtime деплою?

Rolling Update замінює інстанси поступово: спочатку оновлюється 1–2 pod, перевіряється їхнє здоров'я, потім наступні. На відміну від 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. Якщо проба не включає перевірку БД, новий pod може почати приймати трафік до того, як база ініціалізована, що призведе до помилок 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 та повної сумісності.