Блог

Я понимаю, как настроить проверку готовности в kubernetes, но есть ли какие-либо рекомендации относительно того, что микросервис должен проверять при вызове проверки готовности? Два конкретных примера:

1. Микросервис, который работает с БД, где без функционирующего подключения к БД практически вся функциональность не будет работать. Здесь я думаю, что было бы разумно выполнить пинг БД, не выполнив проверку готовности в случае сбоя пинга. Рекомендуется ли это?
2. Микросервис, который использует N других микросервисов, но при невозможности подключиться к любому из них все равно позволит работать большинству функций. Здесь я думаю, что проверять подключение к резервным службам не рекомендуется. В этом случае, при условии отсутствия обширной обработки «загрузки» или «прогрева», работоспособность и готовность эквивалентны. Правильно?

Спасибо

Нет, я не думаю, что существует наилучшая практика для проверки готовности.

Все зависит от приложения и того, что вы ожидаете.

Здесь я думаю, что было бы разумно выполнить пинг БД, не выполнив проверку готовности в случае сбоя пинга

Я попытаюсь прокомментировать это. Давайте представим, что у вас есть какой-то внутренний микросервис (развертывание с серверными репликами), и он взаимодействует с базой данных. Когда БД выходит из строя (при условии отсутствия репликации или серьезного простоя БД), проверки готовности ваших реплик модулей начинают давать сбой, а конечные точки модулей удаляются из службы. Теперь, когда клиент пытается получить доступ к службе, это приведет к тайм-ауту соединения, потому что нет службы для обработки запроса.

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

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

[…] но там, где невозможность подключения к какому-либо из них все равно позволит работать большинству функций. Здесь я думаю, что проверять подключение к резервным службам не рекомендуется. В этом случае, при условии отсутствия обширной обработки «загрузки» или «прогрева», работоспособность и готовность эквивалентны.

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

Итак, для меня liveness probe отвечает на вопрос: «Это приложение все еще работает?» И readines proble отвечает на вопрос: «Готово ли это приложение обрабатывать / способно ли обрабатывать трафик?»

И вам решать, что значит «все еще работать» и «иметь возможность обрабатывать трафик».

Но обычно, если приложение запущено, оно также способно обрабатывать трафик, поэтому в этом случае работоспособность и готовность равны.