kiali показывает неизвестный трафик через отправку через посла

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

Используемый код для развертывания сервиса Ambassador:

apiVersion: v1
kind: Service
metadata:
  name: ambassador
spec:
  type: LoadBalancer
  externalTrafficPolicy: Local
  ports:
    - name: ambassador-http
      port: 80
      targetPort: 8080
  selector:
    service: ambassador
---

Могу ли я что-нибудь добавить сюда, чтобы это стало возможным?

Спасибо

3 ответа

Да, это возможно, и вот подробное руководство для этого из документации Abmassador:


Получение посла, работающего с Istio

Заставить Ambassador работать с Istio несложно. В этом примере мы будем использовать bookinfo образец приложения от Istio.

  1. Установите Istio на Kubernetes, следуя инструкциям по умолчанию (без использования взаимной аутентификации TLS между сайдкарами)
  2. Затем установите образец приложения Bookinfo, следуя инструкциям.
  3. Убедитесь, что образец приложения работает должным образом.

По умолчанию приложение Bookinfo использует вход Istio. Чтобы использовать Амбассадор, нам необходимо:

  1. Установите Амбассадор.

Для начала вам нужно развернуть службу Ambassador ambassador-admin в своем кластере:

Для этого проще всего использовать файлы YAML, которые есть у нас в сети (хотя, конечно, вы можете загрузить их и использовать локально, если хотите!).

Во-первых, вам нужно проверить, включен ли в Kubernetes RBAC:

kubectl cluster-info dump --namespace kube-system | grep authorization-mode

Если вы видите что-то вроде --authorization-mode=Node,RBAC на выходе означает, что RBAC включен.

Если RBAC включен, вам нужно будет использовать:

kubectl apply -f https://getambassador.io/yaml/ambassador/ambassador-rbac.yaml

Без RBAC вы можете использовать:

kubectl apply -f https://getambassador.io/yaml/ambassador/ambassador-no-rbac.yaml

(Обратите внимание, что если вы планируете использовать взаимный TLS для связи между Ambassador и Istio/services в будущем, то порядок, в котором вы развертываете службу ambassador-admin и службу Ambassador LoadBalancer ниже, может потребоваться поменять местами)

Затем вы развернете службу посла, которая действует как точка входа в кластер через тип LoadBalancer. Создайте следующий YAML и поместите его в файл с именем ambassador-service.yaml.

---
apiVersion: getambassador.io/v1
kind: Mapping
metadata: 
  name: httpbin
spec:     
  prefix: /httpbin/
  service: httpbin.org
  host_rewrite: httpbin.org

Затем примените его к Kubernetes с помощью kubectl:

kubectl apply -f ambassador-service.yaml

YAML выше делает несколько вещей:

  • Он создает сервис Kubernetes для Ambassador типа LoadBalancer. Обратите внимание: если вы не развертываете среду, в которой LoadBalancer является поддерживаемым типом (например, MiniKube), вам необходимо изменить его на другой тип службы, например, NodePort.
  • Он создает тестовый маршрут, который будет направлять трафик из /httpbin/ публике httpbin.org Служба запросов и ответов HTTP (которая предоставляет полезную конечную точку, которую можно использовать для диагностических целей). В Ambassador аннотации Kubernetes (как показано выше) используются для настройки. Чаще всего вам нужно настроить маршруты как часть процесса развертывания службы, как показано в этом более сложном примере.

Вы можете увидеть, правильно ли работают две службы Ambassador (а также получить IP-адрес LoadBalancer, если он будет назначен через несколько минут), выполнив следующие команды:

$ kubectl get services
NAME               TYPE           CLUSTER-IP      EXTERNAL-IP      PORT(S)          AGE
ambassador         LoadBalancer   10.63.247.1     35.224.41.XX     8080:32171/TCP     11m
ambassador-admin   NodePort       10.63.250.17    <none>           8877:32107/TCP   12m
details            ClusterIP      10.63.241.224   <none>           9080/TCP         16m
kubernetes         ClusterIP      10.63.240.1     <none>           443/TCP          24m
productpage        ClusterIP      10.63.248.184   <none>           9080/TCP         16m
ratings            ClusterIP      10.63.255.72    <none>           9080/TCP         16m
reviews            ClusterIP      10.63.252.192   <none>           9080/TCP         16m

$ kubectl get pods
NAME                             READY     STATUS    RESTARTS   AGE
ambassador-2680035017-092rk      2/2       Running   0          13m
ambassador-2680035017-9mr97      2/2       Running   0          13m
ambassador-2680035017-thcpr      2/2       Running   0          13m
details-v1-3842766915-3bjwx      2/2       Running   0          17m
productpage-v1-449428215-dwf44   2/2       Running   0          16m
ratings-v1-555398331-80zts       2/2       Running   0          17m
reviews-v1-217127373-s3d91       2/2       Running   0          17m
reviews-v2-2104781143-2nxqf      2/2       Running   0          16m
reviews-v3-3240307257-xl1l6      2/2       Running   0          16m

Выше мы видим, что внешний IP-адрес, назначенный нашему LoadBalancer, равен 35.224.41.XX (XX используется для маскировки фактического значения), и что все поды-посланники работают (для обеспечения высокой доступности Ambassador полагается на Kubernetes, поэтому должно быть два небольшие поды, работающие на каждом узле кластера).

Вы можете проверить, правильно ли установлен Ambassador, используя тестовый путь к httpbin.org чтобы получить IP- адрес источника внешнего кластера, с которого был сделан запрос:

$ curl 35.224.41.XX/httpbin/ip
{
  "origin": "35.192.109.XX"
}

Если вы видите аналогичный ответ, значит, все работает отлично!

(Бонус: если вы хотите использовать немного волшебства awk для экспорта IP LoadBalancer в переменную AMBASSADOR_IP, то вы можете ввести export AMBASSADOR_IP=$(kubectl get services ambassador | tail -1 | awk '{ print $4 }')и использоватьcurl $AMBASSADOR_IP/httpbin/ip

  1. Теперь вы собираетесь модифицировать демонстрацию bookinfo. bookinfo.yaml manifest, чтобы включить необходимые аннотации Ambassador. Смотри ниже.
---
apiVersion: getambassador.io/v1
kind: Mapping
metadata: 
  name: productpage
spec:     
  prefix: /productpage/
  rewrite: /productpage
  service: productpage:9080
---
apiVersion: v1
kind: Service
metadata:
  name: productpage
  labels:
    app: productpage
spec:
  ports:
  - port: 9080
    name: http
  selector:
    app: productpage

Приведенная выше аннотация реализует сопоставление Ambassador из URI '/ productpage /' со службой страницы продукта Kubernetes, работающей на порту 9080 ('productpage:9080'). URI сопоставления "префикс" берется из контекста корня вашего сервиса Ambassador, который действует как входная точка (отображается извне через порт 80, потому что это LoadBalancer), например, "35.224.41.XX/productpage/ ".

Теперь вы можете применить этот манифест из корня репозитория Istio GitHub в вашей локальной файловой системе (позаботившись о том, чтобы обернуть приложение с помощью istioctl kube-inject):

kubectl apply -f <(istioctl kube-inject -f samples/bookinfo/kube/bookinfo.yaml)
  1. При желании удалите контроллер Ingress из bookinfo.yaml проявить, набрав kubectl delete ingress gateway.
  2. Протестируйте Ambassador, перейдя на IP-адрес Ambassador LoadBalancer, который вы настроили выше, например 35.192.109.XX/productpage/. Вы можете снова увидеть реальный IP-адрес посла, набрав kubectl get services ambassador.

Также согласно документации нет необходимости вводить капсулы Ambassador.

Весь трафик, поступающий от источника, не являющегося частью сервисной сети, будет отображаться как unknown.

Посмотрите, что Киали говорит о неизвестном: https://kiali.io/faq/graph/

Да, все это я уже настроил. Вот почему я упомянул об этом на прикрепленном изображении. Я взял это с панели инструментов kiali. Этим выводом я поделился с приложением bookinfo. Я развернул собственное приложение, и оно тоже работает нормально. Но я хочу сократить эту неизвестную вещь. Я использую кластер AWS EKS.

Замечание о посланнике: посол не должен иметь коляску Istio по двум причинам. Во-первых, это невозможно, поскольку запуск двух отдельных экземпляров Envoy приведет к конфликту из-за их сегмента общей памяти. Во-вторых, Ambassador в любом случае не должен быть в вашей сетке. Сетка отлично подходит для обработки маршрутизации трафика от сервиса к сервису, но, поскольку Ambassador является вашей входной точкой, он должен самостоятельно решать, к какой услуге маршрутизировать и как это делать. Попытки установить правила маршрутизации и Ambassador, и Istio были бы головной болью и не имели бы особого смысла.

Другие вопросы по тегам