Можем ли мы отслеживать внешние вызовы API с помощью Istio за прокси через Kiali?

#kubernetes #istio #jaeger #kiali

#kubernetes #istio #егерь #kiali

Вопрос:

У нас есть микросервисы на основе Nodejs, работающие в нашем готовом kubernetes версии v1.19 с Istio версии v1.8.0. Чего я хотел бы добиться, так это отслеживать или отображать внешние вызовы API в Kiali, где у нас есть клиенты Jaeger для каждого микросервиса и возможность отслеживать внутренний трафик.

Но до сих пор я не мог отслеживать какие-либо внешние вызовы API, обращенные к каким-либо микросервисам.Единственное, что я вижу трафик для прокси в обзоре графика Kiali.

У нас есть прокси для совместной работы, и в каждом контейнере установлены env-прокси как для http_proxy, так и для https_proxy.Любая внешняя служба, доступная через прокси-сервер сотрудничества, поэтому трафик должен сначала проходить через наш прокси-сервер сотрудничества. У нас есть защищенный шлюз с TLS, и у нас нет выхода, где есть только istio-ingressgateway.

Так есть ли возможность отслеживать внешний трафик аналогично внутреннему трафику внутри кластера?Если да, чего может не хватать?

    $ kubectl get pods -n dev
    NAME                                     READY   STATUS    RESTARTS   AGE
    api-dev-74896ff4f9-slxt5                 3/3     Running   0          7h1m
    auth-dev-98f77d487-qt5zd                 3/3     Running   0          3d5h
    backend-dev-bb7765464-b7bpr              2/2     Running   0          7d3h
    mp-dev-86d6b8b978-slqp7                  3/3     Running   0          5d9h
    ui-dev-d5667946b-sdvlc                   2/2     Running   0          5d4h
 

Вот сервисные центры и виртуальные сервисы, которые я создал, где я хотел бы использовать функцию повтора, а также вызовы для proxy и externalAPI

 apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
  name: company-proxy
  namespace: dev
spec:
  hosts:
  - foo-proxy.net
  ports:
  - number: PORT
    name: tcp
    protocol: TCP
  location: MESH_EXTERNAL
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: proxy
  namespace: dev
spec:
  hosts:
    - "foo-proxy.net"
  http:
    - name: "company-proxy"
      match:
        - uri:
            prefix: "/"
      route:
        - destination:
            host: "foo-proxy.com"
      timeout: 90s
      retries:
        retryOn: "5xx"
        attempts: 3
        perTryTimeout: 30s
---
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
  name: foo-example.com
  namespace: dev
spec:
  hosts:
    - "foo-example.com"
  ports:
    - number: 80
      name: http
      protocol: HTTP
    - number: 443
      name: https
      protocol: HTTPS
  location: MESH_EXTERNAL
  resolution: DNS

---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: foo-example.com
  namespace: dev
spec:
  hosts:
    - "foo-example.com"
  http:
    - name: "developer-api"
      match:
        - uri:
            prefix: "/"
      route:
        - destination:
            host: "foo-example.com"
      timeout: 90s
      retries:
        retryOn: "5xx"
        attempts: 3
        perTryTimeout: 30s
 

Комментарии:

1. @suren с envoy / istio некоторые части выполняются автоматически (все входящие / исходящие HTTP-запросы), некоторые части все еще зависят от вас (распространение контекста в вашем приложении для «связывания» сгенерированного диапазона вместе)

2. @suren, у нас есть конечная точка клиента Jaeger в качестве переменной env для каждого микросервиса в нашем коде, а не kiali, где с помощью Istio мы можем отслеживать весь трафик между микросервисами, не добавляя ничего лишнего в код нашего приложения .. Но это недопустимо для внешних вызовов, которые, я полагаю, могут. Я полагаю, как упоминал Джоэл, нам нужен выходной шлюз

3. @suren, они обмениваются данными по http в k8s через прокси-сервер envoy через mTLS после того, как мы установили сервисную сетку с Istio. Не уверен, что вам действительно нужно дальше

4. @suren ну, я не добавлял никаких дополнительных вещей для отслеживания или егеря, поскольку я видел, что он уже предоставляет то, что я хочу с Istio для внутренних коммуникаций.. Итак, насколько я понимаю, мы можем управлять внешними вызовами API, не касаясь istio с помощью Jaeger, верно? И тогда мы сможем отслеживать их и в Kiali

5. @сурен, спасибо за ваш ответ.. Я попытаюсь сделать это сначала с помощью egressgateway и serviceEntry, если это не сработает, тогда нет другого выбора для этого без добавления дополнительного кода, как вы упомянули

Ответ №1:

Я не уверен, почему Istio автоматически не отслеживает ваши вызовы внешних API. Возможно, для этого требуется использовать выходной шлюз, я не уверен. Обратите также внимание, что Istio создает трассировки для http (ов) трафика, а не TCP.

Тем не менее, это то, что вы все еще можете сделать программно. Вы можете использовать любую из клиентских библиотек Jaeger, чтобы»дополнить»трассировки, уже созданные Envoy, добавив свои собственные промежутки.

Для этого вам нужно сначала извлечь контекст трассировки из HTTP-заголовков входящего запроса (при условии, что ваши внешние вызовы API являются последовательными для входящего запроса), а затем создать новый span в качестве дочернего элемента этого предыдущего контекста span. Хорошей идеей было бы использовать семантические соглашения OpenTracing, когда вы помечаете свой новый диапазон. Такие инструменты, как Kiali, смогут использовать некоторую информацию, если она соответствует этому соглашению.

Я нашел это сообщение в блоге, в котором объясняется, как это сделать с помощью клиента nodejs jaeger: https://rhonabwy.com/2019/01/06/adding-tracing-with-jaeger-to-an-express-application /