Why I Switched from Istio to Linkerd: A Practical Service Mesh Evaluation

Author: Eric Fossas (translated by Liu Yamong, planned by Tina). The article reflects on the author's experience with service meshes, particularly Istio and Linkerd, after using Istio in production for two years.

Service meshes provide traffic monitoring, mTLS encryption, and advanced features such as traffic splitting, retries, and timeouts, but they often add complexity and are misused to solve problems better addressed elsewhere.

Current limitations of service meshes : reliable only for HTTP, sidecar proxy must start before application containers, init containers and CronJobs cannot run under a sidecar, and non‑HTTP protocols are poorly supported.

The author experienced frequent issues with Istio, including broken CRDs across versions, unreliable support for database and AMQP protocols, and difficult debugging when TLS secrets were misnamed, leading to cluster‑wide outages.

Istio also requires extensive Helm or istioctl deployment steps, heavy reliance on custom resources (CRDs) that cause vendor lock‑in, and a steep learning curve comparable to the initial Kubernetes learning period.

1. Why I uninstalled Istio

Complex installation, long Helm deployment times, heavy CRD dependence, and fragile configuration (e.g., broken TLS secrets) made Istio impractical for the author's use cases.

2. Why I originally chose Istio

When Kubernetes emerged, it outperformed other orchestrators (Mesos, Nomad, Swarm). Istio appeared as the natural service‑mesh solution backed by Google, with Linkerd as its main competitor.

3. What to use now?

After evaluating multiple service meshes (AWS AppMesh, Traefik Maesh, Azure Open Service Mesh, Nginx, Kuma, Consul Connect), the author selected Linkerd for its simplicity, Helm‑friendly deployment, single CRD, Rust‑based proxy, and clean dashboard.

Linkerd’s advantages include easy Helm deployment, straightforward CRD, smooth Grafana/Prometheus integration, and a Rust‑written proxy that avoids the complexity of Envoy. Its drawbacks are limited sidecar support and unreliable handling of non‑HTTP protocols.

4. Summary

The author predicts that service meshes will eventually become native Kubernetes resources via the Service Mesh Interface (SMI), reducing the current operational overhead. While Istio is not yet part of CNCF, Linkerd is, and the author plans to stay with Linkerd as long as it remains simple and effective.