Налаштування 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 та повної сумісності.