I checked the logs of istio-proxy sidecar containers in the api-service deployment pods and in the default istio-ingressgateway deployment. The path remains the same, unwritten from ingressgateway to my service. I expect requests to look something like:
Client: 'GET mysite.com/api/some-resource/123/'
||
||
VV
Ingressgateway: 'GET mysite.com/api/some-resource/123/'
||
||
VV
VirtualService: rewrite.uri: /
||
||
VV
api-service: 'GET mysite.com/some-resource/123/'
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: my-route-rules
spec:
hosts:
- mysite.com
gateways:
- istio-system/mysite-gateway
http:
- match:
- uri:
prefix: /api
rewrite:
uri: /
route:
- destination:
host: api-service.default.svc.cluster.local
port:
number: 7000
- route:
- destination:
host: web-experience.default.svc.cluster.local
port:
number: 9000
I've found that the redirect was actually working, but the envoy sidecar was not reflecting this in its logs the way I expected.
I inferred from the docs that the envoy sidecar would log the rewritten path (Look in the Description of the rewrite Field):
Rewrite will be performed before forwarding.
I checked the access logs for my web server running in my api-service deployment and found malformed requests: GET //some-resource/123/ (from /api/some-resource/123/).
Turns out the extra / (from rewrite.url: /) was causing 404 errors. A Github comment from an istio issue presented a fix: whitespace.
As the user warns, it's uncertain whether this behavior is intended.