Readiness и Liveness Probes - это механизмы проверки работоспособности контейнеров в Kubernetes, которые напрямую влияют на маршрутизацию трафика и стабильность приложений. Liveness Probe определяет, нужно ли перезапустить контейнер, а Readiness Probe решает, можно ли направлять к нему запросы через Service. Правильная настройка этих проб предотвращает отправку трафика на неготовые или неработающие экземпляры, снижает количество ошибок 5xx и обеспечивает плавные обновления. Это руководство содержит готовые YAML-манифесты, рекомендации по параметрам и методы диагностики для stateful и stateless приложений.
Readiness vs Liveness Probe: какая проба за что отвечает и как это влияет на трафик
Liveness Probe контролирует жизненный цикл контейнера, а Readiness Probe управляет его доступностью в сетевой балансировке. Kubelet использует Liveness Probe для принятия решения о перезапуске контейнера. Service и Service Mesh полагаются на статус Readiness Probe для включения или исключения IP-адреса пода из списка Endpoints. Путаница между этими пробами приводит к нестабильной работе: контейнеры перезапускаются без необходимости или трафик направляется на неготовые экземпляры.
Как kubelet использует Liveness Probe для здоровья контейнера
Kubelet периодически выполняет Liveness Probe согласно параметрам periodSeconds. При достижении failureThreshold kubelet отправляет контейнеру сигнал SIGTERM, запускает grace period и затем принудительно завершает процесс. Перезапущенный контейнер получает новый Restart Count. Просмотреть причину можно командой kubectl describe pod в секции Events - там отображается сообщение типа "Liveness probe failed: dial tcp connection refused". Для stateful-приложений, таких как базы данных PostgreSQL или кластеры Redis, неконтролируемый перезапуск по Liveness Probe опасен риском потери данных или split-brain ситуации.
Как Service Mesh и Service используют Readiness Probe для маршрутизации
Kubelet обновляет статус готовности пода в Endpoints API. Kube-proxy или CNI-плагин, например Cilium, синхронизируют эти изменения, обновляя правила iptables/ipvs или eBPF-программы. Service Mesh, такой как Istio или Linkerd, получает информацию о готовности через тот же API и корректирует конфигурацию sidecar-прокси. Когда Readiness Probe падает, IP-адрес пода удаляется из Endpoints, и новые TCP-соединения или HTTP-запросы перестают на него попадать. Этот механизм критичен для rolling updates и canary-развертываний, так как позволяет постепенно вводить в эксплуатацию новые версии только после их полной готовности.
Типы проб на практике: HTTP, TCP и Exec с готовыми шаблонами YAML
Kubernetes поддерживает три типа проб, которые отличаются методом проверки, сложностью и накладными расходами. HTTP GET - оптимален для веб-приложений и REST API. TCP Socket - подходит для stateful-сервисов без HTTP-интерфейса. Exec - гибкий, но ресурсоемкий вариант для сложных сценариев.
HTTP GET probe: идеально для веб-приложений и REST API
HTTP-проба отправляет GET-запрос на указанный путь и порт, ожидая код ответа от 200 до 399. Создайте эндпоинт /health или /ready, который проверяет критичные зависимости: подключение к базе данных, доступность кэша, дискового пространства. Время ответа должно быть меньше timeoutSeconds, иначе проба считается неудачной.
apiVersion: apps/v1
kind: Deployment
metadata:
name: web-app
spec:
template:
spec:
containers:
- name: app
image: nginx:latest
readinessProbe:
httpGet:
path: /health
port: 80
initialDelaySeconds: 10
periodSeconds: 5
livenessProbe:
httpGet:
path: /health
port: 80
initialDelaySeconds: 30
periodSeconds: 10Пример простого эндпоинта на Python с использованием FastAPI:
from fastapi import FastAPI
app = FastAPI()
@app.get("/health")
async def health_check():
# Проверка подключения к БД, кэшу
return {"status": "ok", "timestamp": time.time()}Для Go-приложения используйте стандартный пакет net/http. Убедитесь, что эндпоинт не требует аутентификации и возвращает 200 OK только при полной готовности сервиса обрабатывать пользовательские запросы.
TCP Socket probe: для stateful-сервисов - баз данных, кэшей, мемкэша
TCP-проба устанавливает соединение с указанным портом контейнера. Если соединение устанавливается успешно, проба считается пройденной. Этот метод предпочтительнее Exec для баз данных, так как не создает дополнительной нагрузки командными оболочками и дочерними процессами.
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: postgres
spec:
template:
spec:
containers:
- name: postgres
image: postgres:15
readinessProbe:
tcpSocket:
port: 5432
initialDelaySeconds: 30
periodSeconds: 10
# Liveness Probe для БД настраивайте с осторожностью
livenessProbe:
tcpSocket:
port: 5432
initialDelaySeconds: 60
failureThreshold: 3Для Redis конфигурация аналогична, укажите порт 6379. Ограничение TCP-проверки в том, что она подтверждает только открытие порта, но не логическую готовность сервиса. База данных может принимать соединения, но находиться в режиме восстановления или репликации. Используйте TCP-пробу как readinessProbe, но для livenessProbe рассмотрите комбинацию с Exec или специализированным sidecar-контейнером.
Exec probe: крайняя мера для сложных сценариев проверки
Exec-проба запускает команду внутри контейнера. Код возврата 0 означает успех, любой другой - неудачу. Используйте этот тип для проверки наличия файла готовности, отсутствия дедлоков или специфичных внутренних состояний.
livenessProbe:
exec:
command:
- cat
- /tmp/healthy
initialDelaySeconds: 15
periodSeconds: 20Exec-пробы создают накладные расходы: каждый вызов запускает новый процесс, что потребляет CPU. При высокой частоте проверок это может привести к contention. Команды могут блокироваться из-за зависших дочерних процессов или нехватки ресурсов. Рекомендация: избегайте сложной логики в Exec. Если нужна нетривиальная проверка здоровья, запустите sidecar-контейнер с HTTP-эндпоинтом и используйте HTTP GET probe. Например, sidecar может выполнять запросы pg_isready для PostgreSQL и предоставлять результат через простой веб-сервер.
Тонкая настройка параметров: как избежать ложных срабатываний и «скачущих» подов
Значения по умолчанию для проб не подходят для production-нагрузки. Неправильные initialDelaySeconds приводят к перезапускам во время инициализации приложения. Слишком частые проверки увеличивают нагрузку на сеть и сам контейнер. Параметры failureThreshold и successThreshold защищают от временных сетевых сбоев и плавного возврата в балансировку.
initialDelaySeconds и periodSeconds: учет времени инициализации и нагрузки
Замерьте время полного старта вашего приложения в типичных условиях. Добавьте к этому значению 30-50% запаса и установите initialDelaySeconds. Для Java-приложений с тяжелыми JVM это может быть 60-120 секунд. Для легких Go-сервисов достаточно 5-10 секунд. Период проверки periodSeconds влияет на нагрузку: HTTP-запрос каждые 5 секунд на 100 подов создает 20 запросов в секунду. В production используйте periodSeconds от 10 до 30 секунд для баланса между скоростью обнаружения и накладными расходами. TimeoutSeconds должен быть меньше periodSeconds, обычно 2-5 секунд для HTTP-проб.
failureThreshold и successThreshold: пороги устойчивости для «шумовых» сбоев
FailureThreshold определяет, сколько последовательных неудач нужно для перевода пробы в состояние Failure. Для Liveness Probe установите значение 3-4, чтобы кратковременные проблемы не вызывали перезапуск. Например, при periodSeconds=5 и failureThreshold=3 проба будет считаться упавшей только после 15 секунд непрерывных сбоев. SuccessThreshold для Readiness Probe часто ставят равным 2. Это означает, что после временного сбоя под должен дважды успешно пройти проверку, прежде чем его вернут в балансировку. Такой подход предотвращает "скачущие" поды, которые то появляются, то исчезают из Endpoints при нестабильной сети. Для Liveness Probe successThreshold всегда равен 1.
Диагностика проблем: что делать, если пробы постоянно падают
Если пробы не работают, используйте стандартные инструменты Kubernetes для анализа. Начните с проверки статуса пода и событий, затем перейдите к логам и внутренней диагностике сети.
Анализ событий Pod и статусов контейнера через kubectl
Команда kubectl describe pod <pod-name> показывает ключевую информацию. В секции Conditions проверьте Ready и ContainersReady - они должны быть True. В секции Events ищите предупреждения о failed probes. Сообщение "Readiness probe failed: dial tcp 10.244.1.5:8080: connect: connection refused" указывает на недоступность порта. "Liveness probe failed: Get \"http://10.244.1.5:8080/health\": context deadline exceeded" означает, что запрос превысил timeoutSeconds. Restart Count показывает количество перезапусков контейнера из-за Liveness Probe.
Типичные ошибки конфигурации и их исправление
- Неправильный порт или путь: Убедитесь, что порт в httpGet или tcpSocket совпадает с containerPort в спецификации контейнера. Путь должен быть доступен без аутентификации.
- Слишком короткий initialDelaySeconds: Увеличьте задержку, если приложение стартует дольше. Проверьте логи инициализации.
- Проверка по localhost внутри контейнера: Пробы выполняются изнутри контейнера, но используют его сетевой namespace. Убедитесь, что сервис слушает на 0.0.0.0, а не 127.0.0.1.
- Забытый successThreshold для readiness после сбоя: После восстановления под может не возвращаться в балансировку. Установите successThreshold: 2.
- Конфликт probes с ресурсами limits: Если контейнеру не хватает CPU, Exec-пробы могут зависать. Увеличьте limits или перейдите на HTTP/TCP проверки.
Чеклист диагностики: 1) Выполните kubectl logs <pod-name> для просмотра логов приложения. 2) Используйте kubectl describe pod для анализа событий. 3) Проверьте доступность порта изнутри пода командой kubectl exec <pod-name> -- curl http://localhost:8080/health. 4) Проанализируйте использование ресурсов через kubectl top pod. 5) Для отладки временно упростите пробу до минимальной конфигурации.
Продвинутые сценарии: интеграция с Service Mesh и стратегии для канареечного развертывания
В сложных средах нативные пробы Kubernetes интегрируются с Service Mesh и системами продвинутой маршрутизации. Istio и Linkerd дополняют их своими health checks, основанными на метриках и задержках ответа.
Как пробы Kubernetes взаимодействуют с Istio VirtualService и DestinationRule
Istio sidecar-прокси (envoy) работает параллельно с kubelet. Readiness Probe Kubernetes управляет членством пода в Endpoints, что влияет на базовую маршрутизацию через kube-proxy. Istio использует эти же Endpoints для своей конфигурации, но может применять дополнительные фильтры через DestinationRule. В VirtualService можно настроить правила маршрутизации, которые учитывают готовность версии, определенную через Readiness Probe.
Пример сценария canary-развертывания: новая версия приложения (canary) разворачивается с readinessProbe, которая проверяет не только доступность, но и внутренние метрики, например, процент ошибок. Пока проба не проходит, вес трафика в DestinationRule остается 0. После успешного прохождения readinessProbe и дополнительной проверки через Istio health check вес постепенно увеличивается. Это позволяет реализовать автоматическое canary-развертывание, где продвижение версии зависит от ее фактической готовности.
Отключить пробы Kubernetes в пользу Istio Health Checks можно, но это требует тщательной настройки. Istio предлагает active health checking через параметры outlierDetection в DestinationRule, которые отслеживают процент неудачных запросов и исключают нестабильные экземпляры. Однако базовые Readiness/Liveness Probes остаются необходимы для корректной работы rolling updates и взаимодействия с другими компонентами Kubernetes, такими как Horizontal Pod Autoscaler.
Для управления сложными сценариями маршрутизации, включая Blue-Green и A/B тестирование, изучите продвинутые стратегии развертывания в Kubernetes. В этом руководстве вы найдете готовые манифесты YAML и примеры интеграции с Service Mesh для production-сред.
При построении отказоустойчивой инфраструктуры также важно настроить мониторинг. Используйте готовые шаблоны алертов Prometheus и дашборды Grafana для отслеживания состояния проб, количества рестартов и доступности эндпоинтов.
Для эффективной работы с Kubernetes требуется глубокое понимание его основных абстракций. Если вам нужно освежить знания о структуре манифестов, обратитесь к практическому гайду по структуре YAML и примерам Pod и Deployment. А для комплексного управления приложениями изучите полное руководство по Deployment с production-манифестами.
DevOps-инженерам и системным администраторам, которые хотят систематизировать знания по современным практикам, будет полезен обзор DevOps и Linux-администрирования с актуальными примерами.