Istio: Могу ли я добавить случайно сгенерированное уникальное значение в качестве заголовка к каждому запросу, прежде чем он достигнет моего приложения

Question

У меня есть служба RESTful в приложении весенней загрузки. Это весеннее загрузочное приложение развернуто в cuser kubernetes, и у нас есть Istio как услуга me sh, прикрепленная к коляске каждого контейнера контейнера в кластере. Каждый запрос к моему сервису сначала попадает на сервис me sh, т. Е. Istio, а затем соответственно маршрутизируется.

Мне нужно поставить проверку заголовка запроса, и если этот заголовок отсутствует, случайным образом генерировать уникальное значение и установите его в качестве заголовка запроса. Я знаю, что есть Headers.HeaderOperations, который я могу использовать в правиле назначения, но как я могу генерировать уникальное значение каждый раз, когда отсутствует заголовок? Я не хочу писать логи c внутри моего приложения, так как это общее правило, применяемое ко всем приложениям внутри кластера

Answer 1

Есть важная информация, которую нужно сказать по этому предмету. И мне кажется, что вы пытаетесь найти обходной путь для приложений, которые не пересылают / распространяют заголовки в вашем кластере. Поэтому я собираюсь упомянуть несколько проблем, с которыми можно столкнуться с этим решением (на всякий случай).

Как уже упоминалось в ответе Юрия Г. Вы можете настроить уникальные x-request-id заголовки, но они не будут очень полезны с точки зрения трассировки, если запросы проходят через приложения, которые не распространяют эти x-request-id заголовки.

Это происходит потому, что при трассировке целых путей запроса должен быть уникальный x-request-id, хотя и весь его след. Если значение x-request-id отличается в разных частях пути, по которому идет запрос, как мы собираемся собрать весь путь трассировки?

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

В любом случае для приложений, которые поддерживают пересылку / распространение заголовков x-request-id, я предлагаю следующее руководство из istio документация.

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

Answer 2

Из прочтения документации istio и envoy кажется, что это не поддерживается istio / envoy из коробки. В качестве обходного пути у вас есть 2 варианта

Опция 1 : для установки заголовка x-envoy-force-trace в виртуальной службе

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: reviews-route
spec:
  hosts:
  - reviews.prod.svc.cluster.local
  http:
  - headers:
      request:
        set:
          x-envoy-force-trace: true

Будет сгенерирован заголовок x-request-id, если он отсутствует. Но это похоже на злоупотребление механизмом отслеживания.

Вариант 2: Для использования consistentHash балансировки на основе заголовка, например:

 apiVersion: networking.istio.io/v1alpha3
 kind: DestinationRule
 metadata:
   name: bookinfo-ratings
 spec:
   host: ratings.prod.svc.cluster.local
   trafficPolicy:
     loadBalancer:
       consistentHash:
         httpHeaderName:
           name: x-custom-request-id 

Будет создан заголовок x-custom-request-id для любого запроса, который не ' У этого заголовка нет. В этом случае запросы с одинаковым значением x-custom-request-id всегда будут go к одному и тому же модулю, что может вызвать неравномерную балансировку.