Нужны ли нам внешние конечные точки для оркестрации микроуслуг

Question

У меня есть вопрос по поводу следующей архитектуры, я не смог найти четкого ответа в документации по Kubernetes, возможно, вы мне поможете.

У меня есть служба под названием «OrchestrationService», эта служба зависит от 3 других служб «ServiceA», «ServiceB», «ServiceC», чтобы выполнять свою работу.

Все эти службы имеют свои образы Docker и развернуты в Kubernetes.

Теперь «OrchestrationService» будет единственным, у которого будет контакт с внешним миром, поэтому у него определенно будет внешняя конечная точка, мой вопрос: потребуются ли «ServiceA», «ServiceB», «ServiceC» один или Kubernetes сделает эти сервисы доступными для 'OrchestrationService' через KubeProxy / LoadBalancer?

Спасибо за ответы

Answer 1

Не так, как внешние службы, такие как loadbalancer, но ваши службы A / B / C должны публиковать себя как службы внутри кластера, чтобы их могли использовать другие службы, такие как OrchestrationService.

Answer 2

Нет, вы предоставляете OrchestrationService только для общего пользования, а другие службы A / B / C должны быть кластерными службами. Вы создаете selector сервисы для A / B / C, чтобы OrchestrationService могла подключаться к сервисам A / B / C. OrchestrationService может быть определен как NodePort с фиксированным портом, или вы можете использовать вход для маршрутизации трафика на OrchestrationService.

Answer 3

Нет, вам не нужны внешние конечные точки для ServiceA, ServiceB и ServiceC.

Если эти модули работают успешно в зависимости от ваших ярлыков, вы можете получить к ним доступ в OrchestrationService. http://servicea/context_path

servicea в URL-адресе - метка в определенном сервисе для ServiceA