Так что у меня очень уникальная ситуация. Проблема Правила маршрутизации виртуальных сервисов не применяются. У нас есть настройка buzzfeed sso в нашем кластере. Мы хотим изменить заголовки ответа, т.е. добавить заголовок. к каждому запросу, который соответствует URI Sign_in. Buzzfeed sso имеет свое собственное пространство имен. Теперь, чтобы выполнить это, я создал виртуальный сервис. Шаги для воспроизведения : Мы использовали эту виртуальную службу spe c для создания правил маршрута.
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: sso-auth-injector
spec:
hosts:
- sso-auth
http:
- match:
- uri:
prefix: /sign_in
ignoreUriCase: true
route:
- destination:
host: sso-auth
headers:
response:
add:
foo: bar
request:
add:
hello: world
Анализ
Istioctk x description имеет выход Pod: sso-auth-58744b56cd-lwqrh.sso Порты: 4180 (sso -auth), 15090 (istio-proxy) Предложение: добавить ярлык «app» в модуль для телеметрии Istio. Предложение: добавьте метку «версия» в модуль для телеметрии Istio. Служба: sso-auth.sso Порт: http 80 / HTTP предназначен для порта pod 4180. Порт является РАЗРЕШЕННЫМ (обеспечивает HTTP / mTLS), и клиенты говорят по HTTP. VirtualService: sso-auth-injector.sso / sign_in uncased 2) Istioctl. Не для всех правил, но для исходящих | 80 |
"routes": [
{
"match": {
"prefix": "/sign_in",
"caseSensitive": false
},
"route": {
"cluster": "outbound|80||sso-auth.sso.svc.cluster.local",
"timeout": "0s",
"retryPolicy": {
"retryOn": "connect-failure,refused-stream,unavailable,cancelled,resource-exhausted,retriable-status-codes",
"numRetries": 2,
"retryHostPredicate": [
{
"name": "envoy.retry_host_predicates.previous_hosts"
}
],
"hostSelectionRetryMaxAttempts": "5",
"retriableStatusCodes": [
503
]
},
"maxGrpcTimeout": "0s"
},
"metadata": {
"filterMetadata": {
"istio": {
"config": "/apis/networking/v1alpha3/namespaces/sso/virtual-service/sso-auth-injector"
}
}
},
"decorator": {
"operation": "sso-auth.sso.svc.cluster.local:80/sign_in*"
},
"typedPerFilterConfig": {
"mixer": {
"@type": "type.googleapis.com/istio.mixer.v1.config.client.ServiceConfig",
"disableCheckCalls": true,
"mixerAttributes": {
"attributes": {
"destination.service.host": {
"stringValue": "sso-auth.sso.svc.cluster.local"
},
"destination.service.name": {
"stringValue": "sso-auth"
},
"destination.service.namespace": {
"stringValue": "sso"
},
"destination.service.uid": {
"stringValue": "istio://sso/services/sso-auth"
}
}
},
"forwardAttributes": {
"attributes": {
"destination.service.host": {
"stringValue": "sso-auth.sso.svc.cluster.local"
},
"destination.service.name": {
"stringValue": "sso-auth"
},
"destination.service.namespace": {
"stringValue": "sso"
},
"destination.service.uid": {
"stringValue": "istio://sso/services/sso-auth"
}
}
}
}
},
"requestHeadersToAdd": [
{
"header": {
"key": "hello",
"value": "world"
},
"append": true
}
],
"responseHeadersToAdd": [
{
"header": {
"key": "foo",
"value": "bar"
},
"append": true
}
]
}
]
},
Проблемы / Вопросы
Эти правила не вступают в силу. Каждый запрос передается службе, но заголовки не изменяются. Не должны ли правила маршрута применяться к входящим запросам, а не к исходящим (как показано в сгенерированном конфиге).