I am facing an issue in 1.1 (pre-1.1.3, though) when the sidecar seems to block all downstream connections on port 8080 an other ports used for services in istio-system. I undertsand that this is expected for external service requests, but it is happening for all requests (e.g. request to http://my-svc.my-namespace:8080/foo/bar returns 404).
Could you please explain how to prevent the blocking? For simplicity I am testing with my-svc being a regular kubernetes service (not a virtual service). Is the only option (besides upgrade to 1.1.3+) avoiding ports 80, 443, 3000, 8060, 8080, 9091, 150xx, 15433 and maybe some others I’ve missed? How does it come that other ports (elasticsearch, jaeger) are not blocked?
I have found the issue - it was not related to blocking of ports, but the Envoy’s inability to handle absolute-form in path; It did requests like GET http://my-svc:8080/foo/bar HTTP/1.1 but Envoy can handle only GET /foo/bar HTTP/1.1. The absolute form returns 404 Not Found without any error/warning logs.
Regrettably this is not the complete end of my trouble. While 8080 works, I can’t get the traffic shifting right - I have some routing rules based on header defined in the virtualservice but these are not honored. The same rules are applied when the call goes through ingressgateway (calling curl my-svc.istio.127.0.0.1.nip.io) but not in when the service calls curl my-svc:8080.
@frankbu Thanks a million, that was it! How does it come I can’t see a reference to the mesh gateway anywhere in the examples? I had no idea there’s such gateway, since it’s not defined explicitly as a kubernetes resource…
Actually I found one reference to it in bookinfo-rulehere, but that’s not much.
EDIT: ok, I’ve found another reference in the troubleshooting guide. Still, I thing it would be worth emphasise (I guess the mesh is the default gateway when gateways are not defined).