What is a service mesh, and do you need one?
A service mesh is an infrastructure layer that sends traffic between services through proxies, which add mutual TLS identity, retries and timeouts, traffic splitting and per-request metrics without changes to application code. The proxies form the data plane, and a control plane configures them. You need one when you must authenticate and authorize individual services or control Layer 7 traffic between them; if you only need encryption in transit and network segmentation, a CNI plugin with encryption and network policies covers that with less to operate.
What a mesh adds
| Capability | What the mesh does | Alternative without a mesh |
|---|---|---|
| Workload identity and mTLS | Issues each workload a certificate tied to its service account, rotates it, and encrypts and authenticates every connection | Node encryption in the CNI encrypts but does not identify services |
| Service-level authorization | Rules such as “only checkout may call POST /charges on payments” | Layer 7 network policies in some CNIs |
| Reliability | Retries, timeouts and circuit breaking, configured centrally | Client libraries in each language |
| Traffic splitting | Send 5% of internal traffic to a new version | Weighted routes at the edge with Gateway API |
| Telemetry | Request rate, errors and latency for every service pair | Application metrics; Layer 3 and 4 flow logs from the CNI |
The common thread is that the mesh understands requests, not only packets, and knows which service sent them.
Sidecar, ambient and per-node proxies
How the proxies are deployed decides most of the cost.
| Model | Where the proxy runs | Resource use, Istio 1.24 at 1,000 requests per second |
|---|---|---|
| Sidecar | A proxy container in every Pod | About 0.20 vCPU and 60 MB per sidecar |
| Ambient, Layer 4 | One ztunnel per node for mTLS | About 0.06 vCPU and 12 MB per ztunnel |
| Ambient, Layer 7 | Optional waypoint proxies per namespace or service | About 0.25 vCPU and 60 MB per waypoint |
| Per-node proxy with eBPF | eBPF in the kernel for Layer 3 and 4, a shared proxy per node for Layer 7 | Not published in comparable terms |
The figures come from Istio’s performance page and depend on hardware and configuration. Sidecar cost grows with the number of Pods, and adding or upgrading a sidecar means restarting the Pod. Istio’s ambient mode reached general availability in Istio 1.24 in November 2024 and separates the cheap Layer 4 part from the optional Layer 7 part. Cilium’s service mesh handles Layer 3 and 4 in eBPF and passes Layer 7 traffic through an Envoy proxy on each node.
Common implementations
Istio uses the Envoy proxy and supports both sidecar and ambient modes; it became a CNCF graduated project in July 2023. Linkerd uses its own micro-proxy written in Rust, deployed as a sidecar, and graduated from the CNCF in 2021. Cilium adds mesh features to its CNI plugin. All three implement Gateway API.
Gateway API inside the mesh
The GAMMA initiative extends Gateway API to service meshes. Instead of attaching to a Gateway, an HTTPRoute attaches directly to a Service, so the same resource defines routing at the cluster edge and between services. Mesh support has been part of the Gateway API standard channel since v1.1.0. If you are replacing an Ingress controller, see what replaces ingress-nginx.
When you do not need one
- You only need encryption in transit. Transparent WireGuard® or IPsec encryption in the CNI covers traffic between nodes with no proxies. See whether Pod traffic is encrypted.
- You need segmentation. Network policies decide which Pods can talk to which, and some CNIs add Layer 7 and domain-name rules.
- Canaries happen at the edge. Weighted HTTPRoutes on the ingress gateway split user traffic without touching internal calls.
- You run a handful of services owned by one team. Client libraries and application metrics give the same results with fewer moving parts.
When you do
- Zero-trust requirements. Auditors or customers expect every service call to be authenticated and authorized by workload identity, not by network location.
- Many teams and languages. Consistent retries, timeouts and metrics across services written in several languages are hard to keep in sync through libraries.
- Internal progressive delivery. Shifting traffic between versions of internal services, not only at the edge.
- Multi-cluster service traffic. Cross-cluster discovery and failover with one identity system. Expect added complexity: a shared root of trust, east-west gateways, and upgrades coordinated across clusters.
Start with the smallest model that meets the requirement. A Layer 4 mTLS deployment can grow into Layer 7 features service by service.
Service meshes on Cloudfleet
Cloudfleet Kubernetes Engine (CFKE) encrypts traffic between nodes with WireGuard® and enforces Cilium network policies by default, which covers encryption in transit without a mesh. A service mesh is not included; when you need mTLS identities or Layer 7 routing, you can install Istio. The network security page explains which layer covers what.