Можно ли сделать так, чтобы все модули в наборе состояний Kubernetes не проходили через ReadinessProbes вместо одного? - PullRequest
0 голосов
/ 28 ноября 2018

У нас есть набор состояний для службы (история Druid), которая кэширует большое количество данных на локальных SSD.(Мы запускаем один модуль на узел в SSD, используя порты и сходство.) Когда нам нужно заменить базовые машины, это означает, что модули запускаются с пустыми локальными дисками, а затем им требуется некоторое время для заполнения кешей.В идеале нам нужно только выполнить плановую замену узлов (например, обновление пула узлов GKE) по одному узлу за раз и подождать, пока модуль нового узла полностью не заполнит кэш, прежде чем развернуть следующий узел.

ОК, так что это означает, что нам нужно установить PodDisruptionBudget равным 1, и настроить проверку готовности, чтобы новый узел не был готов, пока кэш не был заполнен.

Проблема в том, что система недействительно предлагает отличный способ задать нам вопрос: «pod X загрузил все необходимое для полной репликации системы».

То, что он задает, это «этовся система полностью реплицирована? ".

Таким образом, у нас возникает соблазн написать тест готовности, который говорит" не готов, если вся система полностью не реплицирована ".Но это означает, что во время обновлений пула узлов (или в других коротких случаях с краткими «не полностью реплицированными» состояниями) каждый модуль в наборе состояний будет не готов .

Мой вопрос: яна самом деле не понимаю полного значения каждой части k8, которая обращается к статусу Ready.Было бы плохо, если бы каждый модуль в SS становился не готовым, пока один модуль загружается?

Насколько я понимаю, готовность используется для таких вещей, как управление темпом развертывания развертывания или StatefulSet (который являетсяхорошо), и это также используется для того, чтобы Службы определяли, к каким модулям направлять.В этом случае мы фактически не используем Сервис, связанный с StatefulSet для маршрутизации (клиенты подключаются напрямую к отдельным модулям).Так что кажется, что на самом деле все может быть хорошоНо так ли это?Или есть другие приложения в состоянии «Готов», из-за которых нам было бы плохо помечать все модули как не готовые, пока глобальная репликация не достигает 100%?

1 Ответ

0 голосов
/ 19 июля 2019

Я не могу ответить на ваши вопросы об общих последствиях проверки готовности к Kubernetes, но я знаю, что ваше заявление (Друид) довольно хорошо.

Я полагаю, что ваше предположение неверно.Вы говорите, что нет способа запросить у отдельного исторического узла его статус относительно загрузки сегментов из глубокого хранилища, но на самом деле есть такой API:

/druid/historical/v1/readiness, а также связанный /druid/historical/v1/loadstatus

как указано здесь: https://druid.apache.org/docs/latest/operations/api-reference.html

...