You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jun 14, 2018. It is now read-only.
Ingress controllers like Nginx use the pod IP instead of service IP. In such a case, Envoy drops the incoming request as the host headers no longer match. Currently the proxy config generator creates virtual hosts only for all variations of service name and the service cluster IP. It needs to take the local pod IP into account as well.
cc @kyessenov
The text was updated successfully, but these errors were encountered:
Is it important to support pod IPs directly? There's a lot more churn in the pod registry, to the point we add this now, Envoy will be constantly restarting.
Its inbound.. from an ingress controller. Just to be able to match the pod's local IP, when its present in the host field.
I don't think we need to restart at all.
I'm hitting this as well when testing the envoy-based ingress controller in #71.
I'm assigning this to myself as I plan to work on it on Sunday (yes it's a working day in here...).
If anyone else wanna give it a go before, that's fine too.
Ingress controllers like Nginx use the pod IP instead of service IP. In such a case, Envoy drops the incoming request as the host headers no longer match. Currently the proxy config generator creates virtual hosts only for all variations of service name and the service cluster IP. It needs to take the local pod IP into account as well.
cc @kyessenov
The text was updated successfully, but these errors were encountered: