Насколько я понимаю, вы пытаетесь расширить зонд готовности Kubernetes Pod, чтобы отразить работоспособность приложения для определенного c арендатора. К сожалению, датчик готовности не предназначен для этого.
Единственная цель датчика готовности Kubernetes (даже новая функция Pod Ready++) - отразить определенную способность модуля Pod обслуживать трафик c. Контроллеры Deployment и StatefulSet учитывают состояние готовности Pod в процессе непрерывного обновления.
Вы можете затормозить всю механику обновления, если установите датчик готовности на зависимость от внешних по отношению к компонентам Pod или подключения к конечным точкам сети. Правильный способ использования датчика готовности - проверка только состояния внутренних компонентов модуля.
Страницы документации Kubernetes:
Для некоторых простых приложений или микросервисов, которые содержат только один Pod, он может отражать также состояние приложения. Но обычно архитектура приложения намного сложнее и содержит много частей, каждая из которых может иметь зависимости.
Иногда дешевле и проще создать собственную проверку работоспособности l oop в приложении внешнего интерфейса (www.example.com/healthz), которая отражает все состояние работоспособности приложения, принимая во внимание все состояния его компонентов и их зависимости, или собирать и агрегировать JSON статусы от других компонентов.
В мире Kubernetes компонентами / приложениями обычно являются Сервисы, которые балансируют трафик c в одном или нескольких Бочках. Таким образом, компонент исправен, если хотя бы один модуль за соответствующей службой находится в состоянии готовности. Количество готовых модулей за службой говорит о производительности приложения больше, чем о работоспособности приложения.
Что касается моей способности представить дизайн вашего приложения:
- Я бы использовал несколько Ingress объекты, из-за которых трафик c направляется в выделенный для каждого клиентского интерфейса пользовательский интерфейс пространства имен арендатора . Все остальные ресурсы арендатора также размещены там.
- Все общие компоненты, которые я бы поместил в дополнительное пространство имен, скажем, «shared / static / commmon / stateless» и создали бы ExternalName в пространстве имен каждого арендатора для доступа к ним (или Ingress, если я будет обслуживать это содержимое по указанному c URL-пути).
- Я бы также развернул какое-нибудь решение для мониторинга приложений + кластера.
Таким образом, вы можете легко масштабировать части приложения, если некоторому арендатору требуется больше ресурсов.
Для управления развертыванием я бы используйте Схемы шлема . Таким образом, я могу легко развернуть еще одного арендатора или удалить / обновить существующего.
Существует множество различных решений для мониторинга работоспособности приложений, производительности, сбора метрик и журналов и выполнения действий при соблюдении определенных условий. Это лишь краткий список самых популярных решений:
PS: Если вы хотите внедрить автоматический выключатель для арендаторов, Istio имеет встроенную функциональность .