TL;NR
Last time, we learned how does the traffic routing look like behind the K8S Ingress. In this one, we will continue our journey and take a close look at the traffic management in Istio, and particularly how Istio IngressGateway works to handle requests from the outside.
Istio in a nutshell
Istio is an open source service mesh that provides a uniform and more efficient way to secure, connect, and monitor microservices. It serves as an addition and alternative to the native K8S network stack such as Kube-proxy, Service and Ingress.
When it comes to traffic management, Istio offers a more fine-grained traffic routing configuration. Istio control plane queries virtualservice and DestinationRule, and generates Envoy config for each Envoy proxy that runs as a sidecar container inside your app pod.
Here is a diagram that illustrates the high level abstraction of Istio traffic management.
Istio control plane watches the rules that you define in IngressGateway, VirtualService and DestinationRule. As a result, the control plane outputs an Envoy config, and applies it to all the Envoy proxies in your cluster.
Istio IngressGateway
Istio has replaced the Ingress resource with new Gateway. Unlike Ingress, the Istio Gateway does not rely on K8S network stack to forwarding and routing external requests. Instead, Istio captures those requests, and applies its own routing rules to distribute the requests to the targeting pods.
So how does it work exactly? Again, here is a diagram, followed by a quick overview:
- A user makes a request to app.example.com
- The L4 load balancer listens on incoming requests and load balancing the request to the backend Istio Gateway service.
- The load balancer selects one working node and forwards the request to the NodeIP:NodePort exposed by the service
- Inside the cluster the request is routed to an Istio Gateway pod (managed by a deployment) using the native K8S network stack.
- The Istio gateway pod has an Envoy proxy container running inside. The proxy is configured by the Istio control plane with a set of routing rules that you define in VirtualService and DestinationRule
- The Istio gateway pod (Envoy proxy) looks up the K8S Endpoints object associated with the app service for the IP addresses of pods, and selects one of the pods to route the request to, based on its own load balancing mechanism
Conclusion
Istio is a replacement of native K8S network stack, and understanding its working mechanism is far from trivial. Hopefully this article has shed some lights on how it works in detail.
Here are some key takeaways:
- Istio makes its own implementations for traffic management including load balancing, service discovery and routing, without being tied to the native K8S network stack.
- The Istio traffic management works more or less the same way regardless of traffic outside or inside within the cluster. Basically it has a control plane for management and configuration, and uses Envoy proxy for traffic routing:
- The Envoy proxy runs along side your app container inside your pod. The proxy captures the HTTP/gRPC requests from the app container and changes the routing path
- To be more precious, the requests from the app container are captured by the pod iptables, and redirected to the envoy container
- In addition to capturing HTTP/gRPC traffic, Istio can also capture DNS requests. In this case, all DNS queries from application will be redirected to Enovy and resolved locally, without using the Kube-DNS