- PVSM.RU - https://www.pvsm.ru -
Прим. перев.: Ведущий инженер из компании Zalando — Henning Jacobs — не раз замечал у пользователей Kubernetes проблемы в понимании предназначения liveness (и readiness) probes и их корректного применения. Посему он собрал свои мысли в эту ёмкую заметку, которая со временем станет частью документации K8s.
Проверки состояния, известные в Kubernetes как liveness probes (т.е., дословно, «тесты на жизнеспособность» — прим. перев.), могут быть весьма опасными. Рекомендую по возможности избегать их: исключениями являются только случаи, когда они действительно необходимы и вы полностью осознаете специфику и последствия их использования. В этой публикации речь пойдет о liveness- и readiness-проверках, а также будет рассказано, в каких случаях стоит и не стоит их применять.
Мой коллега Sandor недавно поделился в Twitter'е самыми частыми ошибками, которые ему встречаются, в том числе связанными с использованием readiness/liveness probes:
Неправильно настроенная livenessProbe
может усугубить ситуации с высокой нагрузкой (лавинообразное отключение + потенциально долгий запуск контейнера/приложения) и привести к другим негативным последствиям вроде падения зависимостей (см. также мою недавнюю статью [2] об ограничении числа запросов в связке K3s+ACME). Еще хуже, когда liveness probe сочетается с проверкой здоровья зависимости (health check'ом), в роли которой выступает внешняя база данных: единственный сбой БД перезапустит все ваши контейнеры!
Общий посыл «Не используйте liveness probes» в данном случае помогает мало, поэтому рассмотрим, для чего предназначены readiness- и liveness-проверки.
Примечание: бόльшая часть приведенного ниже теста изначально была включена во внутреннюю документацию для разработчиков Zalando.
Kubernetes предоставляет два важных механизма, называемых liveness probes и readiness probes [3]. Они периодически выполняют некоторое действие — например, посылают HTTP-запрос, открывают TCP-соединение или выполняют команду в контейнере, — чтобы подтвердить, что приложение работает должным образом.
Kubernetes использует readiness probes, чтобы понять, когда контейнер готов принимать трафик. Pod считается готовым к работе, если все его контейнеры готовы. Одно из применений этого механизма состоит в том, чтобы контролировать, какие pod'ы используются в качестве бэкендов для сервисов Kubernetes (и особенно Ingress'а).
Liveness probes помогают Kubernetes понять, когда пришло время перезапустить контейнер. Например, подобная проверка позволяет перехватить deadlock, когда приложение «застревает» на одном месте. Перезапуск контейнера в таком состоянии помогает сдвинуть приложение с мертвой точки, несмотря на ошибки, при этом он же может привести к каскадным сбоям (см. ниже).
Если вы попытаетесь развернуть обновление приложения, которое проваливает проверки liveness/readiness, его выкатывание застопорится, поскольку Kubernetes будет ждать статуса Ready
от всех pod'ов.
Вот пример readiness probe, проверяющей путь /health
через HTTP с настройками по умолчанию (interval: 10 секунд, timeout: 1 секунда, success threshold: 1, failure threshold: 3):
# часть общего описания deployment'а/стека
podTemplate:
spec:
containers:
- name: my-container
# ...
readinessProbe:
httpGet:
path: /health
port: 8080
readinessProbe
, убедитесь, что endpoint возвращает ОК только в том случае, если основной HTTP-порт (вроде 8080) готов принимать трафик*;
* Мне известно по крайне мере об одном случае в Zalando, когда этого не произошло, то есть readinessProbe
проверила порт «management», но сам сервер так и не начал работать из-за проблем с загрузкой кэша.
* Также можно запускать миграции БД из init-контейнеров снаружи pod'а. Я по-прежнему являюсь поклонником самостоятельных (self-contained) приложений, то есть таких, в которых контейнер приложения без внешней координации знает, как привести БД в нужное состояние.
httpGet
для readiness-проверок через типичные endpoint'ы health check'ов (например, /health
).interval: 10s
, timeout: 1s
, successThreshold: 1
, failureThreshold: 3
):
startupProbe
, появившейся в версии 1.16 [5] (мы писали о ней на русском здесь [6] — прим. перев.).* Таково поведение по умолчанию Spring Data Redis (по крайней мере, оно было таким, когда я проверял в прошлый раз), что привело к «катастрофическому» сбою: когда на короткое время Redis оказался недоступен, все pod'ы «упали».
failureThreshold
), например, присваивать статус not-ready после 3 попыток и считать, что liveness probe провалился после 10 попыток;Об init-контейнерах для миграции БД [11]: добавлена сноска.
EJ напомнил мне [12] о PDB: одна из бед liveness-проверок — отсутствие координации между pod'ами. В Kubernetes есть Pod Disruption Budgets (PDB) [13] для ограничения числа параллельных сбоев, которое может испытывать приложение, однако проверки не учитывают PDB. В идеале мы можем приказать K8s: «Перезапусти один pod, если его проверка окажется неудачной, но не перезапускай их все, чтобы не сделать еще хуже».
Bryan отлично сформулировал [14]: «Используйте liveness-зондирование, когда точно знаете, что лучшее, что можно сделать, — это «убить» приложение» (опять же, увлекаться не стоит).
Автор: Андрей Сидоров
Источник [15]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/sistemnoe-administrirovanie/333243
Ссылки в тексте:
[1] Image: https://twitter.com/sszuecs/status/1175377157343907840
[2] мою недавнюю статью: https://srcco.de/posts/k3s-outage-traefik-acme-lets-encrypt-local-path.html
[3] liveness probes и readiness probes: https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/
[4] Flyway: https://flywaydb.org/
[5] появившейся в версии 1.16: https://sysdig.com/blog/whats-new-kubernetes-1-16/
[6] здесь: https://habr.com/ru/company/flant/blog/467477/
[7] выступление специалистов компании Datadog: https://www.youtube.com/watch?v=QKI-JRs2RIE
[8] Image: https://twitter.com/sszuecs/status/1175655221382529025
[9] Kubernetes Liveness and Readiness Probes Revisited: How to Avoid Shooting Yourself in the Other Foot: https://blog.colinbreck.com/kubernetes-liveness-and-readiness-probes-revisited-how-to-avoid-shooting-yourself-in-the-other-foot/
[10] NRE Labs Outage Post-Mortem: https://keepingitclassless.net/2018/12/december-4-nre-labs-outage-post-mortem/
[11] Об init-контейнерах для миграции БД: https://twitter.com/BarrWill1/status/1178144162526453760
[12] EJ напомнил мне: https://twitter.com/ejc3/status/1178077779293683713
[13] Pod Disruption Budgets (PDB): https://kubernetes.io/docs/tasks/run-application/configure-pdb/
[14] Bryan отлично сформулировал: https://twitter.com/bboreham/status/1178083887991398400
[15] Источник: https://habr.com/ru/post/470958/?utm_source=habrahabr&utm_medium=rss&utm_campaign=470958
Нажмите здесь для печати.