SV
kind: VirtualService
...
spec:
hosts:
- reviews
http:
- match:
- headers:
end-user:
exact: jason
Size: a a a
2021 March 03
SV
SV
чек)
4
шото гугл странные ответы мне дает. неужли нельзя просто 302 сделать с истио? на внешний сервис
---
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: play-google-com-app
namespace: xxx
spec:
gateways:
- mkopa-gateway
hosts:
- '*'
http:
- match:
- uri:
exact: /app
redirect:
uri: /store/apps/details?id=xxx
authority: play.google.com
---
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
name: play-google-com-app
namespace: xxx
spec:
hosts:
- play.google.com
location: MESH_EXTERNAL
ports:
- number: 443
name: https
protocol: TLS
resolution: DNS
4
только это 301
4
но мне 301 и нужен
4
кто-то делал gzip через istio ingress?
apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
name: ingressgateway-gzip
namespace: istio-system
spec:
workloadSelector:
labels:
istio: ingressgateway
configPatches:
- applyTo: HTTP_FILTER
match:
context: GATEWAY
listener:
filterChain:
filter:
name: "envoy.http_connection_manager"
subFilter:
name: 'envoy.router'
patch:
operation: INSERT_BEFORE
value:
name: envoy.gzip
config:
remove_accept_encoding_header: true
compression_level: DEFAULT
2021 March 04
F
Filipp
Благодарю! Насколько я понимаю, Pilot стал частью Istiod с версии 1.17, поэтому анализировал логи Istiod (на remote-кластере istiod не содержит ошибок, а в Istiod'е main-кластере ошибка "Failed to authenticate client from 10.244.0.61:44694: Authenticator ClientCertAuthenticator: no verified chain is found; Authenticator KubeJWTAuthenticator: could not get cluster cluster2's kube client")
Далее история запутаннее, открыл с данной ошибкой тикет на гите, ответили что дело не в аутентификации, и предложили смотреть в сторону cni в кластере, искать ошибки взаимодействия kubelet с istio-proxy.
Поэтому я и решил в лоб спросить, мало ли ошибка встречается и решается проще? Спасибо за ответ, буду дальше копать.
Если вдруг появятся какие-то предположения с вашей стороны, буду благодарен 😊
Далее история запутаннее, открыл с данной ошибкой тикет на гите, ответили что дело не в аутентификации, и предложили смотреть в сторону cni в кластере, искать ошибки взаимодействия kubelet с istio-proxy.
Поэтому я и решил в лоб спросить, мало ли ошибка встречается и решается проще? Спасибо за ответ, буду дальше копать.
Если вдруг появятся какие-то предположения с вашей стороны, буду благодарен 😊
Есть хорошие новости по данному кейсу, ошибка была исправлена.
я генерировал секрет для обращения к api remote-кластера в соответствии с инструкцией. Но по умолчанию secret создается в пространстве имен default.
После создания секрета в пространстве имен istio-system ошибок вообще нет.
(использовал команду: istioctl x create-remote-secret --namespace istio-system).
Еще раз спасибо за помощь!
я генерировал секрет для обращения к api remote-кластера в соответствии с инструкцией. Но по умолчанию secret создается в пространстве имен default.
После создания секрета в пространстве имен istio-system ошибок вообще нет.
(использовал команду: istioctl x create-remote-secret --namespace istio-system).
Еще раз спасибо за помощь!
2021 March 05
4
это аррей, по идее* да
4
не работает?
4
тэкс, а кто-то делал udp на ыстыо?
4
энвой как я понимаю поддерживает udp прокси
4
Non-TCP based protocols, such as UDP, are not proxied. These protocols will continue to function as normal, without any interception by the Istio proxy but cannot be used in proxy-only components such as ingress or egress gateways.
4
вот эт не совсем понятно. т.е. я не могу терминировать udp на гейтвее?
DP
вот эт не совсем понятно. т.е. я не могу терминировать udp на гейтвее?
Звучит именно так
4
а шо можно тогда? :)
DP
а шо можно тогда? :)
Ничего, не пропустишь ты юдп через ингресс как я понимаю