Rolling Update: що ламається під час викочування нової версії
Найчастіша поломка під час викочування нової версії — заміна всіх екземплярів сервісу однією хвилею.
Поки старі процеси гасяться, а нові піднімаються, частина запитів іде в нікуди: з’єднання обриваються на середині транзакції, перевірки готовності не встигають прогрітися, і частка відповідей із помилкою стрибає саме в активних користувачів — тих, хто прямо зараз платить або оформлює замовлення. Недоступність сервісу триває хвилини, але в пікові години це найдорожча хвилина доби.
Друга, неприємніша проблема — гонка версій схеми даних. Якщо міграція бази проходить до викочування коду, старі екземпляри ще живі й не знають про нове поле або перейменовану колонку; якщо після — новий код уже читає те, чого немає.
Невдалий реліз у цей момент перестає бути однією подією: помилки приходять із двох версій одразу, і з журналів не видно, хто саме винен.
Ручний відкат версії під навантаженням погіршує все. Інженер піднімає попередній образ, але схема даних уже поїхала вперед, і старий код на неї не стає: відновлення розтягується з хвилин на години, а трафік весь цей час іде на деградуючий контур.
Розбираємо, як це закривається: хвилі по одній репліці з прогрівом і утриманням з’єднань, оборотні міграції в два сумісні покоління схеми й автоматичний відкат за метриками замість ручного втручання.
Ефект керованого викочування: що змінюється в цифрах
Вимірювані результати з’являються там, де викочування описано формальними параметрами: скільки екземплярів піднімається паралельно, які перевірки готовності проходить новий екземпляр і за якою умовою старий виводиться з балансування.
В оркестраторі на кшталт Kubernetes це задається декларативно, тому стан до й після впровадження порівнюється за одними й тими самими метриками, а не за відчуттями чергової зміни.
Чек-лист того, що перевіряємо і що фіксуємо у звіті:
- Вікно недоступності. До — від кількох хвилин до півгодини на реліз, частина трафіку отримує помилки. Після — нуль: новий екземпляр приймає трафік лише після успішної перевірки готовності, старий знімається з балансування останнім.
- Скорочення вікна релізу. Заміна йде порціями, тому викочування перестає бути зупинкою робіт: збірка й перевірки йдуть паралельно заміні екземплярів.
- Частка невдалих релізів. Раніше — за фактом падіння проду, тепер — за кількістю екземплярів, що не пройшли перевірку готовності. Такі релізи зупиняються автоматично, не доходячи до всієї групи.
- Відкат за один крок. Повернення до робочої версії — перемикання на попередній набір екземплярів, а не повторна збірка й ручний розбір. Час повернення вимірюється десятками секунд.
- Усунений клас відмов. Коректне завершення процесів із паузою більшою за найдовший запит прибирає обриви довгих з’єднань і сплески помилок шлюзу на старті.
- Навантаження на чергового. Ручні дії під час викочування зводяться до запуску й спостереження: прогрес, частка замінених екземплярів і причина зупинки видно в одному місці.
Усі шість пунктів вимірюються до й після на однаковому профілі навантаження — інакше порівняння нічого не доводить. Опишіть вашу задачу: повернемося з оцінкою, планом заміру й конфігурацією під ваш контур.
Порівняння підходів: Rolling Update та альтернативи
Стратегії викочування різняться тим, скільки версій одночасно обслуговують трафік і наскільки швидким виходить повернення назад.
Нижче — чотири робочі варіанти та їхні чесні обмеження: вони визначають, чи потрібен резерв потужності під другий контур, чи готові зовнішні споживачі до двох адрес сервісу і чи вміє команда гасити несумісні зміни схеми даних.
| Підхід | Коли підходить | Обмеження |
|---|---|---|
| Повний перезапуск | Внутрішні сервіси, нічне вікно обслуговування, короткий простій допустимий | Простій на час старту всіх реплік; відкат — повторний запуск минулого образу; перемикання без плавності |
| Rolling Update | Довгоживучі сервіси без стану на вузлі, кілька реплік за балансувальником, викочування без простою | Дві версії працюють одночасно: ламається на несумісних змінах API і схеми; відкат — зворотний прохід по репліках; за заборони недоступних реплік потрібен запас потужності |
| Канареечне викочування | Потрібно перевірити версію на 1–5% трафіку, є метрики й маршрутизація за вагами | Потребує керованого балансувальника й спостережуваності; викочування розтягнуте в часі; дві версії сусідять довше |
| Синьо-зелене викочування | Критичний сервіс, потрібен відкат перемиканням трафіку за секунди | Подвійна витрата ресурсів на час викочування; потрібен прогрів нового контуру; складніше зі станом, чергами й міграціями |
Як вибрати під свій контур
Якщо зовнішні споживачі не готові до двох адрес сервісу й немає метрик у розрізі версій, вибір звужується до повного перезапуску або Rolling Update.
Порядок робіт тут завжди один: спочатку спостережуваність і зворотна сумісність схеми, потім стратегія — інакше відкат перетворюється на вгадування.
Як ми впроваджуємо стратегію: етапи інженерних робіт
Порядок робіт однаковий і для одного сервісу, і для платформи з десятками компонентів — відрізняється лише обсяг. Мета одна: оновлення не повинно бути помітним ні користувачеві, ні черговій зміні. Ідемо від аудиту інфраструктури до передачі в експлуатацію.
Етапи впровадження
- Аудит інфраструктури. Рахуємо репліки та їхній розкид по вузлах, перевіряємо проби готовності й живучості, політику переривань і те, як балансувальник виводить вузол із ротації.
- Схема викочування. Визначаємо, скільки нових реплік піднімається одночасно і яка просадка доступності допустима (maxSurge і maxUnavailable), як чергуються версії в сервісі.
- Налаштування параметрів. Правимо проби, час очікування зупинки, обробник preStop і повтори запитів у клієнтів — інакше зупинена репліка рве з’єднання прямо під час викочування.
- Перевірка на навантаженні. На стенді з профілем бойового трафіку ганяємо викочування й відкат: частка помилок, час відповіді на рідкісних повільних запитах, скільки займає повернення до минулої версії.
- Документування. Регламент викочування й відкату, критерії зупинки при зростанні помилок, що дивитися в першу чергу.
- Передача в експлуатацію. Віддаємо черговій зміні метрики й алерти на застрягле викочування, проговорюємо порядок дій і межу, за якою кличуть нас.
Критерій приймання — викочування під робочим навантаженням без зростання помилок; якщо умову не виконано, повертаємося до параметрів і повторюємо перевірку.
Конфігурації, схеми й регламенти релізу
Комплект артефактів після впровадження стратегії Rolling Update збираємо так, щоб наступний реліз ваша команда випустила без нас. Усе версіонується поряд із кодом: конфігурації, схеми, регламенти й політики доступу — з історією правок і зрозумілою точкою входу.
- Конфігурація оточень — маніфести поступового викочування: частка трафіку на нову версію, скільки екземплярів оновлюється разом, пауза між кроками, пороги готовності. Параметри розведені за середовищами розробки, передпродуктивним і продуктивним — стенд не повторює продуктив наосліп.
- Схема викочування — порядок кроків від збірки артефакту до повного переведення трафіку, точки зупинки автоматики й те, що бачить користувач у момент переходу.
- Регламент релізу — хто ініціює випуск, хто підтверджує, які перевірки обов’язкові до старту, за яким сигналом оголошується відкат.
- Порядок повернення — повернення на попередню версію однією дією, термін життя минулих артефактів у реєстрі й перевірка, що відкат працює не лише в день релізу.
- Політики доступу — ролі в кластері й реєстрі: хто змінює конфігурацію продуктивного середовища, хто читає логи, хто підтверджує випуск; люди й сервісні облікові записи розведені.
- Документація й спостережуваність — опис оточень, змінних і секретів, схема мережі, інструкції з типових операцій, панелі моніторингу й оповіщення за часткою помилок і кількістю доступних екземплярів.
Кожен пункт передаємо з коротким розбором: що налаштовано, чому вибрано саме такий поріг і як діяти, якщо поведінка системи відхилилася від очікуваної.
Кейс: як викочування версії перестало валити сервіс
Сервіс із добовим піком навантаження: онлайн-замовлення, десятки тисяч запитів за хвилину, вікно низького трафіку — лише вночі.
Випуск версії йшов через зупинку групи серверів: 4–6 хвилин недоступності на кожному релізі, а приблизно кожен сьомий реліз відкочували вручну і майже завжди вночі.
Схему випуску перебудували на rolling update у Kubernetes: інстанси замінюються партіями, maxSurge і maxUnavailable задають, скільки нових піднімати одночасно і скільки старих допустимо зняти.
Readiness-проба не пропускає трафік у інстанс, що прогрівається, preStop-hook із затримкою дає активним з’єднанням закритися — на зміні версії не губиться жоден запит.
| Метрика | До | Після |
|---|---|---|
| Час недоступності під час випуску | 4–6 хвилин | немає — трафік іде на живі інстанси |
| Частка невдалих релізів | близько 14% | 2% |
| Повернення до робочої версії | 25–40 хвилин вручну | одна команда, менше хвилини |
| Вікно випуску | лише вночі | будь-який момент, включно з піком |
Контроль залишився в чергового інженера, але рішення ухвалює автоматика: при зростанні частки помилок викочування зупиняється сама й повертає попередній набір образів, не чекаючи деградації сервісу. Бюджет помилок на реліз заданий заздалегідь — вичерпали, викочування заблоковано до розбору причин.
У результаті випуск перестав бути подією з чергуванням по ночах: версії виходять у робочий час, відкат займає менше хвилини, а частка невдалих релізів упала в сім разів на тому самому обсязі трафіку.
Що робити, якщо сервіс уже працює в кластері?
Робочий кластер не можна просто «переключити» на поетапну заміну: старий і новий екземпляри якийсь час обслуговують трафік одночасно. Тому першим ділом перевіряємо, чи переживе сервіс паралельну роботу двох версій — за кодом, за даними й за фоновими задачами. Без цієї перевірки перехід без зупинки перетворюється на лотерею.
Сумісність зі схемою даних — головний обмежувач. Зміни розбиваємо на хвилі: спочатку додаємо поля й індекси, зрозумілі старій версії, потім випускаємо код, який читає обидва формати, і лише наступною хвилею прибираємо старе.
Руйнівні операції — перейменування, звуження типу, видалення колонки — з випуском коду в один крок не поєднуються ніколи.
Окремо перевіряємо все, що погано ділиться на частини: планувальники, кеші з власним станом, тривалі з’єднання. Фонова задача, розмножена на кілька екземплярів, дає подвійний прогін, тому на час випуску її залишають в одній активній копії.
Перевірка готовності має відображати реальну готовність, інакше трафік прийде на екземпляр, який ще не підняв з’єднання.
Порядок переходу — від простого до пов’язаного. Спочатку шари без власного стану: обробники запитів і прикладний API. Потім споживачі черг і робочі процеси. Останніми — компоненти з даними: бази, кеші, брокери, які оновлюються поштучно з перевіркою на кожному кроці.
Ризики переходу зводяться до вікна змішаних версій і відсутності шляху назад. Відкат плануємо заздалегідь: поки нова версія не підтверджена, стара залишається працездатною й сумісною з новими даними.
Частку трафіку на нову версію обмежуємо й розтягуємо заміну в часі, щоб помилки проявлялися на малій частині кластера, а не на всьому навантаженні.
Технічні сумніви й обмеження підходу
Rolling Update вирівнює версію коду, але не стан: поки новий под піднімається, старий приймає трафік, і з’єднання, що живе довше витіснення пода, обривається на боці користувача.
Лікується це не самою стратегією, а зв’язкою — preStop-хук, затримка виведення з балансувальника, коректне завершення за сигналом. Без них плавність видно лише на графіку деплою.
Схема даних обмежує сильніше. Дві версії коду працюють одночасно, тому і стара, і нова мають переживати будь-яку версію схеми: поля додаються як необов’язкові, запис іде в обидва формати, видалення — лише після виведення попереднього релізу.
Відкат ламається рівно в той момент, коли міграція прибрала колонку: повернути її без втрати даних уже не можна.
Інфраструктура задає верхню межу. Підйом нового пода потребує запасу за процесором і пам’яттю, інакше планувальник тримає його в очікуванні й оновлення зависає на середині.
Квоти оточення, дискові томи, кількість адрес у балансуванні — це межа, за якою підхід не застосовується без зміни схеми розгортання.
Чи потрапить користувач на стару версію під час оновлення?
Так, і це нормально, якщо версії сумісні за контрактом інтерфейсів і схемою даних. Задача не в тому, щоб виключити одночасну роботу, а в тому, щоб зробити її безпечною: версіонування інтерфейсів, зворотна сумісність відповідей, відсутність спільного змінюваного стану в пам’яті.
У Kubernetes це доповнюється пробою готовності, щоб трафік ішов лише в под, реально здатний відповідати.
Як відкочуватися, якщо міграцію вже виконано?
Безпечне повернення можливе лише до необоротних змін. Тому міграції ділять на етапи: розширення схеми, перенесення даних, перемикання коду, видалення старого — на кожному кроці застосунок залишається працездатним на попередній версії.
Якщо видалення вже пройшло, відкат означає відновлення з резервної копії з втратою змін за цей проміжок.
Обговоримо задачу й повернемося з планом викочування
Щоб оцінка викочування була предметною, а не «плюс-мінус тиждень», інженерам потрібен доступ до реальної картини оточення: маніфестам робочого навантаження, налаштуванням проб, параметрам оновлення й схемі міграцій.
Чим менше припущень на вході, тим точніший план робіт і тим менше сюрпризів у самому вікні викочування.
Що корисно надіслати до обговорення:
- поточні маніфести робочого навантаження й параметри сервісу, через який іде зовнішній трафік;
- налаштування проб: що вважається живим процесом, що — готовим приймати запити, які таймаути й затримки старту;
- параметри rolling-оновлення: скільки екземплярів можна підняти понад норму, скільки вивести з ладу, скільки чекати готовності;
- як зберігаються образи — чи є незмінні теги, хто і на якому кроці позначає збірку;
- схема міграцій бази й вимога сумісності версій уперед і назад;
- куди дивитися при деградації: метрики, логи, алерти, хто отримує повідомлення;
- обмеження щодо вікна викочування — робочі години, періоди заморозки, необхідність погодження;
- хто володіє рішенням про відкат і за яким сигналом він запускається.
У відповідь повернемося з планом: розбивка викочування за хвилями й частками трафіку, набір параметрів конфігурації під ваш профіль навантаження, готові маніфести й правила ревізій, критерії стоп-сигналу з процедурою повернення на попередню версію та чек-лист для чергового.
Опишіть задачу й поточне оточення — повернемося з оцінкою та планом робіт.
