Каковы наилучшие практики для API проверки работоспособности и зондов в среде Kubernetes для микросервисов?

Мы разрабатываем множество микросервисов. Все они работают в Kubernetes. Как оператору, мне нужно определить зонды для каждого микросервиса. Поэтому мы создадим API проверки работоспособности для каждого микросервиса. Каковы лучшие практики для этого API? Каковы лучшие практики для зондов? Нужно ли нам проверять только работоспособность службы или соединение с базой данных (и т. Д.)? Это избыточно? Базы данных тоже находятся в Kubernetes и тоже имеют свои собственные пробы. Можем ли мы просто использовать API / version в качестве проверки?

Я ищу отзывы и документацию. Спасибо.


kubernetes probe kubernetes-health-check microservices health-monitoring
person Antoine    schedule 22.10.2019    source источник

Ответы (2)


arrow_upward
2
arrow_downward

Аргумент для включения баз данных и других зависимостей нижестоящего в проверку работоспособности следующий:

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

Если бы вместо этого проверка работоспособности включала нисходящие зависимости, балансировщик нагрузки перестал бы направлять трафик на микросервис (и, надеюсь, покажет пользователю приятное сообщение об ошибке). Это дало бы базе данных время для восстановления после увеличения нагрузки (и время для реагирования на операции).

Поэтому я бы сказал, что использование базового /version - не лучшая идея.

person Blokje5    schedule 22.10.2019
comment
Спасибо, актуально. - person Antoine; 22.10.2019

arrow_upward
1
arrow_downward

Микрослужба обычно вызывает другие микросервисы / службы для получения данных, и есть вероятность, что нижележащая служба может быть недоступна. Вы можете использовать «Шаблон прерывателя цепи». Этот шаблон подходит для предотвращения попыток приложения вызвать удаленную службу или получить доступ к общему ресурсу, если эта операция с большой вероятностью завершится ошибкой.

Вы найдете шаблон в Шаблоны наблюдаемости (/ Проверка работоспособности) в микросервисах. У каждой службы должна быть конечная точка, которую можно использовать для проверки работоспособности приложения, например /health.1

person madhuka    schedule 22.10.2019
comment
Спасибо, посмотрю на эту выкройку! - person Antoine; 22.10.2019