Может ли модуль напрямую вызывать другой модуль? - PullRequest
Новая
       21

Может ли модуль напрямую вызывать другой модуль?

1 голос
/ 09 октября 2019

Если у меня есть 2 модуля, есть ли у них способ поговорить друг с другом без создания и использования какого-либо другого ресурса?

Вопрос касается обеих ситуаций - находятся ли они в одном пространстве имен или вразные.

Ответы [ 2 ]

2 голосов
/ 09 октября 2019

Да, они могут!

Если у вас нет сетевых политик, ограничивающих вызовы, ему просто нужно знать его DNS-имя, вот как это работает:

  • в кластере должен быть включен DNS
  • , если модули создаются вручную в одном и том же пространстве имен (не через развертывание), вам просто нужно вызвать имя модуля, который выступает в качестве хоста.
    • POD1 работает в пространстве имен NS1, открывая порт контейнера 31333
    • POD2 работает в пространстве имен NS1
    • POD2 вызывает POD1 через http://POD1:31333
  • если модули находятся в разных пространствах имен, вам необходимо включить пространство имен в хост.
    • POD1 работает в пространстве имен NS1, открывая порт контейнера 31333
    • POD2 работает в пространстве имен NS2
    • POD2 вызывает POD1 через http://POD1.NS1:31333
  • если модуль создается при развертывании, его имя является динамическим, его трудно предсказать, в этом случае вам нужна служба, которая предоставляет другие модули с помощью общего имени (службы)
    • DEPLOYMENT1, развернутый в пространстве имен NS1, создаст модуль со следующим форматом deployname-hash (пример: DEPLOYMENT1-f82hsh)
    • DEPLOYMENT1-f82hsh - это модуль, созданный развертыванием и работающий в пространстве имен NS1, созданный с использованием контейнерапорт 31333
    • POD2, работающий в пространстве имен NS2
    • POD2 может вызывать DEPLOYMENT1-f82hsh через http://DEPLOYMENT1 -f82hsh.NS1: 31333 , но поскольку имя динамическое, вв любое время он может измениться на что-то другое и сломать POD2
    • . Решение заключается в развертывании службы SVC1, которая перенаправляет запросы в модули DEPLOYMENT1
    • POD2, а затем вызывает http://SVC1:31333, который переадресует вызов DEPLOYMENT1-f82hsh или любой другой модуль, доступный в DEPLOYMENT1.

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

В более сложных сценариях вы также использовали бы суффикс dns кластера для вызова этих служб. Следующие документы описывают все более подробно https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/

1 голос
/ 09 октября 2019

Я бы ответил да на ваш вопрос ... Есть несколько вопросов, чтобы поговорить с сервисом, подобным тому, который дал вам ShreePrakash, и то же самое можно применить к стручку.

Вот еще один вопрос относительно: 2 Kubernetes pod общается, не зная выставленного адреса

Это отвечает на ваш вопрос, так как вы должны быть в состоянии сделать то же самое с PODNAME.PODNAMESPACE:PORT, и оно должно работать.

Теперь, почему это не сделано? Просто потому, что у pod есть случайный идентификатор, добавленный к их именам при создании (что-то вроде: nginx-ingress-1234456), и если он выходит из строя и получает заново, имя не будет таким же. Это относится к приложениям без сохранения состояния. Вы можете вывести имя модуля в состоянии с состоянием только с одним модулем ...

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

Надеюсь, это поможет.

...