Hello, and welcome to Continuous Improvement, the podcast where we dive deep into various topics related to software development and infrastructure. I’m your host, Victor, and in today’s episode, we are going to explore the fascinating world of service mesh and specifically focus on Istio. So, whether you’re a software developer or just curious about how networks in the cloud work, this episode is for you!

As a software developer, I sometimes find infrastructure networking quite confusing. But fear not, because today we’ll be unraveling the mysteries of service mesh and shedding light on Istio.

So, what exactly is a service mesh? Well, to put it simply, a service mesh is a dedicated infrastructure layer responsible for handling service-to-service communication. It ensures reliable delivery of requests through the complex topology of services in a cloud-native application.

In practice, a service mesh is usually implemented as a collection of lightweight network proxies deployed alongside the application code. The beauty of it is that the application doesn’t even need to be aware of these proxies. Contrary to its name, a service mesh is not a mesh of services, but rather a mesh of proxies that abstract away the network layer.

Now, a service mesh fulfills three primary functions: flow control, security, and observability. The control plane manages the flow of configuration data from a central unit to the proxies that make up the mesh. Meanwhile, the data plane handles the flow of application data between microservices, facilitated by the sidecar proxy.

One popular service mesh that you may have heard of is Istio. Istio is an open-source project born out of a collaboration between Google, IBM, and Lyft’s Envoy proxy. It provides a transparent infrastructure layer for managing inter-service communication on Kubernetes.

So how does Istio work? It intercepts network traffic bound for a pod and proxies it through an intelligent Layer 7 proxy called Envoy, which is mounted as a sidecar to the main container. Istio then applies advanced routing and policy rules to enhance security, resiliency, and observability. It even uses mutual TLS for communication between peers.

Using Istio offers immediate advantages in the three core functions of a service mesh. However, it’s important to note that there are complexities involved, such as operational overhead and a slight latency at the link level. Istio also requires platform adaptation and consumes additional resources like memory and CPU.

Let’s take a closer look at the components of Istio. The control plane, known as istiod, handles functions like service discovery, proxy configuration, certificate management, and more. In older versions of Istio, these functions were spread out among separate deployments, but they have since been consolidated into istiod.

The data plane of Istio consists of Envoy proxy instances that communicate with the Istio control plane. Once configured and synchronized, these proxies manage all inbound and outbound network traffic to pods by applying advanced Layer 7 routing and policy rules. The configuration is achieved through the control plane’s Rules-Based API, which then compiles it into Envoy-specific settings.

To be entirely transparent to application developers, Istio reroutes all traffic to Envoy by manipulating the IP tables of all pods in the service mesh. Traffic hijacking is achieved through either an init container called istio-init or Istio’s Container Networking Interface (CNI) plugin.

In addition to its core functionalities, Istio also offers a Security API that allows you to configure policies at different levels of granularity. It supports various modes of TLS communication, such as DISABLE, PERMISSIVE, and STRICT. By examining Istio request metrics, you can determine whether a request was proxied over mTLS.

In conclusion, service mesh and Istio are fascinating technologies that provide a dedicated infrastructure layer to manage inter-service communication. Although they bring immediate advantages in terms of flow control, security, and observability, they also introduce complexities and require platform adaptation.

I hope this episode helped shed some light on service mesh and Istio. Remember, learning is a continuous process, and there’s always more to explore. Thank you for tuning in to Continuous Improvement. I’m Victor, and until next time, keep improving!