Exploring Istio and Envoy

Take a walk with me down how Istio and Envoy propagate the service mesh as we follow how a request eventually gets to a pod in a Kubernetes cluster.

Transcript

1. ISTIO INTERNALS A LOVE STORY ABOUT
2. PREFACE WHO I AM ▸ My name is Bobby. People like to call me Bobby Tables ▸ I work at Namely (namely.com) ▸ I’m currently a lead on our implementation of Istio on Kubernetes ▸ We’ve been following and trying Istio since 0.1
3. TALKING ABOUT WHAT WE’RE ‣ A 100 meter dive into Istio and its internals ‣ Explain a little bit of the lower level architecture of Istio ‣ All of this will be in the context of Istio + Kubernetes ‣ Following a request through our mesh Istio
4. ISTIO AND ENVOY FORGETTING ABOUT ENVOY ▸ Istio's abstraction over Envoy very well done ▸ So well done, in fact, you can sometimes forget Envoy is even there ▸ So when things aren't working it can difficult to know sometimes which part is wrong
5. ISTIO AND ENVOY ISTIO INGRESS ▸ A good example is Istio Ingress, which is mostly Envoy but configured slightly different than sidecars ▸ Istio has a pod called "istio-ingress" that runs a Envoy process that is configured to retrieve routes from Pilot for ingress rules only ▸ Pilot is listening to the Kubernetes API server and refreshing its cache of ingress rules ▸ Envoy Ingress then retrieves these updates every second (or whatever is configured)
6. ISTIO INGRESS THE LIFE OF AN INGRESS
7. DEMO STEP BY STEP ▸ Using the Pilot APIs, we'll see what view of the world Istio has currently ▸ We'll apply a service and watch Pilot update ▸ We'll then deploy a set of pods and watch Pilot update ▸ We'll then apply an ingress and watch Pilot update
8. DEMO
9. NEXT STEPS GREAT, NOW HOW DOES THE POD GET TRAFFIC? ▸ Once the Ingress (Envoy) receives a request, it will find an upstream endpoint to forward the request to ▸ Envoy has many modes for load balancing, by default it uses Round Robin ▸ Once a pod IP is selected, the next step happens.
10. NEXT STEPS THE ISTIO + ENVOY SIDECAR ▸ When using Istio + Kubernetes, your pods will have a "sidecar" attached inside of it. ▸ This sidecar is running another Envoy instance that is configured to pull from the Pilot API (the same way Ingress works, but in sidecar mode) ▸ This sidecar receives all traffic (ingress and egress) ▸ Istio does this by creating a NAT IP Table rule that redirects all traffic to port 15001 of Envoy
11. NEXT STEPS THE ISTIO + ENVOY SIDECAR (CONT) ▸ Envoy accepts the connection on port 15001, and then looks for an appropriate "listener" that has been configured ▸ The Pilot API gives every sidecar a list of Listeners that Envoy will create internally ▸ For a given sidecar, Pilot will return a listener for the IP and Port for Envoy to forward requests to.
12. NEXT STEPS THE ISTIO + ENVOY SIDECAR (CONT)
13. HOW TRAFFIC GETS TO OUR POD WHAT WE'RE GOING TO DO ▸ We're going to look at how Envoy listens for traffic by inspecting Pilots LDS endpoint (Listener Discovery Service) ▸ We'll then refresh our ingress a few times to generate traffic ▸ Then we'll see how Envoy logs this traffic on the pod
14. DEMO
15. ENVOYS ADMIN ENVOY ALSO PROVIDES AN ADMIN ▸ Envoy also has an admin page that provides great information ▸ You can port-forward the Envoy endpoint locally to view this ▸ You can view what Envoys state of the world is, IE: Clusters, Listeners, Routes, etc.
16. DEMO
17. WHERE TO GO ▸ Your best bet when things go wrong, is to look at Pilot logs. ▸ Since Pilot is the source of truth for your service mesh, it's common this is where problems will arise most of the time ▸ When in doubt, restart Pilot.
18. CLOSING UP ▸ Istio is a great control & data plane for Envoy. It provides control of most of the features of Envoy currently, with plans to add more. ▸ It's important to keep in mind that all traffic in your cluster goes through Envoy ▸ Istio is only used by Envoy to ask questions, such as "what is this service" and "what port should I listen on?"