Readiness и Liveness probes

Что такое probe

kubelet - компонент Kubernetes, который запускает контейнеры на узле и следит за их состоянием. Сам по себе kubelet не знает, что происходит внутри приложения. Контейнер запущен, главный процесс жив, но это ещё не значит, что приложение готово работать.

Бывает две проблемы. Приложение ещё прогревается, а трафик на него уже идёт, и пользователь получает ошибку. Или процесс жив, но завис, и запросы не обрабатываются.

probe - небольшая проверка, которую kubelet регулярно отправляет в контейнер. По её результату kubelet решает, готов ли контейнер и нужно ли его перезапускать. Probe бывает трёх типов: readinessProbe, livenessProbe, startupProbe.

Probe	На какой вопрос отвечает	Что при провале
readinessProbe	готов ли Pod принимать трафик	Service не шлёт в этот Pod запросы
livenessProbe	работает ли процесс по-настоящему	kubelet перезапускает контейнер
startupProbe	закончился ли долгий старт	две остальные ещё не запускаются

readinessProbe

readinessProbe отвечает на вопрос «готов ли Pod принимать трафик». Pod - наименьшая единица, которую запускает Kubernetes; внутри Pod работает один или несколько контейнеров.

Service - объект, который раздаёт сетевой трафик на группу Pod. Пока readinessProbe не вернула успех, Service не направляет запросы в этот Pod. Деплой уже завершён, но пользователь не видит ошибку, пока приложение прогревается.

livenessProbe

livenessProbe отвечает на вопрос «работает ли процесс по-настоящему». Если probe не проходит несколько раз подряд, kubelet перезапускает контейнер. Это помогает против зависаний: главный процесс жив, а обработка запросов встала.

С livenessProbe легко навредить. Она не должна зависеть от внешних сервисов вроде базы данных. Если внешний сервис упадёт, liveness начнёт перезапускать контейнер без причины.

startupProbe

startupProbe нужна приложениям с очень долгим стартом: минута и больше. Пока startupProbe не прошла, liveness и readiness не запускаются. Это спасает медленные приложения от перезапуска во время прогрева. Если приложение стартует за несколько секунд, startupProbe не нужна.

Минимальный YAML

readinessProbe:
  httpGet:
    path: /
    port: 80
  initialDelaySeconds: 5
  periodSeconds: 10
livenessProbe:
  httpGet:
    path: /
    port: 80
  initialDelaySeconds: 5
  periodSeconds: 10

Разбор полей.

• httpGet - тип probe. kubelet делает HTTP-запрос по указанным path и port. Ответ 200-399 считается успехом.
• initialDelaySeconds - сколько секунд kubelet ждёт перед первой проверкой. Если поставить 0, probe начнёт стучать в ещё не открытый порт.
• periodSeconds - интервал между проверками в секундах. По умолчанию 10.

Эти поля относятся к контейнеру. В YAML они стоят внутри описания контейнера, рядом с image и name.

camelCase в ключах

Kubernetes принимает только ключи в camelCase. httpGet - правильно, httpget - нет. На опечатку в регистре kubectl apply ответит ошибкой strict decoding error: unknown field и не создаст объект (строгая валидация полей).

Что часто ломается

• liveness проверяет endpoint, который ходит в базу. База легла, и вместе с ней перезапустились все Pod приложения.

Как посмотреть поля и текущие значения

kubectl explain pod.spec.containers.readinessProbe
kubectl explain pod.spec.containers.readinessProbe.httpGet
kubectl get deploy app -o yaml | grep -A6 Probe
kubectl describe pod -l app=app | grep -A4 -E 'Readiness|Liveness'

Домашка

Теорию закрепляет задание на своём кластере: 2 шага с проверкой. Кластер поднимается по треку Kubernetes локально, задания лежат в репозитории k8s-practice.

./run.sh start k8s-readiness-liveness     # развернуть стартовое состояние
./run.sh verify k8s-readiness-liveness    # проверить текущий шаг

Коротко

• readinessProbe решает, пускать ли трафик из Service в этот Pod.
• livenessProbe решает, перезапускать ли контейнер, и не должна зависеть от внешних сервисов.
• startupProbe придерживает две остальные, пока медленное приложение прогревается.
• httpGet считает успехом коды 200-399; initialDelaySeconds задаёт паузу перед первой проверкой, periodSeconds - интервал.
• Probe описываются внутри контейнера, ключи строго camelCase, иначе kubectl apply отвергнет манифест.