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
Related
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
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
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.