Для чего нужны пробы (probes) в Kubernetes?

Пробы — это механизм, с помощью которого Kubernetes получает сигналы о состоянии приложения внутри контейнера, что позволяет автоматически управлять его жизненным циклом и маршрутизацией трафика. Без них Kubernetes знает только о состоянии контейнера как процесса, но не о состоянии сервиса внутри него.

Три типа проб, которые я настраиваю:

1. Liveness Probe (Проба жизнеспособности):

   • Назначение: Определяет, жив ли контейнер. Если проба падает, kubelet убивает контейнер и запускает его заново согласно политике рестарта (restartPolicy).
   • Когда использовать: Для восстановления из "зависших" состояний, когда процесс работает, но приложение не функционирует (например, deadlock).

     livenessProbe:
     httpGet:
     path: /healthz
     port: 8080
     httpHeaders:
     - name: Custom-Header
       value: "Liveness-Check"
     initialDelaySeconds: 30  # Даем приложению время на старт
     periodSeconds: 10
     failureThreshold: 3

2. Readiness Probe (Проба готовности):

   • Назначение: Определяет, готов ли контейнер принимать входящий трафик. Поды с непройденной пробой исключаются из эндпоинтов Service.
   • Когда использовать: Когда приложению нужно время для подготовки (загрузка кэша, подключение к БД) после запуска или во время временной неработоспособности.

     readinessProbe:
     exec:
     command:
     - /bin/sh
     - -c
     - test -f /tmp/ready  # Проверка наличия файла, который создается после инициализации
     initialDelaySeconds: 5
     periodSeconds: 5

3. Startup Probe (Проба старта):

   • Назначение: Для медленно стартующих приложений (например, legacy Java-приложений). Пока проба старта не станет успешной, остальные пробы (liveness/readiness) отключены.
   • Когда использовать: Чтобы избежать ложных перезапусков liveness-пробой на этапе долгого старта.

     startupProbe:
     httpGet:
     path: /healthz
     port: 8080
     failureThreshold: 30  # Позволяем проверять до 30 раз
     periodSeconds: 10     # с интервалом 10 секунд (итого 5 минут на старт)

Ключевые практики:

• Эндпоинты проб должны быть легковесными и не требовать аутентификации.
• initialDelaySeconds и failureThreshold должны быть адекватны времени запуска и "хрупкости" приложения.
• Пробы readiness и liveness должны проверять разные аспекты: readiness — доступность зависимостей, liveness — общую работоспособность бизнес-логики.