Istio Destination Rule has an order? - istio

- route:
- destination:
host: A
subset: v1
port:
number: 80
match:
- uri:
exact: /articles
- uri:
regex: \/articles
- route:
- destination:
host: B
subset: v1
port:
number: 80
match:
- uri:
exact: /articles
- uri:
regex: \/articles
Say I have something like this, which rules will be applied for /articles as all the match will be hit?

That is not a destination rule but a VirtualService. Matching occurs in order.

Related

cookie-based virtual service routing does not work

We followed the instructions in the Istio Rules Configuration docs to setup routing rule based on a cookie.
There is the actual istio virtual service configuration:
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
annotations:
meta.helm.sh/release-name: prodstagingistio
meta.helm.sh/release-namespace: istio-system
creationTimestamp: "2022-07-14T16:12:56Z"
generation: 22
labels:
app.kubernetes.io/managed-by: Helm
name: api-gateway-virtualservice
namespace: istio-system
resourceVersion: "149056406"
uid: a5be0a58-6fd8-467c-9a98-5de9ac71b1dd
spec:
gateways:
- api-gateway
hosts:
- api0-prod.dev.domain.com
- api0-staging.dev.domain.com
http:
- match:
- authority:
exact: api0-prod.dev.domain.com
headers:
cookie:
regex: ^(.*;.)?(feature-b=true)(;.*)?$
route:
- destination:
host: api-gateway.blue.svc.cluster.local
- match:
- authority:
exact: api0-prod.dev.domain.com
route:
- destination:
host: api-gateway.green.svc.cluster.local
- match:
- authority:
exact: api0-staging.dev.domain.com
route:
- destination:
host: api-gateway.orange.svc.cluster.local
Supposedly, when accessing https://api0-prod.dev.domain.com with cookie value (feature-b=true) in http header, the traffic should be redirected to api-gateway.blue.svc.cluster.local. But regardless of the cookie setting, the traffic was sent to api-gateway.green.svc.cluster.local.
But I can't find anything wrong according to the document.
Can anything help taking a look of the config and see why the cookie setting doesn't work?
The virtual service routes should be like below to match cookie. Similarly you need to add for green.
http:
- match:
- headers:
cookie:
regex: ^(.*;.)?(feature-b=true)(;.*)?$
route:
- destination:
host: api-gateway.blue.svc.cluster.local
subset: blue-sub

istio: VirtualService url rewriting or forwarding

I have an Istio VirtualService with a match and a route and redirect url defined as follows:
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: my-pro
spec:
hosts:
- "*"
gateways:
- my-gateway
http:
- match:
- uri:
prefix: /events
route:
- destination:
host: event-service
port:
number: 8000
- match:
- uri:
prefix: /blog
redirect:
uri: /
authority: blog.mydomain.com
- route:
- destination:
host: default-service
port:
number: 8000
this VirtualService work as follows:
if the request is www.mydomain.com/events it will forward to event-service.
if the request is www.mydomain.com/blog it will redirect host to blog.mydomain.com.
if the request is www.mydomain.com/anyother it will forward to default-service.
In case no.2 I am redirecting www.mydomain.com/blog to blog.mydomain.com page because my blog page is hosted on that domain.
now my problem is while redirecting the URL, the browser URL is changing to blog.mydomain.com. I want it to remain the same www.mydomain.com/blog but the content of blog.mydomain.com should be display on the screen.
I think you should use rewrite with a destination : https://istio.io/latest/docs/reference/config/networking/virtual-service/#HTTPRewrite
If the destination is external to the Service Mesh, you'll also need a ServiceEntry
- match:
- uri:
prefix: /blog
name: blog.mydomain.com
rewrite:
authority: blog.mydomain.com
uri: /blog
route:
- destination:
host: blog.mydomain.com
Add the above rule in the virtual service, then create this service entry.
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
name: blog
spec:
hosts:
- blog.mydomain.com
location: MESH_EXTERNAL
ports:
- number: 80
name: http
protocol: HTTP
resolution: DNS

Retry not working for 5xx error in istio 1.4.3

Hi I have following virtual service configured for my test app.
I have configured the retires for 5xx .
But this is not working.
Instead of 3 times it retries only once.
kind: VirtualService
metadata:
name: test-app
spec:
gateways:
- test-app-gateway-public
- test-app-gateway-private
hosts:
- '*'
http:
- match:
- uri:
prefix: /api/test
retries:
attempts: 3
perTryTimeout: 1s
retryOn: 5xx
route:
- destination:
host: test-app
port:
number: 8080
weight: 100
timeout: 1000s

Istio queryParams always returning truthy

Set up istio and the basic bookinfo app
set up the virtual service as such:
one with headers:
kind: VirtualService
apiVersion: networking.istio.io/v1alpha3
metadata:
name: bookinfo
spec:
hosts:
- '*'
gateways:
- bookinfo-gateway
http:
- match:
- headers:
apiKey:
exact: test
rewrite:
uri: /productpage
route:
- destination:
host: productpage
port:
number: 9080
tcp: ~
tls: ~
and another with queryParams as the routing differentiator:
kind: VirtualService
apiVersion: networking.istio.io/v1alpha3
metadata:
name: bookinfo
spec:
hosts:
- '*'
gateways:
- bookinfo-gateway
http:
- match:
- headers:
apiKey:
exact: test
rewrite:
uri: /productpage
route:
- destination:
host: productpage
port:
number: 9080
tcp: ~
tls: ~
For some reason, the header policy seems to work fine. i.e if I dont submit the header=test, istio will return 404.
HOWEVER, for the queryParams, it is always returning thruthy. am I doing something wrong? or is this an istio related issue at its core.
(note: these 2 vs are not running in parallel, but rather an update from one to another, so it cant be some wonkyness with having 2 similar VS)
Ideally i would expect for the queryParam vs headers to act the same.
This was in fact a quasi-defect.
The docs for istio-1.2 was incorrectly stating feature that was found in 1.3.
For those of you in a similar situation, upgrading to istio 1.3.x should resolve it.

Why am I hitting the sane container with different prefix folders

Do you know why the following two istio yaml prefix configurations, is routed to the same container?
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: my-one-virtualservice
spec:
hosts:
- "*"
gateways:
- my-gateway
http:
- match:
- uri:
prefix: /one
route:
- destination:
host: my-one-service
The following is hitting the same container/service(just changed the prefix and host service):
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: my-two-virtualservice
spec:
hosts:
- "*"
gateways:
- my-gateway
http:
- match:
- uri:
prefix: /one/two
route:
- destination:
host: my-two-service
The problem is because you have 2 virtual services for the same host. In this case the rules will be merged in undefined order as described here.
In your case, since the second prefix is a more specific subset of the first, you need to make sure that the second rule has higher priority (i.e., is ordered first).
You can fix it by putting both rules into a single virtual service, like this:
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: my-one-virtualservice
spec:
hosts:
- "*"
gateways:
- my-gateway
http:
- match:
- uri:
prefix: /one/two
route:
- destination:
host: my-two-service
- match:
- uri:
prefix: /one
route:
- destination:
host: my-one-service
More information about rule ordering can be found here.