Коротко: Проверки readiness и liveness решают, когда pod может принимать трафик и когда его нужно перезапустить; это самый простой и самый действенный рычаг, чтобы держать vibecoded‑приложение живым под реальной нагрузкой. Liveness‑проверка должна отвечать только на вопрос «Достаточно ли здоров процесс, чтобы продолжать работать?», а readiness‑проверка — на вопрос «Может ли этот инстанс обслуживать запросы прямо сейчас?». Большинство сбоев при неудачных роллаутах происходят из‑за смешения этих понятий или из‑за проверок, которые слишком медленные, чрезмерно строгие или проверяют не то. Используйте startupProbe для медленной загрузки, переводите readiness в false при SIGTERM для корректного завершения и держите обработчики проверок быстрыми и изолированными. Продакшен‑готовые приложения поставляются с проверками, которые отражают реальную способность обслуживать трафик без флаппинга.

Главное

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

Что такое проверки readiness и liveness и зачем они нужны?

Readiness и liveness — это проверки здоровья Kubernetes, которые управляют маршрутизацией трафика и перезапусками на уровне pod. Readiness определяет, будет ли pod добавлен в endpoints службы, а liveness — нужно ли kubelet перезапускать контейнер.

Используйте liveness, чтобы обнаруживать «зависшие» процессы, которые не смогут восстановиться без перезапуска. Используйте readiness, чтобы сигнализировать о временной недоступности — прогрев кэшей, backpressure или контролируемое завершение работы. Роллауты, автоскейлинг и реагирование на инциденты зависят от этих сигналов, чтобы не отправлять пользователей на сломанные pod’ы.

Как работают проверки readiness и liveness в Kubernetes?

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

  • Liveness: при провале нужное число раз kubelet перезапускает контейнер.
  • Readiness: при провале pod исключается из endpoints службы, пока проверка снова не пройдёт.
  • Startup: во время старта работает только startupProbe; когда она проходит, запускаются liveness и readiness. Это предотвращает перезапуски при медленной инициализации.

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

Что на самом деле должна проверять production‑liveness?

Production‑liveness должна проверять только способность контейнера делать «вперёд» — продолжать прогресс. Держите её минимальной и внутренней, чтобы внешние временные сбои не вызывали лишних рестартов.

  • Проверьте, что событийный цикл или пул потоков отзывчив, отдавая крошечный внутрипроцессный хендлер.
  • Убедитесь, что нет дедлока или OOM, мешающих выполнению базового хендлера.
  • Не ходите в базы, очереди или внешние API в liveness; внешние сбои не должны вынуждать рестарт контейнера.
  • Отвечайте быстро простым 200 OK; избегайте «тяжёлых» путей с логированием и лишними аллокациями.

Перезапуски дороги под нагрузкой. Оставьте liveness для невосстанавливаемых состояний, а не как общий ответ на ошибки.

Что должна проверять production‑readiness?

Production‑readiness должна подтверждать, что инстанс может обслуживать трафик прямо сейчас. Она может учитывать критичные зависимости, но обязана отвечать быстро и не провоцировать каскадные отказы.

  • Подтвердите, что HTTP‑сервер принимает соединения и отдаёт тривиальный хендлер.
  • Опционально проверьте, что пул соединений к базе содержит хотя бы одно здоровое соединение или может открыть его в жёстком бюджете. Используйте лёгкий ping‑запрос, а не тяжёлую транзакцию. Рекомендации по безопасному дизайну пулов: Postgres connection pooling for MVPs.
  • Если обработка запросов требует конкретный кэш, проверьте, что клиент кэша подключён; не выполняйте flush или перестройку в проверке.
  • Если критичный брокер сообщений или стрим нужен для приёма записей, проверьте, что клиент подключён или может опубликовать в служебную health‑тему, без постоянных побочных эффектов.
  • Экспонируйте backpressure: когда очереди превышают безопасную глубину или на ноде закончились файловые дескрипторы, помечайте «не готов», чтобы сбрасывать нагрузку.

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

Как спроектировать health‑эндпоинты, которые не врут

Health‑эндпоинты должны быть явными, быстрыми и стабильными под стрессом. Один /healthz, который всегда возвращает 200, хуже, чем отсутствие проверок: он уводит трафик в ошибочные pod’ы при сбоях.

  • Разведите хендлеры: отдельный для liveness (чисто внутрипроцессный) и отдельный для readiness (внутрипроцессный + критичные зависимости).
  • Возвращайте 200 для «здоров», 503 для «не готов» и 500 — только для настоящих сбоев живости. Используйте явные коды вместо кодирования состояния в JSON.
  • Держите тела ответов крошечными и по возможности пустыми; проверке не нужны подробные пейлоады. Подробную диагностику отправляйте в логи и метрики.
  • Ставьте жёсткие таймауты на каждый хендлер, короче, чем таймаут самой пробы, чтобы избежать head‑of‑line blocking в сервере.
  • Не требуйте аутентификацию; держите хендлеры на внутреннем порту/пути с ограничениями сетевой политики.

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

Когда использовать startupProbe?

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

  • Долгая загрузка модулей, прогрев JIT или шаги компиляции во время рантайма.
  • Миграции данных или проверки схемы, которые нужно закончить до старта обслуживания.
  • Крупные прогревы кэша, необходимые, чтобы инстанс укладывался в SLO.

Во время startupProbe liveness отключена. Выберите консервативные timeout и period, чтобы избежать ложных рестартов, а затем переходите к обычным readiness/liveness, когда готовы обслуживать.

Как проверки помогают в корректном завершении?

Корректное завершение (graceful shutdown) требует перевести readiness в false при SIGTERM, слить/доделать текущую работу и завершиться в пределах terminationGracePeriodSeconds. Так балансировщик перестаёт слать новые запросы, пока pod заканчивает текущие.

  1. При SIGTERM или в preStop немедленно установите readiness в false и отвечайте на readiness‑проверки 503.
  2. Перестаньте принимать новые соединения и перестаньте вычитывать новые задачи у фоновых воркеров.
  3. Завершите текущие HTTP‑запросы и фоновые задачи в пределах grace‑периода; отменяйте или чекпойнтьте длинные.
  4. Корректно закройте сетевые соединения и завершитесь раньше terminationGracePeriodSeconds.

Корректное завершение — основа роллаутов без простоев и безопасных drain’ов нод. Liveness должна оставаться «зелёной» во время дренирования, иначе kubelet может убить контейнер до завершения работы.

Какие пороги и тайминги настраивать?

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

  • Период: выберите частоту, которая обнаруживает сбои в рамках вашего error‑бюджета без лишней нагрузки; обычно каждые несколько секунд для readiness и чуть реже для liveness.
  • Таймаут: поставьте короче обычного таймаута запроса и соразмерно работе хендлера (сотни миллисекунд — пара секунд для большинства веб‑приложений).
  • Порог ошибок: разрешайте кратковременный джиттер для readiness (несколько подряд ошибок) и меньше — для liveness, так как это простой внутрипроцессный хендлер.
  • Порог успехов: для readiness требуйте более одного успеха, чтобы вернуться в ротацию, если система склонна к флаппингу; liveness обычно достаточно одного успеха.
  • Startup: дайте startupProbe щедрое окно, если cold start или прогрев кэшей плавает, затем переходите к обычным проверкам.

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

Какие зависимости включать в readiness, а какие — нет?

Не каждая зависимость должна попадать в readiness. Включайте только те, что критичны для обслуживания того трафика, который маршрутизируется на pod.

  • Включать: HTTP‑сервер, основную базу данных в путях запроса, обязательный кэш перед запросами или брокер, без которого нельзя синхронно принимать записи.
  • Исключать: необязательные аналитические сливы, асинхронные email‑очереди или batch‑источники данных; деградируйте изящно.
  • Ограждать: если база иногда медленная, используйте в readiness лёгкий ping с жёстким таймаутом, а не полный запрос.

Если вы полагаетесь на реляционную базу, проверяйте состояние пула соединений, а не открывайте новое соединение на каждую проверку. Неограниченные попытки подключения из проверок могут исчерпать пул. Советы по тюнингу пулов и безопасным таймаутам — в нашем гайде Postgres connection pooling.

Как проверки должны вести себя при обратном давлении?

При устойчивой нагрузке здоровая система может вынужденно сбрасывать трафик. Readiness — это рычаг, который снижает приём на pod, сохраняя liveness.

  • Пробрасывайте глубину внутренних очередей и загрузку CPU в readiness‑хендлер и помечайте «не готов», когда превышены пороги.
  • Ограничивайте частоту вычисления readiness, чтобы не дребезжать; переключайтесь только при устойчивом пересечении порогов.
  • Координируйтесь с автоскейлерами по CPU или кастомным метрикам, чтобы pod’ы возвращались в ротацию по мере снижения давления.

Readiness, понимающая backpressure, предотвращает взрыв хвостовой латентности и защищает ваш error‑бюджет во всплески трафика.

Типичные анти‑паттерны, ломающие роллауты

Большинство продакшен‑инцидентов, связанных с проверками здоровья, вызваны несколькими предсказуемыми ошибками. Избегайте этих анти‑паттернов, переводя vibecoded‑приложение в прод.

  • Liveness выполняет запрос к базе или внешний API. Внешние сбои перезапускают контейнер и мешают восстановлению.
  • Readiness делает тяжёлую работу — перестройку кэша или миграции. Проба становится генератором нагрузки, который топит pod.
  • Один сложный /healthz. Единый флаг скрывает различие семантики и поощряет неуместные проверки.
  • Таймауты проб больше таймаутов сервера. Проба держит поток дольше пользовательских запросов и вызывает head‑of‑line blocking.
  • Нет startupProbe при медленном старте. Pod уходит в цикл перезапусков до инициализации.
  • Нет сброса readiness на SIGTERM. Pod получает трафик во время выключения, что даёт лишние 5xx при роллаутах.
  • Хендлеры здоровья логируют WARN/ERROR на каждый хит. Пробы захламляют логи и маскируют реальные сигналы.

Сделайте проверки скучными. Скучные health‑checks надёжны и недороги.

Как реализовать проверки в популярных стеках?

Реализация проста, если разделять обязанности и держать хендлеры маленькими. Паттерны одинаковы в разных языках и фреймворках.

  • HTTP‑серверы: смонтируйте два роута, например, /live для liveness и /ready для readiness, с жёсткими таймаутами на уровне сервера/мидлвари.
  • Фоновые воркеры: поднимите отдельный порт или HTTP‑эндпоинт из воркера, либо используйте exec‑пробы, проверяющие способность принять и обработать no‑op задачу.
  • Сигналы процесса: зарегистрируйте обработчик SIGTERM, который переключает флаг readiness и закрывает листенеры; многие фреймворки дают хуки graceful shutdown — свяжите их с флагом readiness.
  • Проверки базы: пингуйте пул или выполняйте лёгкое чтение с коротким таймаутом; никогда не создавайте новые соединения на каждую пробу.
  • Кэш/брокер: проверяйте, что клиенты в состоянии «connected»; избегайте pub/sub, если только это не выделенный health‑канал без побочек.

По возможности используйте HTTP‑пробы: их проще таймить и инструментировать, чем exec, и они лучше отражают здоровье сервиса.

Как тестировать проверки до продакшена?

Тестируйте здоровье в условиях, для которых оно предназначено: медленные старты, сбои зависимостей, поочерёдные обновления и ресурсное давление. Тесты, которые в деве лишь проверяют 200, не решают задачу.

  • Искусственно замедлите старт, задержав зависимости; убедитесь, что startupProbe удерживает рестарты до конца инициализации.
  • Выключите базу или введите DNS‑сбои; проверьте, что readiness быстро уходит в 503, а liveness остаётся 200.
  • Шлите SIGTERM во время нагрузочного теста; убедитесь, что readiness падает сразу, текущий трафик завершается и всплеска 5xx нет.
  • Смоделируйте завалы очередей; проверьте, что readiness падает при backpressure и восстанавливается без флаппинга, когда давление уходит.

Используйте реалистичные объёмы данных и паттерны запросов. Если нужна репрезентативная несекретная выборка, см. наш материал о test data management for MVPs.

Как проверки взаимодействуют с роллаутами и перераспределением трафика?

Проверки — это слой безопасности для обновлений без простоя, канареек и blue‑green. Если проверки отражают реальную способность обслуживать, платформа естественно обходит нездоровые pod’ы во время роллаута.

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

Комбинируйте проверки с поэтапным сдвигом трафика и версионированной конфигурацией. Если само приложение точно экспонирует здоровье, платформа сможет принимать безопасные решения без хрупких скриптов деплоя.

Безопасность и приватность health‑эндпоинтов

Health‑эндпоинты не должны раскрывать секреты, пользовательские данные или подробные внутренности. Пробы частые и автоматические; любая утечка множит риск.

  • Привяжите сервер здоровья к localhost или отдельному порту, доступному только внутри кластера.
  • Возвращайте минимальные тела; никогда не включайте переменные окружения, строки подключения или стектрейсы.
  • Ограничьте rate или изолируйте health‑эндпоинты от публичного ingress; они нужны kubelet, а не интернету.

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

Операционные метрики: что наблюдать по проверкам

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

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

Оповещайте о длительной потере readiness на проценте pod’ов и о неожиданных рестартах liveness. Алерты по одному «дребезжащему» pod’у — чаще шум.

Минимальный чек‑лист production‑ready health‑checks

Используйте этот короткий список, чтобы закрыть разрыв между vibecoding и продом в теме проверок здоровья.

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

Как Moai Team подходит к этому

Мы рассматриваем проверки здоровья как интерфейсный контракт между вашим сервисом и платформой. Начинаем с явных проб, отражающих реальную способность обслуживать: минимальный внутрипроцессный liveness‑хендлер и readiness‑хендлер, который проверяет только критичный путь в жёстком бюджете. Мы привязываем SIGTERM к переключению readiness в false, реализуем дренирование соединений и проверяем, что завершение укладывается в настроенный grace‑период.

Мы согласуем тайминги проверок со стратегией деплоя и SLO, чтобы роллауты не давали всплесков 5xx. Мы укрепляем проверки базы, читая из пулов вместо открытия новых соединений, и калибруем таймауты, чтобы не допускать штормов подключений; для более глубокой работы с базой используем паттерны из нашего Postgres connection pooling guide. Мы делаем латентности и переходы проб первоклассными метриками и проводим учения по сбоям: режем зависимости, включаем backpressure и шлём SIGTERM под нагрузкой. Это закрывает разрыв между vibecoding и продом там, где ломается большинство прототипов: выключения, медленные старты и дрожание зависимостей.

Частые вопросы

Должна ли моя liveness‑проверка ходить в базу?

Нет. Liveness должна лишь подтверждать, что процесс способен обработать тривиальный внутрипроцессный запрос. Сбои базы обычно временные и должны влиять на readiness, а не вызывать рестарты.

Когда мне нужна startupProbe?

Используйте startupProbe, когда инициализация медленная или непредсказуемая: загрузка крупных моделей, прогрев JIT или миграции. Она предотвращает преждевременные рестарты liveness во время загрузки приложения.

Какие коды статуса должны возвращать readiness и liveness?

Возвращайте 200 для «здоров», 503 для «не готов», а 500 — только когда процесс нездоров. Отдельные коды помогают платформе и операторам быстро понимать состояние.

Насколько быстрой должна быть readiness‑проверка?

Держите readiness в жёстком таймауте, обычно ниже среднего бюджета латентности запросов. Если проверка медленная, она конкурирует с реальным трафиком и может флаппать под нагрузкой.

Как избежать флаппинга проверок?

Используйте подходящие пороги ошибок и успехов, не проверяйте необязательные зависимости и опирайтесь на стабильные индикаторы — здоровье пула и глубину очередей. Убедитесь, что таймауты хендлеров короче таймаутов самих проб.

Как пробы влияют на rolling‑обновления?

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

Отправляете прототип к реальным пользователям? Мы встраиваем форвард‑деплойд инженеров, чтобы закрыть разрыв. Talk to Moai Team.