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.
Related
I have an Istio gateway, Istio VirtualService, and app deployed running as a service. The virtual service is deployed like so:
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: my-app-route
spec:
hosts:
- "*"
gateways:
- my-gateway
http:
- match:
- uri:
prefix: "/my-app"
route:
- destination:
host: my-app-service
port:
number: 8000
When I navigate to http://myurl.com/my-app I would expect to see a JSON response from the service it is pointing to, but I just get a 404. However if I remove the match and redeploy like so:
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: my-app-route
spec:
hosts:
- "*"
http:
- route:
- destination:
host: my-app-service
port:
number: 800
And then go to http://myurl.com/my-app I can see the expected JSON response. Any help?
I am using istio in knative. Since the client ip did not come, I activated the reverse-prox. I added envoyfilter. but I get "upstream connect error or disconnect/reset before headers. reset reason: connection termination" error in services on knative.
if it's not knative service I can access it.
virtualservice
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: test-entry-route
namespace: default
spec:
gateways:
- knative-serving/knative-ingress-gateway
hosts:
- "test.net"
http:
- match:
- uri:
prefix: /test/ #working
rewrite:
uri: /
route:
- destination:
host: user-api.test.svc.cluster.local
port:
number: 80
- match:
- uri:
prefix: /user/ #not working
route:
- destination:
host: istio-ingressgateway.istio-system.svc.cluster.local
port:
number: 80
weight: 100
rewrite:
authority: user-api.poker-test.k8s.test.net
uri: /
EnvoyFilter
apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
name: proxy-protocol
namespace: istio-system
spec:
configPatches:
- applyTo: LISTENER
patch:
operation: MERGE
value:
listener_filters:
- name: envoy.listener.proxy_protocol
- name: envoy.listener.tls_inspector
workloadSelector:
labels:
istio: ingressgateway
service load balancer
annotations:
service.beta.kubernetes.io/do-loadbalancer-enable-proxy-protocol: 'true'
externalTrafficPolicy: Local
Is there a way to remove x-envoy-peer-metadata or restrict the data that goes into this header? Looks like this is default behavior at egress level and it has sensitive information related to k8s and other backend components.
(Updated, needed two files)
This is how it possible to do it via istio
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
labels:
app.kubernetes.io/part-of: my-namespace
name: my-namespace-google-remove-header
namespace: my-namespace
spec:
hosts:
- www.google.com
http:
- route:
- destination:
host: www.google.com
headers:
request:
remove:
- x-forwarded-proto
- x-envoy-decorator-operation
- x-envoy-peer-metadata-id
- x-envoy-peer-metadata
Then a ServiceEntry for the mesh is also needed
Below you can change port to 443 and protocol HTTPS if you need that instead
apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
name: mesh-external-www-google-com
spec:
hosts:
- www.google.com
location: MESH_EXTERNAL
ports:
- number: 80
name: http
protocol: HTTP
resolution: NONE
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.
You will have request for (say /test ) , and that request has to be redirected to multiple services
kind of multitasking behavior
I tried below things , but it didn't work
- route:
- destination:
host: details
subset: v1
- destination:
host: preview
subset: v1
I have code for matching the test prefix and added only that part where actual redirection is happening.
In simpler way . I want to know , how to achieve fan out in istio
You haven't shared a full VirtualService manifest, however in the similar scenario I used the following configuration in order to distinguish HTTP requests to the same prefix path by applying specific custom headers:
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: reviews
spec:
hosts:
- example
gateways:
- example-gateway
http:
- match:
- headers:
test:
exact: details
- uri:
prefix: /test
route:
- destination:
host: details
subset: v1
- match:
- headers:
test:
exact: preview
- uri:
prefix: /test
route:
- destination:
host: preview
subset: v1
Of course don't forget to accomplish appropriate DestinationRule's
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: details
spec:
host: details
subsets:
- name: v1
labels:
version: v1
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: preview
spec:
host: preview
subsets:
- name: v1
labels:
version: v1
You can find more relevant information in the official Istio traffic management documentation.
Try to use mirror option in Istio https://istio.io/docs/tasks/traffic-management/mirroring/