Прокси-сервер с коляской посланника

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

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

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

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


person RamPrakash    schedule 16.04.2020    source источник


Ответы (1)


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

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

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

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

Зайдите в модуль приложения и посмотрите настроенные iptables. Я собираюсь показать пример с использованием nsenter. Кроме того, вы можете войти в контейнер в привилегированном режиме, чтобы увидеть ту же информацию. Для людей, не имеющих доступа к узлам, более практично использовать exec для входа в сопроводительный файл и запуск 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

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

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

https://istio.io/blog/2019/data-plane-setup/#traffic-flow-from-application-container-to-sidecar-proxy

person Arghya Sadhu    schedule 16.04.2020