What is a service mesh: Istio
…key features
Service meshes are a tool for injecting observability, traffic management, and security features into applications at the platform level rather than the application level, for a brief overview check the value of a Service Mesh.
Over the last few years, service mesh adoption has been steadily increasing, and it has become a critical piece of infrastructure for many organizations that aim to be or become cloud-native. Service meshes are still early, but nonetheless, Istio seems to dominate when it comes to adoption, examples of other implementations are Linkerd, Conduit, and Consul.
Istio was initially developed by Google and IBM and built on top of the Envoy project from Lyft.
Istio’s architecture consists of a control plane and a data plane. The data plane consists of Envoy proxies deployed as sidecars containers. Envoy is transparent to the service, attaching itself to every container without the need to modify the code. The sidecar proxy architecture takes all of the application networking logic (connectivity, security, reliability, and observability) and puts it outside your application container in a proxy container.
Technically speaking Istio provides:
- Observability: By adding services to the mesh you’ll begin to get tracing and monitoring capabilities for those services.
- Traffic management: load balancing, service discovery, timeouts, and retries.
- Security: automatically establish a secure channel between services by managing service identities, certificates, and mTLS handshaking.
Looking at the traffic flow for service from the mesh, we can see that clients connect to a proxy sidecar container that is running next to your service, and on the inbound part policies like authentication and authorization are applied, and on the outbound part traffic management policies are applied.
Some of the most important Istio CRD are:
- virtualservices.networking.istio.io
- gateways.networking.istio.io
- destinationrules.networking.istio.io
When a request comes into the gateway, Istio will use the rules defined in the virtualservice resource to determine which service to route the traffic to. Afterwards the destinationrule applies the policies to traffic intended for the service after routing has occurred.
A service mesh ultimately shifts the implementations concerning traffic policies and controls from the app level to the network level (more exactly applying them on top of an existing network) without requiring applications to be rewritten.
When using Istio, Envoy proxies are placed next to every single pod you’re running, which comes with a cost in CPU and memory, but now Istio has created Ambient Mesh to address that concern, which takes a less invasive approach by removing the need for sidecars everywhere with shared L4 proxies per node, and L7 proxies per service account.
Last but not least in July/2023 Istio graduated from CNCF serving as a testament to its role as a pioneer in the modern service mesh pattern.
