#kubernetes #openshift #istio
#kubernetes #openshift #istio
Вопрос:
У меня возникли проблемы с пониманием того, какой трафик контролируется входными и выходными шлюзами istio.
- Например, приложение настраивает слушателей в очереди MQ. Это пример входящего или исходящего трафика? Я думал, что там, где приложение инициирует соединение, тогда этот трафик будет направлен на выходной шлюз. И наоборот, если приложение является конечной точкой, то трафик должен маршрутизироваться через входной шлюз.
- Допустим, приложение A является внешней службой для приложения B. Приложение A выполняет запрос rest для B. Должен ли этот запрос перенаправляться через ingress? Теперь приложение B выполняет запрос rest к A. Должен ли трафик проходить через выход сейчас?
Комментарии:
1. Это полностью зависит от того, как установлены TCP-соединения. Если приложение A инициирует соединение с B, оно будет перенаправлено через выход, предполагая, что правила виртуальных служб / шлюза / назначения были настроены как таковые. Наоборот, B -> A будет проходить через входной ресурс в вашу коляску и проксироваться. Я полагаю, что поведение по умолчанию, предполагающее, что Envoy включен в вашем модуле. Трафик будет направляться с выхода и через вход.
2. чтобы убедиться: 1) приложение A, развернутое в openshift, приложение B работает вне кластера openshift. Поэтому, если приложение A инициирует соединение (например, отправляет post-запрос на ‘ ServerB / test’ ) с B, этот запрос должен быть направлен через входные шлюзы. 2) приложение A подключается к внешнему серверу базы данных (не в кластере openshift) через выходные шлюзы?
3. @pwflamy 1) правильно, 2) не совсем, AFAIK это проходит через кластер, как упоминалось здесь , но вы можете включить выход и отправлять исходящий трафик через него, если хотите, взгляните сюда , это должно вам все объяснить.
4. @Jakub подождите, что значит «инициировать соединение»? Если мы запустим command
[appA]: curl appB, означает ли это, что appA инициирует соединение с AppB? Я спрашиваю, потому что, если вы последуете своему ответу ниже, окажется, что мой первый пример в комментарии неверен. Или я не правильно понимаю «инициировать соединение» (посмотрите, что в моем комментарии appA находится внутри сервисной сетки, а AppB — внешняя служба)5. @pwflamy извините, я неправильно понял второй вопрос, и хотя appA является внешним, а AppB находится внутри сетки. Как упоминалось ниже в моем примере, appA — это внешний сервис за пределами сетки, а AppB — это внедренный сервис в сетку istio.
Ответ №1:
Давайте начнем с некоторой теории. Я нашел несколько источников, в которых описывается, как работают входные и выходные шлюзы istio.
Документация Istio
Istio использует входные и выходные шлюзы для настройки балансировщиков нагрузки, выполняющихся на границе сервисной сетки. Входной шлюз позволяет определять точки входа в сетку, через которую проходит весь входящий трафик. Выходной шлюз — это симметричная концепция; он определяет точки выхода из сетки. Выходные шлюзы позволяют применять функции Istio, например, мониторинг и правила маршрутизации, к трафику, выходящему из сетки.
Istio в книге действий
Чтобы наши приложения и службы могли предоставлять что-либо значимое, им необходимо взаимодействовать с приложениями, которые находятся за пределами нашего кластера. Это могут быть существующие монолитные приложения, готовое программное обеспечение, очереди обмена сообщениями, базы данных и системы сторонних партнеров. Для этого операторам необходимо настроить Istio так, чтобы разрешать трафик в кластер, и быть очень конкретными в отношении того, какому трафику разрешено покидать кластер. Компонентами Istio, которые обеспечивают эту функциональность, являются istio-ingressgateway и istio-egressgateway.
И вот картинка, которая хорошо это показывает
Banzaicloud
Входной шлюз служит точкой входа для всех служб, работающих в сети.
выходные шлюзы — это точки выхода из сетки, которые позволяют нам применять функции Istio. Это включает в себя применение таких функций, как мониторинг и правила маршрутизации, к трафику, который выходит из сетки.
По поводу ваших вопросов
Например, приложение настраивает слушателей в очереди MQ. Это пример входящего или исходящего трафика? Я думал, что там, где приложение инициирует соединение, тогда этот трафик будет направлен на выходной шлюз. И наоборот, если приложение является конечной точкой, то трафик должен маршрутизироваться через входной шлюз.
Я не знаком с очередями сообщений, но, основываясь на приведенном выше рисунке, давайте предположим, что потребители находятся внутри сетки, поэтому службам производителей придется обращаться туда через входной шлюз.
[Служба производителя] -> входной шлюз -> [коляска посланника -> Служба потребителя]
Итак, да, трафик должен маршрутизироваться через входной шлюз
Допустим, приложение A является внешней службой для приложения B. Приложение A выполняет запрос rest для B. Должен ли этот запрос перенаправляться через ingress? Теперь приложение B выполняет запрос rest к A. Должен ли трафик проходить через выход сейчас?
Если служба внутри сервисной сетки хочет взаимодействовать с внешней службой, мы должны начать с настройки для нее выхода и входа в службу.
Поскольку весь исходящий трафик из модуля с поддержкой Istio по умолчанию перенаправляется на его вспомогательный прокси-сервер, доступность URL-адресов за пределами кластера зависит от конфигурации прокси-сервера. По умолчанию Istio настраивает прокси-сервер Envoy для передачи запросов к неизвестным службам. Хотя это обеспечивает удобный способ начать работу с Istio, обычно предпочтительнее настроить более строгий контроль.
Насколько мне известно, именно этого хотел бы трафик.
appA -> external service outside the mesh
appB -> injected service in the istio mesh
Предположим, вы хотите использовать curl из appA в AppB
[приложение A] (curl ingress-внешний ip / определенный путь или порт) -> входной шлюз -> [коляска посланника -> AppB]
Предположим, вы хотите использовать curl из AppB в appA
[AppB -> коляска посланника] (curl appA) -> выходной шлюз -> [appA]
Дайте мне знать в комментариях, если у вас есть еще какие-либо вопросы или вы хотите что-то обсудить.