Istio, an open platform to connect, manage, monitor, and secure microservices, was launched on May 24, 2017 with a joint announcement by IBM, Google, and Lyft. I had been watching the Istio project closely since the beginning of the year and I am now very excited to have started working full-time on Istio very recently.
If you’re not familiar with Istio, I highly recommend you to read the Istio Architecture Overview. One thing that always fascinates me is that developers doesn’t have to modify their microservice applications to work with Istio. As developers run their microservice applications with Istio, they immediately gain the many benefits that come with Istio, such as mutual TLS (mTLS) between microservices, traffic management, policy enforcement, telemetry and many more. The abstraction provided by Envoy and Istio as the service mesh control plane makes it possible for developers to focus on just the microservices themselves.
What I have always been curious about is how network traffic is routed when I examine my microservices deployed in Istio. How does the Istio ingress controller or Envoy side car know where to route the traffic? What is the difference between Istio ingress controller and Envoy side car while both of them use Envoy and interact with Pilot? What does Pilot really provide as part of the interaction? My curiosity forced me to use tcpdump to capture the network traffic on the `istio-ingress` pod and one of the microservices I deployed. For simplicity, I turned off mTLS in Istio and focused mainly on the Istio ingress, Envoy side car and Pilot components. I recorded a short video to share with you on what I have learned. Enjoy and give us feedback on the Istio user mailing list.