I am trying to understand if there is a way to avoid that while some pods (which have the injected sidecar) are in the Terminating phase, if Istio in the meantime is able to intercept any requests toward the service and avoid that those got propagated.
I mean, this is what I am observing:
My application is exposing some metrics on the /metrics endpoint (Prometheus integration).
Basicly while killing the pod, and while the pod is in the Terminating phase (graceful shutdown intercept from the application), I still see some request towards the endpoint, that’s why I see :
Apr 19 17:48:12 service-7589696bd7-5lv2d istio-proxy error failed scraping application metrics: error scraping http://localhost:3260/metrics: Get "http://localhost:3260/metrics": dial tcp [::1]:3260: connect: connection refused
I would expect that this should not happen, but I did not get why it is, so I assume that the sidecar did not realize that the other container is dying.
I would expect that those kind of request will be then discarded since the /endpoint is not valid (service dying).
Is there any way for that?
Used istio version: 1.17.1
Client Version: v1.23.3
Server Version: v1.25.8