ОБНОВЛЕНИЕ: Это на самом деле будет исправлено в Istio 1.1, и приятно то, что вы можете легко применить патч самостоятельно, не дожидаясь 1.1, как это указано в конфигах yaml:
Ссылка на патч:https://github.com/istio/istio/pull/10480
Так что для Istio 1.0.x вам, в основном, нужно отредактировать пользовательский ресурс типа Rule
с именем promhttp
в пространстве имен istio-system
, чтобы установить следующее выражение match
:
match: (context.protocol == "http" || context.protocol == "grpc") && (match((request.useragent | "-"), "kube-probe*") == false)
Первоначальный ответ:
Я не уверен, есть ли для этого «чистое» решение, но в нижней части этой страницы документа описан обходной путь: https://istio.io/docs/tasks/traffic-management/app-health-check/#liveness-and-readiness-probes-with-http-request-option
Поскольку прокси-сервер Istio перехватывает только те порты, которые явно объявлены в поле containerPort, трафик на порт 8002 обходит прокси-сервер Istio независимо от того, включен ли взаимный TLS Istio.
Таким образом, вы можете настроить конечные точки работоспособности, используя другой порт, который вы не объявили бы как порты контейнера, и таким образом трафик не будет перехвачен прокси-посланником, следовательно, он выиграет 't генерировать телеметрию в Kiali.
Это не идеальное решение, поскольку оно заставляет вас определенным образом формировать ваше приложение для Istio ... но, тем не менее, оно работает.
[Редактировать,только что обнаружил: https://istio.io/help/faq/telemetry/#controlling-what-the-sidecar-reports.Похоже, вы также можете отфильтровать запросы от телеметрии на основе источника.Хотя я не уверен, сработает ли это в том случае, когда источник «неизвестен»]