Short answer: Проби готовності та живучості визначають, коли pod може приймати трафік і коли його треба перезапустити, і це найпростіший та найефективніший інструмент, щоб утримати vibecoded‑застосунок живим під реальним навантаженням. Liveness‑проба має відповідати лише на запитання «Чи достатньо здоровий процес, щоб продовжувати роботу?», тоді як readiness‑проба — «Чи може цей інстанс обслуговувати запити прямо зараз?». Більшість збоїв під час грубих розгортань виникають через плутанину між ними або через проби, що надто повільні, надто суворі чи перевіряють не те. Використовуйте startupProbe для повільного старту, на SIGTERM миттєво перемикайте readiness у false для коректного завершення та тримайте хендлери проб швидкими й ізольованими. Продакшен‑готові застосунки постачаються з пробами, що відображають реальну здатність обслуговувати трафік без флапінгу.

Key takeaways

  • Readiness і liveness мають різні цілі: readiness керує допуском трафіку; liveness ініціює перезапуски.
  • Liveness має бути мінімальною та внутрішньопроцесною; readiness може перевіряти критичні залежності, але мусить бути швидкою.
  • Використовуйте startupProbe, щоб убезпечити повільну ініціалізацію та міграції від передчасних перезапусків.
  • На SIGTERM перемикайте readiness у false, дренуйте, потім завершіть роботу в межах terminationGracePeriodSeconds для коректного завершення.
  • Пороги, таймаути та інтервали проб повинні відповідати вашому бюджетові затримок, аби запобігти флапінгу та каскадним відмовам.

What are readiness and liveness probes, and why do they matter?

Readiness і liveness — це перевірки здоров’я Kubernetes, що керують маршрутизацією трафіку та перезапусками на рівні pod. Readiness визначає, чи додавати pod до кінцевих точок сервісу, тоді як liveness вирішує, чи має kubelet перезапустити контейнер.

Використовуйте liveness, щоб виявляти застряглі процеси, які не здатні відновитися й потребують перезапуску. Використовуйте readiness, щоб сигналізувати про тимчасову недоступність — прогрів кешів, бекпрешер або контрольоване завершення. Продакшен‑розгортання, автоскейлінг та реагування на інциденти покладаються на ці сигнали, аби не надсилати користувачів на зламані pod’и.

How do readiness and liveness probes work in Kubernetes?

Проби в Kubernetes виконуються за розкладом і перевіряють HTTP‑ендпоінт, TCP‑сокет або команду в контейнері. Пороги успіху й невдачі визначають, коли kubelet перемикає стан готовності pod або ініціює перезапуск.

  • Liveness: коли послідовно фейлиться до налаштованого порогу, kubelet перезапускає контейнер.
  • Readiness: коли фейлиться, pod вилучається з ендпоінтів сервісу, доки проба знову не пройде.
  • Startup: під час старту працює лише startupProbe; коли вона проходить, запускаються liveness і readiness. Це запобігає перезапускам під час повільної ініціалізації.

Таймінги проб керуються параметрами periodSeconds (період), timeoutSeconds (таймаут очікування) та failureThreshold/successThreshold (стабільність). Ці налаштування мають відповідати профілю затримок вашого застосунку.

What should a production liveness probe actually check?

Продакшен‑liveness повинна перевіряти лише здатність контейнера робити поступ уперед. Тримайте її мінімальною та внутрішньою, щоб тимчасові зовнішні збої не спричиняли зайвих перезапусків.

  • Переконайтеся, що цикл подій чи пул потоків реагує, обслуговуючи крихітний внутрішньопроцесний хендлер.
  • Гарантуйте відсутність дедлоків або OOM‑станів, що заважають виконанню базового хендлера.
  • Не викликайте БД, черги чи зовнішні API в liveness; зовнішні збої не повинні змушувати контейнер перезапускатися.
  • Відповідайте швидко простим 200 OK; оминайте важкі за логуванням або виділенням пам’яті кодові шляхи.

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

What should a production readiness probe verify?

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

  • Підтвердіть, що HTTP‑сервер приймає з’єднання та виконує тривіальний хендлер.
  • За потреби перевірте, що пул підключень до БД має принаймні одне здорове з’єднання або може відкрити його в межах жорсткого бюджету. Використовуйте легкий ping‑запит, а не важку транзакцію. Див. поради з безпечного дизайну пулів у Postgres connection pooling for MVPs.
  • Якщо для обробки запитів потрібен певний кеш, переконайтеся, що клієнт кешу підключений; не виконуйте flush чи rebuild у пробі.
  • Якщо критично необхідний брокер повідомлень чи стрім для прийому записів, перевірте, що клієнт може публікувати в health‑топік або підключений, але уникайте постійних побічних ефектів.
  • Експонуйте бекпрешер: коли черги перевищують безпечну глибину або вузол вичерпав файлові дескриптори, повертайте not ready, щоб скидати навантаження.

Readiness має відображати здатність обслуговувати в межах вашого SLO. Якщо застосунок не вкладається в бюджет затримок для стандартного запиту через втрату залежностей або ресурсний тиск, він має фейлити readiness і припинити прийом трафіку до відновлення.

How to design probe endpoints that do not lie

Health‑ендпоінти мають бути чіткими, швидкими та стабільними під стресом. Один /healthz, що завжди повертає 200, гірший за відсутність перевірок, бо неправильно маршрутизує трафік у моменти відмов.

  • Експонуйте окремі хендлери: для liveness (суто внутрішньопроцесний) та для readiness (внутрішній + критичні залежності).
  • Повертавайте 200 для здорового стану, 503 — коли не готовий, і 500 — лише для справжніх відмов живучості. Використовуйте явні статус‑коди, а не кодуйте стани в JSON.
  • Тримайте тіла відповідей мінімальними й необов’язковими; пробі не потрібні багатослівні пейлоади. Детальну діагностику віддавайте в логи та метрики.
  • Встановіть суворі пер‑хендлерні таймаути коротші за таймаут проби, щоб уникнути head‑of‑line блокування в сервері.
  • Не вимагайте автентифікації; запустіть хендлери на внутрішньому порту або шляху з мережевими політиками.

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

When should you use startupProbe?

Використовуйте startupProbe, щоб екранувати повільну чи варіативну ініціалізацію від перезапусків liveness. Startup‑проби запускаються до readiness і liveness та мають перевіряти завершення кроків завантаження, які не можна поєднувати з трафіком.

  • Довге завантаження модулів, прогрів JIT або кроки рантайм‑компіляції.
  • Міграції даних або перевірки схем, що мають завершитися до старту обслуговування.
  • Великі попередні завантаження кешу, необхідні, щоб інстанс відповідав у межах SLO.

Під час startupProbe liveness вимкнено. Оберіть консервативні таймаути й періоди, щоб уникнути фальшивих перезапусків, а далі перейдіть до звичних readiness/liveness, коли сервіс готовий.

How do probes coordinate graceful shutdown?

Коректне завершення потребує перемкнути readiness у false на SIGTERM, злити (дренувати) поточну роботу та вийти в межах terminationGracePeriodSeconds. Так балансувальник перестає надсилати нові запити, поки pod завершує наявні.

  1. На SIGTERM або preStop негайно встановіть readiness у false і відповідайте на readiness 503.
  2. Припиніть приймати нові з’єднання та зупиніть вибірку нових задач із фонових воркерів.
  3. Завершіть поточні HTTP‑запити та задачі в межах grace‑періоду; скасуйте або збережіть прогрес довгих задач.
  4. Акуратно закрийте мережеві з’єднання та завершіть процес до завершення terminationGracePeriodSeconds.

Коректне завершення критичне для розгортань без даунтайму та безпечного дренування вузлів. Liveness має лишатися зеленою під час drain, інакше kubelet може вбити контейнер раніше, ніж той завершить роботу.

What thresholds and timings should you configure?

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

  • Період: виберіть частоту, що виявляє збої в межах вашого бюджетy помилок без зайвого навантаження — зазвичай кілька секунд для readiness і трохи довше для liveness.
  • Таймаут: зробіть коротшим за типовий таймаут запиту й узгодженим із роботою хендлера (сотні мілісекунд — кілька секунд для більшості веб‑додатків).
  • Поріг відмов: дозвольте невеликий джиттер для readiness (кілька поспіль фейлів) і менший для liveness, адже це простий внутрішній хендлер.
  • Поріг успіху: для readiness вимагайте більше одного успіху, щоб повернутися в ротацію, якщо система схильна до флапінгу; для liveness зазвичай достатньо одного.
  • Старт: дайте startupProbe щедре вікно, якщо холодні старти чи прогрів кешів варіативні, далі переходьте до звичайних проб.

Думайте в термінах користувацького досвіду: час виявлення readiness, довший за вікно перемикання трафіку чи розгортання, може надсилати користувачів на зламані pod’и. Узгодьте інтервали проб зі стратегіями деплойментів і інтервалами HPA.

Which dependencies belong in readiness, and which do not?

Не кожна залежність має бути в readiness. Readiness повинна охоплювати лише критичні залежності для трафіку, що маршрутується на pod.

  • Включайте: HTTP‑сервер, основну БД у шляхах запитів, обов’язковий кеш, що фронтить запити, або брокер, потрібний для синхронного прийому записів.
  • Виключайте: необов’язкові аналітичні сінки, асинхронні email‑черги або batch‑джерела; деградуйте функціонал граційно.
  • Страхуйте: якщо БД іноді повільна, перевірка readiness має використовувати легкий ping із жорстким таймаутом, а не повноцінний запит.

Якщо ви покладаєтесь на реляційну БД, перевіряйте стан пулу з’єднань, а не відкривайте нове підключення кожною пробою. Необмежені спроби підключення з проб можуть вичерпати пул. Для тюнінгу пулів і безпечних таймаутів див. наш гайд Postgres connection pooling.

How should probes behave under backpressure?

За тривалого навантаження здорова система може потребувати скидати трафік. Readiness — важіль для зниження прийому на pod при збереженні liveness.

  • Експонуйте глибину внутрішніх черг і насичення CPU в readiness‑хендлері й позначайте not ready при перевищенні порогів.
  • Лімітуйте частоту обчислень readiness, щоб уникнути тремтіння; перемикайте стан лише за сталого перевищення порогів.
  • Координуйтеся з автоскейлерами (CPU чи кастомні метрики), щоби pod’и поверталися в ротацію зі спадом тиску.

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

Common anti‑patterns that break rollouts

Переважна більшість інцидентів, пов’язаних із health‑чеками, походить із кількох передбачуваних помилок. Уникайте цих антипатернів, переводячи vibecoded‑застосунок у продакшен.

  • Liveness виконує запит до БД або викликає сторонній API. Зовнішні збої спричиняють перезапуски контейнерів і ускладнюють відновлення.
  • Readiness виконує важку роботу — перебудову кешів чи міграції. Проби стають генератором навантаження, що топить pod.
  • Єдиний /healthz із складною логікою. Один прапорець приховує семантичні відмінності та заохочує недоречні перевірки.
  • Таймаути проб перевищують серверні. Проба блокує пул потоків довше за користувацькі запити, спричиняючи head‑of‑line блокування.
  • Без startupProbe на повільних стартах. Pod перезапускається по колу, не встигши ініціалізуватися.
  • Без скидання readiness на SIGTERM. Pod отримує трафік під час завершення, що веде до зайвих 5xx у розгортаннях.
  • Хендлери здоров’я логують WARN/ERROR на кожен хіт. Проби заливають логи та маскують сигнали.

Зробіть проби нудними. Нудні health‑чеки — надійні та дешеві.

How do you implement probes in common stacks?

Імплементація проста, якщо розвести обов’язки та тримати хендлери крихітними. Патерни однакові в різних мовах і фреймворках.

  • HTTP‑сервери: підніміть два маршрути, напр., /live для liveness і /ready для readiness, кожен зі строгими таймаутами від сервера або middleware.
  • Фонові воркери: експонуйте окремий порт або HTTP‑ендпоінт із воркера, або використовуйте exec‑проби, щоб перевірити здатність прийняти й обробити no‑op завдання.
  • Сигнали процесу: зареєструйте обробник SIGTERM, що перемикає readiness і закриває лісенери; багато фреймворків мають хуки коректного завершення — зв’яжіть їх із прапорцем readiness.
  • Перевірки БД: пінгуйте пул або виконуйте легке читання з коротким таймаутом; ніколи не створюйте нові підключення на кожну пробу.
  • Перевірки кеша/брокера: впевніться, що клієнти у стані connected; уникайте publish/subscribe, якщо це не окремий health‑канал без побічних ефектів.

Обирайте HTTP‑проби, де можливо; їх легше таймити й інструментувати, ніж exec‑проби, і вони напряму відображають здоров’я сервісу.

How do you test probes before production?

Тестуйте health‑чеки в умовах, які вони мають контролювати: повільні старти, відмови залежностей, поетапні оновлення та ресурсний тиск. Тести, що лише перевіряють 200 у деві, не про те.

  • Індукуйте повільний старт, затримуючи доступність залежностей; перевірте, що startupProbe утримує перезапуски до завершення ініціалізації.
  • Вбийте БД або інжектуйте DNS‑збої; перевірте, що readiness швидко переходить у 503, тоді як liveness лишається 200.
  • Надішліть SIGTERM під час навантажувального тесту; переконайтеся, що readiness падає одразу, трафік у польоті завершується й немає спайку 5xx.
  • Симулюйте наростання черг; перевірте, що readiness фейлиться під бекпрешером і відновлюється без флапінгу зі спадом навантаження.

У тестах використовуйте реалістичні обсяги даних і патерни запитів. Якщо потрібні репрезентативні несекретні дані, див. наші поради з test data management for MVPs.

How do probes interact with rollouts and traffic shifting?

Проби — шар безпеки для розгортань без даунтайму, канарок і blue‑green стратегій. Якщо проби відображають реальну здатність обслуговувати трафік, платформа природно обминає нездорові pod’и під час розгортання.

  • Нові pod’и: startupProbe запобігає передчасним перезапускам; readiness гарантує отримання трафіку лише після прогріву.
  • Pod’и, що завершуються: падіння readiness і коректне дренування запобігають спайкам 5xx і частковим записам.
  • Канарка: readiness тримає канарку поза ротацією у разі регресії, мінімізуючи blast radius.

Поєднуйте проби з поетапним перемиканням трафіку та версійною конфігурацією. Якщо сам застосунок експонує точне здоров’я, платформа може ухвалювати безпечні рішення без крихких скриптів деплою.

Security and privacy considerations for health endpoints

Health‑ендпоінти не повинні розкривати секрети, користувацькі дані або докладні внутрішні відомості. Проби часті та автоматизовані; будь‑який витік множить ризик.

  • Прив’яжіть health‑сервер до localhost або окремого порту, доступного лише всередині кластера.
  • Повертавайте мінімальні тіла; ніколи не включайте змінні оточення, рядки підключень або stack trace’и.
  • Рейт‑лімітуйте або ізолюйте health‑ендпоінти від публічного ingress; вони існують для kubelet, а не для інтернету.

Використовуйте стандартні HTTP‑заголовки безпеки на зовнішніх шляхах. Базові безпечні дефолти для веб‑маршрутів — у нашій статті HTTP security headers for vibecoded apps.

Operational metrics: what to observe from probes

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

  • Відстежуйте переходи readiness у часі — на рівні деплойментів, вузлів і зон.
  • Міряйте розподіли латентностей хендлерів проб і коди помилок.
  • Корелюйте втрату readiness із ресурсними метриками (CPU, пам’ять, мережа, файлові дескриптори) і помилками залежностей.

Алертіть на стійку втрату readiness у відсотку pod’ів і на неочікувані перезапуски liveness. Алерти по одному флапаючому pod’у зазвичай — шум.

А minimal, production‑ready health check checklist

Скористайтеся цим коротким чеклістом, щоб закрити розрив між vibecoding і продакшеном у health‑чеках.

  • Розділіть /live і /ready з явними статус‑кодами.
  • Використовуйте startupProbe для варіативної ініціалізації чи важкого прогріву.
  • Тримайте liveness лише внутрішньопроцесною; тримайте readiness швидкою з лише критичними залежностями.
  • На SIGTERM перемикайте readiness у false; дренуйте, далі завершуйтеся в межах grace‑періоду.
  • Добирайте таймаути, періоди й пороги під ваш бюджет затримок і план розгортань.
  • Інструментуйте латентності проб і переходи; алертіть на стійкі проблеми, а не разові.
  • Лоад‑тестуйте з відмовами залежностей і завершеннями, щоб валідовати поведінку проб.

How Moai Team approaches this

Ми трактуємо health‑чеки як контракт інтерфейсу між сервісом і платформою. Починаємо з явних проб, що відображають реальну здатність обслуговувати: мінімальний внутрішній liveness‑хендлер і readiness‑хендлер, який перевіряє лише критичний шлях у вузькому бюджеті. Ми з’єднуємо SIGTERM із перемиканням readiness у false, імплементуємо дренування з’єднань і перевіряємо, що завершення вкладається в налаштований grace‑період.

Ми узгоджуємо таймінги проб із вашою стратегією деплойментів і SLO, щоби розгортання не спричиняли спайків 5xx. Ми підсилюємо перевірки БД, читаючи з пулів замість відкриття нових з’єднань, і калібруємо таймаути, щоб запобігти штормам підключень; для глибшої поведінки БД поєднуємо це з патернами з нашого Postgres connection pooling guide. Ми інструментуємо латентності проб і переходи як метрики першого класу та проводимо навчальні відмови: вимикаємо залежності, застосовуємо бекпрешер і шлемо SIGTERM під навантаженням. Це закриває розрив між vibecoding і продакшеном, де більшість прототипів ламаються: завершення, повільні старти та хиткі залежності.

Frequently Asked Questions

Should my liveness probe check the database?

Ні. Liveness має лише підтверджувати, що процес здатний обробити тривіальний внутрішній запит. Збої БД зазвичай тимчасові й повинні впливати на readiness, а не спричиняти перезапуски.

When do I need startupProbe?

Використовуйте startupProbe, коли ініціалізація повільна або варіативна, наприклад, завантаження великих моделей, прогрів JIT чи виконання міграцій. Вона запобігає передчасним перезапускам liveness під час старту застосунку.

What HTTP status codes should readiness and liveness return?

Повертавайте 200 для здорового стану, 503 — коли не готовий, і 500 — лише коли процес нездоровий. Окремі коди допомагають платформі й операторам швидко зрозуміти стан.

How fast should my readiness probe be?

Тримайте readiness у жорсткому таймауті — зазвичай нижче за середній бюджет латентності запитів. Повільна readiness конкурує з реальним трафіком і під навантаженням спричиняє флапінг.

How do I avoid probe flapping?

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

How do probes affect rolling updates?

Проби керують трафіком під час оновлень: нові pod’и мають пройти readiness перед отриманням трафіку, а pod’и, що завершуються, повинні скинути readiness для чистого дренування. Правильні проби запобігають спайкам 5xx під час розгортань.

Shipping a prototype to real users? We embed forward‑deployed engineers to close the gap. Talk to Moai Team.