Kubernetes probe

Как работает проба:

Kubelet, который запущен как systemd агент на каждой ноде, запускает проверку к процессу внутри контейнера. Этот процесс опроса мы можем настраивать.

существуют пробы:

• startup - проверяет как запустилось, живо ли приложение и переключает сетевой трафик, после неё запускаются остальные пробы
• liveness - проверяет работает ли приложение, при failure происходит рестарт pod
• readiness - переключает сетевой трафик на pod, при failure перестаёт передавать трафик на pod

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

Так в spring boot framework, по умолчанию проверяются все зависимости, тут можно детальнее узнать как настроить:

https://www.callicoder.com/spring-boot-actuator/#displaying-detailed-health-information

для startup probe

• /health/startup - проверяет все внешние зависимости и выполнение основной функции приложения, а так же рабочее время ответа

// при невыполнении пробы, pod рестартует, трафик не подаётся на контейнер //

для liveness probe

• /health/live - проверка на длительном периоде выполнение основной функции приложения и рабочее время ответа

// при невыполнении пробы pod рестартует //

для readiness probe

• /health/ready - проверка внешних зависимостей, критичных для выполнения основной функции

// при невыполнении пробы, трафик не подаётся на pod //

Определения:

initialDelaySeconds - через сколько сек старт проверки проб // по умолчанию 0

periodSeconds - сек между попытками опроса // по умолчанию 10

timeoutSeconds - сколько сек ждём ответа от пробы // по умолчанию 1

failureThreshold - допустимое количество провальных попыток // по умолчанию 3

failureThreshold - сделать больше, чтобы максимально рано обнаружить запуск приложения;

periodSeconds - оставить по умолчанию, чтобы опрашивал часто;

timeoutSeconds - увеличить до 3 сек, (зависит от приложения)

initialDelaySeconds - можно не задавать, т к это фиксированное время до начало проверки, а мы делаем акцент на failureThreshold.

Отметим, что readiness и liveness пробы стартуют после startup пробы.

startupProbe:
  httpGet:
    path: /health/startup
    port: health-port
  failureThreshold: 30
  periodSeconds: 10
  timeoutSeconds: 3

надо понимать допустимую скорость ответа приложения - задать ее в timeoutSeconds, например 3 сек

желательно periodSeconds увеличить, в среднем ставить 30 сек

надо понимать, что через ~ 1,59 минуты, в случае проблем, приложение перезапустится

    livenessProbe:
      httpGet:
        path: /health/live
        port: health-port
      timeoutSeconds: 3
      periodSeconds: 30

Здесь можно реже опрашивать, т к тут логика проверки внешних зависимостей,

periodSeconds - 60 сек

failureThreshold - 2 попытки

timeoutSeconds - ставим больше, т к имеем дело с сетью для проверки внешних зависимостей, например 5 сек

так через 2 минуты недоступности внешних зависимостей, критичных для работы приложения, клиентский трафик перестанет приходить на pod.

    readinessProbe:
      httpGet:
        path: /health/ready
        port: health-port
      timeoutSeconds: 5
      periodSeconds: 60
      failureThreshold: 2

По умолчанию, пробы работают по HTTP и ожидают код ответа 2хх или 3хх,

если ответ 4хх или 5хх - увеличивается счётчик failureThreshold

так же, увеличить число тредов +2 к тому, что нужно самому приложению, чтобы гарантировать ответ на пробу.

Статусы проб:

• Success - все хорошо, exit code null или http 2xx - 3хх
• Failed - все плохо, exit code отличный от null или http 4xx - 5xx
• Unknown - не может запустить проверку или проблемы с сетью, или сам kubelet упал

Ваше приложение может НЕ работать с HTTP, тогда можно использовать TCP или альтернативные пробы и ожидать exit code null:

    livenessProbe:
      exec:
        command:
        - cat
        - /tmp/healthy
      initialDelaySeconds: 5
      periodSeconds: 5

Наиболее частые проблемы с пробами по:

• CPU
• latency (длительность ответа)
• Внешние зависимости