I have been using kubernetes for a couple of years, during which time I have used the Ingress mechanism, with the nginx IngressController to route traffic to workloads in my cluster. I illustrate that on the top of the digram below:
As shown, I route all traffic on 80/443 to the IngressController. I then use Ingress resources (namespace specific) to route based on hostname to the desired service. The Service resource takes it the ‘last mile’, so to speak, to an appropriate Pod.
From what I can tell, the lower part of the above diagram shows how Istio works, and what the correlation is between the Ingress approach and the Istio approach.
I guess my broad question is whether I have the correct understanding. Some more specific questions/observations:
- Does the Istio Ingress Gateway Pod, which I can see is based on Envoy, reconfigure itself based on Gateway resources in a similar way to how the nginx IngressController reconfigures itself based on new Ingress resources?
- The Ingress resource includes Service, Port, Path and other details that appears to be split between the Istion Gateway and VirtualService. Is this the right way of thinking about it?
- DestinationRules appear to work with the VirtualService to route to a specific Pod (e.g. by version label), but I’m not sure how the VirtualService manages the routing.
That last bullet is a bit of a puzzle, since I can’t figure out how VirtualService routes. Is there another proxy somewhere that I’m not seeing?