Посланник прокси коляска - PullRequest
Новая
       35

Посланник прокси коляска

0 голосов
/ 16 апреля 2020

Я пытаюсь понять поведение istio и посланника и как работает прокси!

Предположим, что я создал приложение, которое продолжает отправлять запрос в API поиска Google. Когда я развертываю это в своем кластере k8s с istio и посланником как контейнером с коляской, говорят, что все запросы маршрутизируются через контейнер с прокси / коляской.

Мой вопрос: и приложение, и прокси / коляска работают в одном модуле и используют один и тот же IP-адрес. Чтобы приложение отправляло запрос в sidecar, его следует изменить, чтобы оно отправляло запрос на локальный хост (ie на порт прокси-сервера), чтобы оно могло пересылать в Google. Но как исходящие запросы одного приложения перенаправляются в другое приложение. Где поддерживается эта конфигурация?

Может кто-нибудь, кто хорошо это понял, объяснит?

1 Ответ

1 голос
/ 16 апреля 2020

istio-init контейнер init используется для настройки правил iptables, чтобы входящий / исходящий трафик c проходил go через прокси-сервер коляской . Контейнер init отличается от контейнера приложения следующими способами:

Он запускается до запуска контейнера приложения и всегда завершается. Если имеется много контейнеров init, каждый из них должен успешно завершиться до запуска следующего контейнера.

Итак, вы можете увидеть, как этот тип контейнера идеально подходит для задания по настройке или инициализации, которое не нужно быть частью фактического контейнера приложения. В этом случае istio-init делает именно это и устанавливает правила iptables.

istio-proxy Это фактический прокси-сервер sidecar (на основе Envoy).

Войдите в модуль приложения и посмотрите на настроенные iptables. Я собираюсь показать пример, используя nsenter. Кроме того, вы можете ввести контейнер в привилегированном режиме, чтобы увидеть ту же информацию. Для людей, не имеющих доступа к узлам, использование exe c для входа в коляску и запуск iptables более практичны. 

$ docker inspect b8de099d3510 --format '{{ .State.Pid }}'
4125

$ nsenter -t 4215 -n iptables -t nat -S
-P PREROUTING ACCEPT
-P INPUT ACCEPT
-P OUTPUT ACCEPT
-P POSTROUTING ACCEPT
-N ISTIO_INBOUND
-N ISTIO_IN_REDIRECT
-N ISTIO_OUTPUT
-N ISTIO_REDIRECT
-A PREROUTING -p tcp -j ISTIO_INBOUND
-A OUTPUT -p tcp -j ISTIO_OUTPUT
-A ISTIO_INBOUND -p tcp -m tcp --dport 80 -j ISTIO_IN_REDIRECT
-A ISTIO_IN_REDIRECT -p tcp -j REDIRECT --to-ports 15001
-A ISTIO_OUTPUT ! -d 127.0.0.1/32 -o lo -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -m owner --uid-owner 1337 -j RETURN
-A ISTIO_OUTPUT -m owner --gid-owner 1337 -j RETURN
-A ISTIO_OUTPUT -d 127.0.0.1/32 -j RETURN
-A ISTIO_OUTPUT -j ISTIO_REDIRECT
-A ISTIO_REDIRECT -p tcp -j REDIRECT --to-ports 15001

Вывод выше ясно показывает, что все входящие трафики c на порт 80 , который является портом, который прослушивает приложение, теперь перенаправлен на порт 15001, который является портом, который прослушивает istio-proxy, прокси Envoy. То же самое относится и к исходящему трафику c.

Обновление: Вместо istio-init теперь, кажется, есть возможность использования нового CNI, что устраняет необходимость для контейнера init и связанных привилегий. Этот плагин istio-cni настраивает сетевое соединение модулей для выполнения этого требования вместо текущего подхода istio-init для pod-модулей Istio.

https://istio.io/blog/2019/data-plane-setup/#traffic -flow-from-application-container-to -sidecar-прокси

...