What is a Service Mesh?

Overview

Service Meshes (e.g. Istio) solve security and scaling challenges that distributed systems like Kubernetes encounter once they reach a certain scale. This includes:

• Advanced load balancing.
• Advanced security features.
• More granular metrics, especially around requests.

This blog post will focus on Istio and its feature set that is commonly used to compliment Kubernetes.

Istio Architecture

Istio’s features are made available through two primary components:

• Envoy proxy: Istio’s built-in integration of Envoy proxy is fundamentally the same. It’s Istio’s control plane that extends its functionality.
• Control Plane: istiod is deployed as a Deployment in the istio-system namespace.

Highlights

Traffic

Service Meshes are typically something you introduce when concerns arise about Kubernetes infrastructure’s ability to handle traffic. This typically manifests in metrics via uneven traffic distribution among pods within services within nodes. Unusually low utilization of other resources (e.g. CPU, memory) caused by network congestion could be another sign. This is despite the fact that Kubernetes provides round-robin load balancing to pods. Kubernetes has poor load balancing because traffic between nodes are handled via per-node kube-proxy proxies. Istio, on the other hand, deploys a per-pod Envoy proxy, providing more granular traffic routing.

Istio provides additional traffic management features to compliment Kubernetes, such as:

• Dynamic Routing: Directing traffic based on request content, allowing for more intelligent load distribution.
• Fault Injection: Testing the system’s resilience by introducing controlled failures, helping identify potential points of failure.
• Circuit Breaking: Preventing cascading failures across the system by cutting off traffic to unhealthy services.

These needs can be difficult to predict without forward-looking load tests.

Security

Given that all traffic between pods are routed through their Envoy proxies, this enables control with a lot of granularity that can be used to implement security features like mutual TLS. This security need can arise depending on the scale and customer base of the application.

Istio’s service-level mutual TLS is enabled by strong service identities (derived from Kubernetes service accounts) to facilitate secure service-to-service communication. Istio’s Control Plane (specifically Citadel) provides automated certificate issuance and rotation to support this.

These service identities enable specifying retry rules, access controls, and other policies that can be propagated to the pod-level proxies.

Metrics

When the level of communication metrics provided by Kubernetes between services is not sufficient (especially in regard to requests), Istio provides the necessary granularity to acquire these metrics. These metrics easily integrate into observability platforms such as: Prometheus, Grafana, and Kiali.

Some metrics include:

• Request counts.
• Request duration.
• Request size.
• Response size.
• Error rates.

Conclusion

Service Meshes like Istio introduce capabilities not inherently available in Kubernetes. These include sophisticated traffic management, advanced security features, metrics, and strong policy enforcement. By leveraging the Envoy proxy, Istio compliments Kubernetes wonderfully (especially at higher traffic loads), transforming it into a more versatile platform for deploying and managing scalable, distributed systems. Through its comprehensive suite of features, Istio empowers both developers and operators to build and maintain highly resilient and secure applications, underscoring its vital role in the modern cloud-native ecosystem.

To be updated with an investigation into deploying Envoy proxy standalone without Istio.

---

Author

• ← Minmax Tree
• What is Recursion? →