Istio и (или против) Nginx Ingress Controller

Я нахожусь в пути тестирования Istio, и сейчас я собираюсь протестировать "канареечные" возможности маршрутизации трафика.

Для своего теста я создал небольшую сервисную сетку, состоящую из 5 микросервисов (serviceA, serviceB, serviceC, serviceD, serviceE). Каждый может звонить другим. Я просто прохожу такой путь, как A, E, C, B, B, D, и запрос следует по этому пути. Для вызова моей servicemesh извне кластера у меня есть Nginx Ingress Controller с правилом Ingress, указывающим на модуль serviceA.

Это нормально работает.

Проблема, с которой я столкнулся, касается переключения трафика с использованием настраиваемого сопоставления заголовков, например:

kind: VirtualService
metadata:
  name: ServiceA
  namespace: demo
  labels:
    app: demo
spec:
  hosts:
  - service-a
  http:
  - route:
    - destination:
        host: service-a
        subset: v1
  - match:
    - headers:
        x-internal-request:
          exact: true
    route:
    - destination:
        host: service-a
        subset: v2

Итак, здесь я хочу попытаться направить трафик на версию ServiceA v2, когда для настраиваемого заголовка x-internal-request установлено значение true.

Вопросы:

  • Чтобы использовать эту функцию, должны ли мои службы знать о x-internal-header и должны ли они передавать его следующей службе в запросе? Или им не нужно заниматься этим, потому что Istio делает всю работу за них?

  • Чтобы использовать эту функцию, нужно ли мне использовать контроллер входа Istio (со шлюзом Istio) вместо контроллера входа Nginx?

Сегодня я использую Nginx Ingress Controller для предоставления доступа к некоторым из моих сервисов. Мы выбрали Nginx, потому что у него есть такая функция, как «внешняя авторизация», которая экономит нам много работы, и если нам нужно вместо этого использовать контроллер Istio Ingress, я не уверен, что он предлагает те же функции, что и Nginx.

Возможно, я не вижу среднего пути

Спасибо за помощь


person Fred Mériot    schedule 10.08.2018    source источник


Ответы (1)


Istio предназначен для использования Envoy, развернутого на каждом модуле, в качестве sidecars для перехвата и прокси-трафика сетевого трафика между микросервисами в служебной сети.

Вы также можете управлять с помощью HTTP headers для запросов и ответов с помощью Envoy. Согласно официальной документации, пользовательские заголовки могут быть добавлены в запрос / ответ в следующем порядке: взвешенные заголовки уровня кластера, заголовки уровня маршрута, заголовки уровня виртуального хоста и, наконец, заголовки глобального уровня. Поскольку ваши Envoy прокси развернуты на каждом соответствующем сервисном Pod как sidecar, пользовательский HTTP header должен передаваться на каждый запрос или ответ.

Я бы рекомендовал использовать Istio Ingress Controller с его основным компонентом. Istio Gateway, который обычно используется для включения функций мониторинга и правил маршрутизации в Istio сервисах сетки.

На GitHub была открыта проблема с реализацией Nginx Ingress controller в сервисах сетки и проблема с маршрутизацией запросов.

person Nick_Kh    schedule 13.08.2018
comment
Спасибо за ответ. Сегодня мы используем ngress-контроллер NGINX с функцией внешней аутентификации. Вы знаете, есть ли в Istio такая функция? Возможно, можно использовать контроллер входа nginx в качестве фронтального шлюза с настраиваемой аутентификацией, а затем передать запрос внутреннему контроллеру входа istio? - person Fred Mériot; 16.08.2018
comment
Я не нашел решения для внешней аутентификации в Istio Ingress Controller на официальных страницах документации, поэтому вы можете попробовать использовать контроллер NGinx Ingress на передней стороне в качестве шлюза для службы Istio Ingress. - person Nick_Kh; 17.08.2018
comment
@ FredMériot, если вы все еще ищете ответ, мы используем те же функции Nginx, что и вы и Istio, в качестве нашей сервисной сетки. Теперь вам просто нужно добавить traffic.sidecar.istio.io/includeInboundPorts :, посмотрите вариант 1 здесь github.com/istio/istio/issues/7776#issuecomment-412197907 - person cbj; 10.12.2018