Alek's Blog - mtls

Istio vs. Linkerd: Service Mesh on Kubernetes

2026-05-12T00:00:00+00:00

Both Istio</a> and Linkerd</a> are CNCF Graduated service meshes that provide automatic mTLS, traffic policy, and observability for Kubernetes workloads. Both run in sidecar mode for this comparison — a proxy container injected into every pod. The fundamental difference is the data plane: Istio uses Envoy</a>, Linkerd uses its own Rust-based proxy (linkerd2-proxy</code></a>). That choice drives the differences in overhead, extensibility, and egress control.</p>

This post compares them on the dimensions that matter for a production deployment. For the broader question of Istio vs. Envoy Gateway (ingress-only), ambient mode, and managed cloud specifics (AKS, GKE, OVH MKS), see the companion postIstio vs. Envoy Gateway: Gateway API on Kubernetes</a>.</p>



Istio vs. Envoy Gateway: Gateway API on Kubernetes
2026-04-30T00:00:00+00:00
Both Istio</a> and Envoy Gateway</a> implement the
Kubernetes Gateway API</a> and use Envoy as their data plane.
That is roughly where the similarity ends. Istio is a full service mesh that happens to
implement Gateway API; Envoy Gateway is a dedicated Gateway API controller with no mesh
ambitions. Choosing between them is mostly a question of scope.</p>
This post starts with that comparison — architecture, mTLS, egress control, and resource
overhead — then broadens to cover Cilium</a> as a lighter alternative for
East-West security, how the choice plays out on managed Kubernetes offerings (AKS, GKE, and
OVH MKS including their cloud-native ingress and egress options), and finally how to get
the real client IP through a cloud load balancer to your application.</p>