Разрешение внутрикластерной связи с nginx в kubernetes

Question

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

Если API пытается связаться, скажем, с OSS-модулем, он будет взаимодействовать только с первым контейнером. Я хочу, чтобы API мог общаться со всеми тремя по кругу.

Как мне это сделать? Я понимаю, что мне понадобится Ingress Controller, например, nginx. Но есть ли какой-то реальный учебник, который ломает, как я могу достичь этого? Я не уверен и немного новичок в k8s. Любая помощь будет необходима!

Кстати, я работаю локально над миникубом.

Edit:

В процессе производства мы раскручиваем три копии каждого сервиса. Когда службе A необходимо обратиться к службе B, выбирается модуль B1 из службы B, который управляет любым полученным запросом. Однако этот модуль B1 становится единственным модулем из службы B, который обрабатывает любое сообщение; другими словами, стручкам B2 и B3 никогда не говорят. Я пытаюсь решить эту проблему с помощью nginx, потому что кажется, что нам нужен балансировщик нагрузки, чтобы помочь с этим, но я не уверен, как это сделать. Кто-нибудь может дать подробное объяснение того, что нужно сделать? В частности, как я могу настроить nginx с моими службами, чтобы все модули использовались в службе (каким-то образом), в отличие от того, что происходит сейчас, когда используется только один модуль? Это проблема, потому что в производстве один модуль перегружен запросами и умирает, когда у нас есть два других модуля, которые ничего не делают. Я локально развиваюсь на миникубе.

Answer 1

Упоминается очень простой пример того, как сбалансировать ваши бэкенд-модули с помощью сервиса Kubernetes здесь

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

kubectl run hello-world --replicas=2 --labels="run=load-balancer-example" --image=gcr.io/google-samples/node-hello:1.0  --port=8080

Делая это, kubernetes обеспечит равномерное распределение нагрузки между всеми вашими беговыми модулями.

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

kubectl get endpoints --all-namespaces

NAMESPACE     NAME                      ENDPOINTS                                                  AGE
kube-system   kube-dns                  10.244.0.96:53,10.244.0.97:53,10.244.0.96:53 + 1 more...   1d

Что ж, если вы действительно заинтересованы в настройке входа nginx, этот будет хорошим началом. Но простого LoadBalancer в сервисе kubernetes должно хватить для вашего текущего требования

Answer 2

Я предполагаю, что у вас есть микросервисная архитектура под вашими модулями, верно? Рассматривали ли вы вопрос об использовании Istio с Kubernetes? Он открыт и поставляется компаниями Google, IBM и Lyft. Намерение - предоставить разработчикам независимый от поставщиков способ (который, кажется, вам нужен) для подключения, защиты, управления и мониторинга сетей различных микросервисов на облачных платформах. (AWS, Azure, Google и т. Д.).

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

Это ссылка на документацию Istio , подробно объясняющая, как настроить мультикластерное окружение , что вы и ищете.

В документации есть примечание, которое я хотел бы выделить - оно может быть связано с вашей проблемой:

Поскольку модули Kubernetes не имеют стабильных IP-адресов, перезапустите любой Istio модуль обслуживания в кластере плоскости управления приведет к тому, что его конечная точка будет изменилось. Следовательно, любое соединение с удаленными кластерами конечная точка будет сломана. Это задокументировано в Istio выпуске # 4822 .

Там Есть несколько способов избежать или разрешить этот сценарий. это В разделе приведен общий обзор этих параметров.

• Обновление записей DNS
• Использовать тип сервиса балансировщика нагрузки
• Предоставление услуг Istio через шлюз

Я цитирую решение для балансировки нагрузки, так как оно, кажется, то, что вы хотите:

В Kubernetes вы можете объявить службу с типом службы как LoadBalancer. Простым решением проблемы перезапуска модуля является использование балансировщики нагрузки для сервисов Istio. Затем вы можете использовать нагрузку балансировочные IP-адреса в качестве конечных IP-адресов сервисов Istio для настройки удаленные кластеры.

Надеюсь, это поможет, и если у вас возникнут вопросы, стреляйте!