Налаштування Kubernetes StatefulSets для stateful-застосунків

StatefulSet Kubernetes: що ламається без стійких ідентичностей

У stateless-світі под — витратний матеріал: упав, перестворився, нічого не втрачено. Зі stateful усе навпаки. Планувальник Kubernetes видає поду нове ім'я при кожному перестворенні, а том залишається прив'язаним до попереднього імені.

База даних піднімається з порожнім диском, кластер бадьоро звітує про готовність, і лише за логами застосунку видно, що даних немає.

Стійкі ідентичності подів — це не прикраса, а контракт. mysql-0, mysql-1, mysql-2 — фіксовані імена, за кожним закріплено свій PersistentVolumeClaim, і при перезапуску под повертається рівно до свого тому.

Без цієї прив'язки відмова диска або перестворення поду перетворюється на втрату даних при перезапуску: застосунок стартує, а історії транзакцій за ним немає.

Другий шар — порядок запуску реплік. Репліка з роллю первинної зобов'язана піднятися й віддати готовність раніше за інших, інакше вторинні йдуть у цикл перепідключень, а сервіс віддає помилки на весь період розкату.

Порядок запуску та зупинки реплік задається політикою керування, і це саме та ручка, якої немає у звичайного контролера розгортання.

Третій збій помітний найпізніше. Том живе в конкретній зоні доступності, прив'язка тому до вузла фіксує це на рівні сховища. Вузол падає — под перепланується в іншу зону, том туди не примонтується, под добами висить в очікуванні, а черговий розбирає це руками за ланцюжком подій. Розбираємо, як це закривається налаштуванням StatefulSet.

Що дає керована робота зі станом: вимірювані ефекти

Коректно описаний StatefulSet у Kubernetes повертає репліку, що впала, під тим самим іменем, з тим самим томом і тією самою роллю в кластері.

Проба готовності не пропускає трафік, поки застосунок не наздогнав журнал реплікації, тому відновлення відбувається без ручного втручання й укладається в десятки секунд замість годин розбору та переприв'язки диска.

Оновлення проходить по одному поду — від останнього індексу до нульового, з перевіркою готовності на кожному кроці.

Якщо нова версія не піднімається, викат зупиняється на конкретній репліці й не розносить весь кластер: частка успішних оновлень зростає саме завдяки тому, що збій локалізовано, а не розмазано по всіх екземплярах.

Окремий постійний том на репліку й заборона на одночасний запуск двох подів з одним іменем прибирають цілий клас відмов: втрату даних при перезапуску, гонку за одним каталогом, пошкоджений журнал після падіння вузла. Ці збої зазвичай спливають у найневдаліший момент — уночі або під час пікового навантаження.

Порядок запуску та зупинки задано декларативно, тому викат відтворюваний: однаковий результат на стенді й у продуктивному середовищі, відкат — повернення попереднього опису й повторний прохід у зворотному порядку. Тривалість простою на планових роботах узгоджується заздалегідь і не з'ясовується за фактом аварії.

У сумі це не «стало зручніше», а чотири перевірювані показники: час відновлення, частка вдалих оновлень, знятий клас відмов із втратою стану й передбачуваний викат.

Режими розгортання StatefulSet Kubernetes: таблиця порівняння

Вибір варіанта зводиться до трьох питань: де фізично лежать дані, хто відповідає за їхню узгодженість і що станеться з подом при переїзді на інший вузол.

StatefulSet дає стабільне мережеве ім'я, порядок запуску й окремий том на кожну репліку через volumeClaimTemplates, але природу носія він не визначає — її задають клас зберігання та режим доступу до тому.

Нижче — альтернативи, між якими реально обирають, коли застосунок тримає стан: черга, база, пошуковий індекс або сховище сесій.

Режим керування станом задається окремо від носія: podManagementPolicy визначає, чи піднімаються репліки по черзі або паралельно, updateStrategy — як проходить оновлення, а headless-сервіс дає передбачувані імена для зв'язку реплік між собою.

Ці параметри важливіші за вибір диска, коли застосунок сам уміє збирати кластер: йому потрібні стабільні адреси й гарантія, що наступна репліка стартує після готовності попередньої.

Обмеження варіанта майже завжди проявляється при відмові вузла: локальні томи потребують ручного або операторного перенесення, спільні — узгодженості на боці застосунку, зовнішня база — окремого контуру доступу.

Тому розбір починається не з вибору класу зберігання, а з того, як застосунок поводиться при втраті однієї репліки.

Порядок робіт: аудит, схема, міграція, перевірка, передача

Аудит кластера починається з інвентаризації: які застосунки справді зберігають стан, якому потрібна стабільна мережева адреса й порядок запуску, а яке переживе звичайний контролер без гарантій.

Далі фіксуємо профіль навантаження й вимоги до збереженості даних — від цього залежать клас зберігання, кількість реплік і схема розміщення за зонами.

1. Інвентаризація та аудит кластера. Збираємо перелік застосунків зі станом, поточні контролери, заявки на томи, доступні класи зберігання, квоти й розбивку за зонами доступності.
2. Схема розгортання. Описуємо цільовий StatefulSet: headless Service для передбачуваних DNS-імен, volumeClaimTemplates із потрібним класом зберігання, порядок запуску pod і правила розміщення за вузлами та зонами.
3. Перенесення даних і перший запуск. Перевіряємо ключову властивість: при перестворенні pod його том і мережеве ім'я зберігаються, застосунок піднімається на тих самих даних без ручних операцій.
4. Налаштування відмовостійкості. Перевірки готовності та живучості, бюджет переривань, ліміти ресурсів, оновлення по одному pod — щоб кворум не втрачався на середині викату.
5. Перевірка відмовостійкості. Планово гасимо вузли й зони, вибиваємо вузол із кворуму, замірюємо час переобрання лідера й відновлення з резервної копії.
6. Передача в експлуатацію. Віддаємо схему, регламенти штатних і аварійних операцій, алерти щодо стану томів і реплікації, межі масштабування.

Кожен етап закривається артефактом — таблицею інвентаризації, схемою, відпрацьованим сценарієм відкату, — тому наступний крок спирається на перевірене, а не на припущення.

Що замовник отримує на руки: схеми, маніфести, регламенти

Ми передаємо не «працюючий кластер», а комплект артефактів, за яким ваша команда сама змінює конфігурацію, розгортає середовище з нуля й піднімає дані після збою.

Усе лежить у репозиторії з історією змін: видно, хто і навіщо змінював параметр, а відкат до попередньої ревізії займає хвилини.

• Маніфести StatefulSet: headless-сервіс для стабільних мережевих імен, шаблони томів із заявками на диски, правила розміщення за вузлами, перевірки готовності та живучості, бюджет переривань, стратегія оновлення з можливістю поетапного викату й політика збереження даних при видаленні ресурсу.
• Шаблони середовищ із параметризацією: розробка, передпродакшн і продакшн збираються з одного набору описів, відмінності — лише у значеннях змінних, без копіювання конфігурацій вручну.
• Схеми взаємодії: як екземпляри знаходять одне одного за постійними іменами, як влаштована реплікація між ведучим і веденими вузлами, у якому порядку запускаються поди, де точки підключення застосунків.
• Політики доступу: ролі та службові облікові записи з мінімально достатніми правами, правила мережевої ізоляції, порядок зберігання й ротації секретів і сертифікатів.
• Регламент резервного копіювання: розклад знімків томів і узгоджених дампів, терміни зберігання, перевірка відновлення на окремому контурі та цільовий час підйому після аварії.
• Інструкції для команди: як розширити кластер, замінити вибулий екземпляр, оновити образ, відкотитися й що робити при втраті вузла — покрокові сценарії з очікуваним результатом на кожному кроці.
• Набір спостережуваності: панелі та оповіщення щодо відставання реплікації, вільного місця на томах, кількості готових екземплярів і тривалості запуску, щоб деградація була видна до відмови сервісу.

Кейс: переведення черг і сховищ на стійкі ідентичності

До: ідентичність губилася при кожному перезапуску

Черги й два сховища жили як звичайні розгортання: поди отримували випадкові імена, а томи підклеювалися за порядком запуску.

При витісненні на іншу ноду под не міг повернути свій том, а сусідній ставав на чужий — брокер RabbitMQ піднімався з розсинхронізованими чергами й дублями повідомлень.

Відновлення займало в середньому 40 хвилин і шість ручних операцій: зняти завислий том, дочекатися звільнення, підняти под у потрібному порядку, звірити дзеркала.

Повторювалося це двічі на місяць, а будь-яке обслуговування нод перетворювалося на нічну вахту чергового інженера.

Що змінили

Перевели черги й сховища на StatefulSet із headless-сервісом: под отримує передбачуване ім'я й DNS-запис, а том створюється з шаблону й залишається прив'язаним до своєї репліки.

Порядок запуску та зупинки став строгим — спочатку піднімається лідер, потім послідовники, і витіснення не починається, поки репліка не підтвердила готовність.

Додали бюджет переривань і перевірку готовності, яка дивиться на доступність сховища до запису, а не на живучість процесу.

Після: метрики

• Відновлення репліки — з 40 хвилин до 4, без ручних кроків.
• Відмови через втрачені томи — нуль за пів року спостереження.
• Обслуговування нод відбувається в робочий час: нічних викликів чергового немає.

Причина пішла, а не симптом: підміна ідентичності більше не відтворюється, тому відмови, що повторювалися щомісяця, не потребують швидкого лікування.

Що робити, якщо постійні томи вже розгорнуті вручну?

Переводити працюючу систему на StatefulSet можна без зупинки сервісу — за умови, що томи не перестворюються, а приймаються як є. У Kubernetes StatefulSet зіставляє том поду за іменем: ім'я шаблону плюс порядковий номер.

Якщо наявні PVC назвати за цим правилом і оголосити власником новий об'єкт, контролер підхопить уже наповнені дані, а не відправить заявку на створення чистого тому зі StorageClass.

Порядок робіт будуємо від консистентності даних, а не від маніфестів. Спочатку точка повернення — снапшот тому засобами сховища або повна копія, потім застосунок переводиться в режим без запису: гасимо приймання на рівні сервісу або переводимо вузол у читання.

Лише після цього знімаються старі поди, і StatefulSet піднімає под із тим самим заявленим томом — дані залишаються тими самими файлами на тому самому носії.

Для баз із реплікацією пряма заміна поду не годиться: вузол, який дивиться в наявний том, повинен залишитися учасником групи, а перемикання йде зміною ведучого.

Спочатку новий под на прийнятому томі наздоганяє журнал, потім йому передається роль ведучого, і лише потім гаситься старий — кластер увесь час відповідає на запити.

Страховка від необоротного результату — політика зберігання: автоматичний збір заявок вимикаємо, старі маніфести й резервний контур тримаємо до звірки контрольних сум.

Якщо розходження знайшлося, відкат — це повернення попереднього контролера й заявок старому власнику, а не відновлення з копії.

Технічні сумніви: відмовостійкість, міграції, відкати

Перед стартом робіт спливають ті самі сумніви: що буде з даними при відмові вузла, як переносити стан між кластерами, як відкотити реліз, який уже записав несумісний формат. Відповідаємо прямо — ці самі пункти стають критеріями приймання.

Як переносити стан в інший кластер?

Снапшот тому, відновлення в цільовому кластері, наздоганяння реплік, перемикання трафіку. У регламенті заздалегідь зафіксовано вікно запису й момент зупинки застосунку — розходження зводимо до хвилин, а не до «як вийде».

Реліз зламав стан — як відкочуємося?

Образи закріплені за дайджестом, тому повернення — це перемикання на попередній маніфест. Схему даних змінюємо зворотно сумісними кроками: спочатку додаємо поля, потім переводимо читання, і лише потім прибираємо старе — так відкат застосунку не тягне за собою відкат бази.

Резервні копії — за розкладом чи на вимогу?

Обидва режими. Розклад дає точку відновлення на кожну годину, а перед ризикованою зміною схеми копію знімаємо вручну. Копії лежать в окремому сховищі з політикою життєвого циклу, а саме відновлення ми перевіряємо на навчальному контурі — не в момент аварії.

Обговоримо задачу: зберемо схему й повернемося з оцінкою

Фінальний крок — узгодити склад робіт і порядок викату. Щоб оцінка була предметною, а не «на око», нам потрібен короткий ввід: перелік сервісів зі станом, вимоги до доступності та допустимої втрати даних, поточні маніфести й те, як зараз проходять оновлення. Цього достатньо, щоб побачити вузькі місця й запропонувати робочу схему.

Далі йдемо за зрозумілим маршрутом:

• розбираємо поточну конфігурацію: маніфести, розбивку за просторами імен, де лежать дані й як влаштовано резервне копіювання;
• фіксуємо вимоги: скільки реплік потрібно на відмову вузла, чи допустиме коротке переривання при оновленні, хто отримує доступ до томів;
• проєктуємо схему на об'єкті StatefulSet: стійкі імена, прив'язка томів, порядок запуску та зупинки реплік, правила оновлення;
• узгоджуємо склад робіт і межі відповідальності — що робимо ми, що залишається на вашому боці;
• перевіряємо план на тестовому контурі: оновлення, відмова вузла, відновлення з резервної копії;
• повертаємося з оцінкою та планом: етапи, порядок викату, точки відкату й вимоги до середовища.

Щоб обговорити задачу, достатньо описати сервіси та їхні вимоги до збереженості даних. Опишіть ситуацію — повернемося з оцінкою та планом робіт і запропонуємо найближчий крок.