Перевірки стану відповідають на різні питання, і оркестратор реагує на них по-різному.
Liveness - «процес живий чи завис?»
Якщо перевірка не проходить кілька разів поспіль, контейнер перезапускається. Призначення - виходити з безвихідних станів: взаємоблокування, нескінченний цикл, вичерпані воркери.
Readiness - «чи готовий приймати трафік прямо зараз?»
Якщо не проходить - контейнер прибирається з балансування, але не перезапускається. Призначення - не слати запити туди, де їх не оброблять: застосунок ще прогрівається, тимчасово перевантажений, втратив з'єднання з залежністю.
Startup - «чи завершився запуск?»
Поки вона не пройшла, інші перевірки не виконуються. Для застосунків з довгим стартом: без неї liveness-перевірка може «вбивати» контейнер, що просто повільно запускається.
Що буде, якщо переплутати:
- liveness перевіряє базу даних. База на хвилину недоступна - усі контейнери застосунку провалюють liveness і одночасно перезапускаються. Після відновлення бази - шторм перезапусків і холодний старт усього сервісу. Залежності - у readiness, а liveness має перевіряти лише сам процес;
- немає readiness - трафік іде на контейнер, який ще прогріває кеш чи виконує міграції: користувачі отримують помилки після кожного деплою;
- занадто суворі пороги (тайм-аут 1 секунда під навантаженням) - здорові контейнери перезапускаються саме тоді, коли найбільше потрібні;
- важка перевірка (повний запит до бази, рендер сторінки) на кожні кілька секунд - зайве навантаження.
Як це виглядає в Docker: HEALTHCHECK у Dockerfile чи healthcheck у Compose дає один статус (healthy/unhealthy). Сам Docker не перезапускає нездоровий контейнер - на статус реагують Swarm, Compose з depends_on: condition: service_healthy чи зовнішні інструменти.
Для Laravel:
- liveness - легкий ендпойнт без звернень до залежностей (маршрут
/upпідходить, якщо не перевантажений подіями); - readiness - окремий ендпойнт, що перевіряє базу, Redis, наявність закешованої конфігурації;
- черги й планувальник - окремі перевірки: воркер без HTTP перевіряють командою.