Первая проба, которая срабатывает после успешного развёртывания пода в Kubernetes

Мониторинг первой пробы после успешного деплоя Pod

В Kubernetes после успешного развёртывания пода и его запуска критически важна первая проба (initial probe), которая проверяет, готово ли приложение принимать трафик. Хотя в K8s нет явного понятия "первая проба", этот функционал реализуется через комбинацию Readiness Probe и Startup Probe, которые становятся активными сразу после старта контейнера.

Ключевые механизмы для реализации "первой проверки"

Kubernetes предоставляет три типа проб: Liveness, Readiness и Startup. Для сценария "первой пробы после деплоя" наиболее релевантны:

1. Startup Probe — используется для "тяжёлых" приложений с долгим временем запуска. Она отключает проверки Liveness/Readiness до первой успешной проверки Startup. Это гарантирует, что приложение не будет убито или получить трафик до полной инициализации.
2. Readiness Probe — определяет, готов ли Pod принимать сетевые запросы. Успех этой пробы — ключевой триггер для добавления пода в эндпоинты Service. Эту проверку можно считать той самой "первой успешной пробой", после которой под считается рабочим.

Типичная конфигурация в манифесте

Вот пример фрагмента манифеста пода, где startupProbe дает приложению время на запуск, а readinessProbe выполняет финальную проверку готовности:

apiVersion: v1
kind: Pod
metadata:
  name: my-app
spec:
  containers:
  - name: app
    image: myapp:latest
    ports:
    - containerPort: 8080
    startupProbe:
      httpGet:
        path: /health/startup
        port: 8080
      failureThreshold: 30  # Позволяет ждать до 30 * periodSeconds = 150 секунд
      periodSeconds: 5
    readinessProbe:
      httpGet:
        path: /health/ready
        port: 8080
      initialDelaySeconds: 5
      periodSeconds: 5
      successThreshold: 1  # Первый же успех переведёт под в состояние Ready
      failureThreshold: 3
    livenessProbe:
      httpGet:
        path: /health/live
        port: 8080
      periodSeconds: 10

Последовательность срабатывания:

1. Контейнер запускается (состояние Running).
2. Немедленно активируется startupProbe. До её успеха readinessProbe и livenessProbe не начинаются.
3. После первого успеха startupProbe (например, приложение инициализировало БД, загрузило кэш) она отключается.
4. Сразу начинается readinessProbe. Первый её успех (при successThreshold: 1) — это тот самый момент, когда под считается готовым. Kubelet обновляет статус пода на Ready, и контроллер сервиса добавляет его IP-адрес в список эндпоинтов.
5. Теперь под может получать трафик от Service и Ingress.

Зачем это нужно? (Архитектурный контекст)

• Предотвращение даунтайма: Без проб трафик может начать поступать в ещё неинициализированное приложение, что вызовет ошибки 5xx.
• Плавный запуск (RollingUpdate): При деплое Deployment контроллер K8s ждёт, пока новый под не станет Ready, прежде чем начать останавливать старые пода. Это обеспечивает нулевое время простоя.
• Самоисцеление (Self-healing): Если первая readinessProbe не сработает за время failureThreshold * periodSeconds, под будет помечен как Not Ready и исключён из балансировщика нагрузки, даже находясь в состоянии Running.

Практические рекомендации по настройке

• Разделение эндпоинтов: /health/startup, /health/ready, /health/live должны проверять разную глубину готовности. Startup — факт запуска процесса, Ready — доступность БД, кэша, внешних API, Live — отсутствие deadlock.
• Таймауты и задержки: initialDelaySeconds должен учитывать минимальное время инициализации. periodSeconds — баланс между скоростью детектирования и нагрузкой.
• Пороги: successThreshold: 1 для быстрого перевода в Ready, failureThreshold: 3 для защиты от ложных срабатываний.
• Логирование: Приложение должно логировать момент успешного прохождения readiness check. Это точка отсчёта в логах для анализа времени запуска.

Альтернативный паттерн без Startup Probe: Для легковесных приложений можно обойтись только readinessProbe с увеличенным initialDelaySeconds. Однако startupProbe — более элегантное и управляемое решение, так как явно отделяет фазу запуска от фазы готовности.

Таким образом, "первая проба, которая срабатывает после успешного развёртывания" — это, как правило, успешная Readiness Probe. Именно её конфигурации и логике проверки следует уделять максимальное внимание, так как она напрямую влияет на доступность сервиса для пользователей после каждого деплоя.