Коротко. Kubernetes проверяет здоровье подов тремя видами проб: livenessProbe перезапускает зависший контейнер, readinessProbe убирает под из балансировки, пока он не готов принимать трафик, а startupProbe даёт медленно стартующим приложениям время на инициализацию. Это внутренний self-healing. Но пробы не видят сетевой путь снаружи кластера — для честного аптайма с точки зрения пользователя нужен внешний synthetic-мониторинг сайтов.
Три вида проб и их роли
Путаница между liveness и readiness — источник самых болезненных инцидентов в Kubernetes. Их назначение принципиально разное:
- livenessProbe — «жив ли процесс?». Провал → kubelet перезапускает контейнер;
- readinessProbe — «готов ли принимать трафик?». Провал → под убирается из Endpoints, но не перезапускается;
- startupProbe — «закончил ли стартовать?». Пока не прошла, liveness и readiness отключены.
Пример манифеста
Правильная конфигурация для веб-сервиса с health-эндпоинтами:
apiVersion: apps/v1
kind: Deployment
metadata:
name: web
spec:
template:
spec:
containers:
- name: web
image: myapp:1.4.2
ports:
- containerPort: 8080
startupProbe:
httpGet:
path: /healthz
port: 8080
failureThreshold: 30
periodSeconds: 5
livenessProbe:
httpGet:
path: /healthz
port: 8080
initialDelaySeconds: 0
periodSeconds: 10
failureThreshold: 3
readinessProbe:
httpGet:
path: /readyz
port: 8080
periodSeconds: 5
failureThreshold: 3Liveness vs readiness: типичные ошибки
| Ошибка | Последствие | Как правильно |
|---|---|---|
| liveness проверяет зависимость (БД) | Каскадный рестарт всех подов при сбое БД | liveness — только сам процесс |
| Нет startupProbe для медленного старта | liveness убивает под до инициализации | Добавить startupProbe с запасом |
| readiness и liveness на один путь | Под перезапускается вместо вывода из ротации | Разделить /healthz и /readyz |
| Слишком агрессивный failureThreshold | Флапающие рестарты под нагрузкой | 3–5 и адекватный periodSeconds |
Золотое правило: liveness проверяет ТОЛЬКО сам процесс. Если в liveness проверять базу или внешний API документацию, сбой зависимости устроит каскадный перезапуск всех реплик.
Чего пробы не видят
Probes работают внутри кластера: kubelet стучится в под напрямую. Они не проверяют Ingress, балансировщик, DNS, TLS-терминацию и сеть между пользователем и кластером. Под может быть «Ready», а снаружи сайт — недоступен из-за неверного Ingress или просроченного сертификата на LoadBalancer.
Внешний слой поверх Kubernetes
enterno.io проверяет полный путь снаружи — так, как видит пользователь: HTTP-ответ через Ingress, валидность SSL на балансировщике, DNS-резолв и Ping из регионов RU / EU / US. Это дополняет внутренние probes, а не заменяет: probes лечат поды, внешний монитор ловит проблемы на границе кластера. Бесплатно — 10 мониторов с интервалом 5 минут, на платных — 1 минута / 30 секунд. Алерты в Telegram, Slack, email, webhook, PagerDuty.
Для cron-задач и батч-джоб в Kubernetes используйте heartbeat-мониторинг (dead man's switch): джоб пингует уникальный URL, и если пинг не пришёл вовремя — приходит алерт.
FAQ
Почему под рестартует под нагрузкой?
Чаще всего liveness-проба таймаутит из-за нехватки CPU. Увеличьте timeoutSeconds, проверьте лимиты ресурсов и не вешайте на liveness тяжёлые проверки.
Нужен ли startupProbe всегда?
Нет, только для приложений с долгой инициализацией (прогрев кэша, миграции). Для быстрых сервисов хватает liveness + readiness.
Заменяет ли readinessProbe внешний мониторинг?
Нет. readiness управляет балансировкой внутри кластера, но не видит Ingress, DNS и путь к пользователю. Внешний synthetic-монитор нужен отдельно.
Как мониторить CronJob в Kubernetes?
Через heartbeat: задача делает HTTP-пинг на enterno.io/heartbeat в конце выполнения; пропущенный пинг = алерт о незапустившейся или зависшей джобе.
Добавьте взгляд снаружи кластера: создайте монитор на enterno.io/monitors для проверки Ingress и SSL. Полезное: health-check эндпоинты, мониторинг контейнеров, мониторинг для разработчиков.