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.
- Установите Istio на Kubernetes, следуя инструкциям по умолчанию (без использования взаимной аутентификации TLS между сайдкарами)
- Затем установите образец приложения Bookinfo, следуя инструкциям.
- Убедитесь, что образец приложения работает должным образом.
По умолчанию приложение Bookinfo использует вход Istio. Чтобы использовать Амбассадор, нам необходимо:
- Установите Амбассадор.
Для начала вам нужно развернуть службу 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
- Теперь вы собираетесь модифицировать демонстрацию 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)
- При желании удалите контроллер Ingress из
bookinfo.yaml
проявить, набравkubectl delete ingress gateway
. - Протестируйте 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 были бы головной болью и не имели бы особого смысла.