✔️ startupProbe правильный способ пережить долгий старт приложения
В прошлом посте мы разбирали, как увеличить окно терпения у livenessProbe и readinessProbe через failureThreshold × periodSeconds, чтобы Pod пережил долгую Liquibase/Alembic-миграцию и не ушёл в бесконечные рестарты.
Способ рабочий, но у него есть один недостаток 〰️ пока действует большое окно терпения, livenessProbe перестаёт быстро реагировать на реальные зависания приложения.
Если долгий старт 〰️ обычная история, для этого в Kubernetes уже есть штатный механизм 〰️ startupProbe.
✅ Как же он работает❓
Пока startupProbe ни разу не прошёл успешно, livenessProbe и readinessProbe вообще не выполняются.
Как только startupProbe успешно проходит первый раз, он больше никогда не запускается. Дальше контейнер работает с обычными значениями livenessProbe и readinessProbe.
startupProbe:
httpGet:
path: /actuator/health/liveness
port: 8080
periodSeconds: 5
failureThreshold: 720 # до 1 часа на миграцию
livenessProbe:
httpGet:
path: /actuator/health/liveness
port: 8080
periodSeconds: 5
failureThreshold: 3 # обычные рабочие значения
✅ Почему это лучше ❓
🔵 Не нужно временно увеличивать failureThreshold перед раскаткой, а потом вспоминать, что его нужно вернуть обратно.
🔵 После успешного запуска начинает работать обычный livenessProbe с небольшими значениями failureThreshold, поэтому реальные зависания приложения после старта обнаруживаются быстро, а не спустя часы.
🔵 По манифесту сразу видно, что это отдельное окно для долгого запуска приложения, а не случайно огромное значение failureThreshold, происхождение которого через полгода уже никто не вспомнит.
✅ Но что точно стоит проверить, чтоб не словить проблему❗️
🔵 Admission-политики 〰️ не SCC, а именно policy-engine
Если в кластере используются Kyverno или OPA Gatekeeper, могут существовать политики, запрещающие определённые настройки проб.
В этом случае новый манифест просто не применится. Старые Pod продолжат работать, а проблему сразу покажет kubectl rollout status.
🔵 Размер окна
Если приложение запускается дольше, чем рассчитано окно failureThreshold × periodSeconds
то kubelet посчитает контейнер зависшим и начнёт его перезапускать.
Поэтому окно лучше закладывать с запасом 〰️ примерно в 1,5–2 раза больше максимального времени запуска.
🔵 Стратегию раскатки
Само по себе добавление startupProbe не приводит к даунтайму.
При стандартной стратегии RollingUpdate и нескольких репликах старые Pod продолжают обслуживать трафик, пока новые не станут Ready.
Риск появляется при одной реплике, стратегии Recreate, агрессивных настройках maxUnavailable или других особенностях раскатки.
✅ Итог
Если долгий старт 〰️ разовая история, например, тяжёлая миграция перед релизом, временно увеличить окно терпения у livenessProbe вполне допустимо.
Если же приложение регулярно долго запускается, startupProbe 〰️ более правильное решение. Он отделяет этап запуска от контроля живости приложения, поэтому после успешного старта livenessProbe продолжает работать с обычными, небольшими значениями.
Именно для таких сценариев startupProbe и появился в Kubernetes.
#startupProbe #k8s #Liquibase #Alembic #DevOps
В прошлом посте мы разбирали, как увеличить окно терпения у livenessProbe и readinessProbe через failureThreshold × periodSeconds, чтобы Pod пережил долгую Liquibase/Alembic-миграцию и не ушёл в бесконечные рестарты.
Способ рабочий, но у него есть один недостаток 〰️ пока действует большое окно терпения, livenessProbe перестаёт быстро реагировать на реальные зависания приложения.
Если долгий старт 〰️ обычная история, для этого в Kubernetes уже есть штатный механизм 〰️ startupProbe.
✅ Как же он работает❓
Пока startupProbe ни разу не прошёл успешно, livenessProbe и readinessProbe вообще не выполняются.
Как только startupProbe успешно проходит первый раз, он больше никогда не запускается. Дальше контейнер работает с обычными значениями livenessProbe и readinessProbe.
startupProbe:
httpGet:
path: /actuator/health/liveness
port: 8080
periodSeconds: 5
failureThreshold: 720 # до 1 часа на миграцию
livenessProbe:
httpGet:
path: /actuator/health/liveness
port: 8080
periodSeconds: 5
failureThreshold: 3 # обычные рабочие значения
✅ Почему это лучше ❓
🔵 Не нужно временно увеличивать failureThreshold перед раскаткой, а потом вспоминать, что его нужно вернуть обратно.
🔵 После успешного запуска начинает работать обычный livenessProbe с небольшими значениями failureThreshold, поэтому реальные зависания приложения после старта обнаруживаются быстро, а не спустя часы.
🔵 По манифесту сразу видно, что это отдельное окно для долгого запуска приложения, а не случайно огромное значение failureThreshold, происхождение которого через полгода уже никто не вспомнит.
✅ Но что точно стоит проверить, чтоб не словить проблему❗️
🔵 Admission-политики 〰️ не SCC, а именно policy-engine
Если в кластере используются Kyverno или OPA Gatekeeper, могут существовать политики, запрещающие определённые настройки проб.
В этом случае новый манифест просто не применится. Старые Pod продолжат работать, а проблему сразу покажет kubectl rollout status.
🔵 Размер окна
Если приложение запускается дольше, чем рассчитано окно failureThreshold × periodSeconds
то kubelet посчитает контейнер зависшим и начнёт его перезапускать.
Поэтому окно лучше закладывать с запасом 〰️ примерно в 1,5–2 раза больше максимального времени запуска.
🔵 Стратегию раскатки
Само по себе добавление startupProbe не приводит к даунтайму.
При стандартной стратегии RollingUpdate и нескольких репликах старые Pod продолжают обслуживать трафик, пока новые не станут Ready.
Риск появляется при одной реплике, стратегии Recreate, агрессивных настройках maxUnavailable или других особенностях раскатки.
✅ Итог
Если долгий старт 〰️ разовая история, например, тяжёлая миграция перед релизом, временно увеличить окно терпения у livenessProbe вполне допустимо.
Если же приложение регулярно долго запускается, startupProbe 〰️ более правильное решение. Он отделяет этап запуска от контроля живости приложения, поэтому после успешного старта livenessProbe продолжает работать с обычными, небольшими значениями.
Именно для таких сценариев startupProbe и появился в Kubernetes.
#startupProbe #k8s #Liquibase #Alembic #DevOps