As a software developer, I sometimes find infrastructure networking quite confusing. In this article, I will delve deeper to understand service mesh and Istio. A service mesh is a dedicated infrastructure layer responsible for handling service-to-service communication. It ensures the reliable delivery of requests through the complex topology of services that comprise a modern, cloud-native application.
In practice, a service mesh is usually implemented as an array of lightweight network proxies deployed alongside the application code, without requiring the application to be aware of them. Contrary to its name, a service mesh is not actually a mesh of services but rather a mesh of proxies that abstract away the network layer. The service mesh primarily fulfills three 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. The data plane, on the other hand, manages the flow of application data between microservices in the mesh, facilitated by the sidecar proxy.
One commonly used service mesh is Istio. Born out of a partnership between Google, IBM, and Lyft (Envoy proxy), Istio is an open-source project that provides a transparent infrastructure layer for managing inter-service communication on Kubernetes. It hijacks network traffic bound for a pod and proxies it through an intelligent Layer 7 proxy (Envoy), mounted as a sidecar to the main container. Istio applies advanced routing and policy rules, enhances security and resiliency, and uses mutual TLS for communication between peers.
Istio offers immediate advantages in the core functions of a service mesh: flow control, security, and observability. However, it does introduce complexities, such as operational overhead and a slight latency at the link level. It also requires platform adaptation and consumes extra resources like memory and CPU.
The Istio control plane, known as istiod, performs various functions: service discovery, proxy configuration, certificate management, and more. In older versions of Istio, these functions were divided among separate deployments but have since been consolidated into istiod.
Istio's data plane 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, 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 accomplished through either an init container (istio-init) or Istio's Container Networking Interface (CNI) plugin.
Istio's flow control capabilities can be divided into three categories: request routing, resilience, and debugging. It exposes a Rule-Based API that allows users to configure traffic management within the mesh. Traffic policies applied to a host service are based on various matching conditions, such as load balancing strategies, connection pool settings, and outlier detection.
Istio also offers a Security API to configure policies at varying levels of granularity. It supports three modes of TLS communication: DISABLE, PERMISSIVE, and STRICT. By looking at Istio request metrics, you can determine whether a request was proxied over mTLS.
In summary, this article serves as a brief deep dive into service mesh and Istio. There's still much more to explore. Thank you for reading this article, and let's continue learning!