Skip to content
docktionary

Clusters & cloud

Service mesh

A Service already gives you a stable address and basic load balancing. A mesh adds a uniform layer of traffic control, security, and observability on top, without touching application code.

The sidecar pattern

Most meshes (Istio, Linkerd) work by injecting a proxy — commonly Envoy — as a sidecar container into every Pod. All traffic in and out of the Pod's main container is transparently routed through that proxy, which is what makes mesh features apply uniformly without any code change.

terminal
kubectl label namespace default istio-injection=enabled
kubectl rollout restart deployment docktionary-app
kubectl get pod -l app=docktionary -o jsonpath='{.items[0].spec.containers[*].name}'
# app istio-proxy   <- the sidecar is now present

What a mesh actually buys you

  • mTLS everywhere — every service-to-service connection is automatically encrypted and mutually authenticated, without each team hand-rolling TLS.
  • Fine-grained traffic shaping — route a percentage of traffic to a new version (canary), retry failed requests with a backoff, inject a timeout — declaratively, at the infrastructure layer.
  • Uniform observability — request-level metrics, traces, and a service dependency graph for free, since every request already passes through the proxy.
  • Authorization policy — allow or deny service-to-service calls based on identity, independent of NetworkPolicy's IP/port-based rules.

Traffic splitting for a canary release

virtualservice.yaml
apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: docktionary-app
spec:
  hosts: ["docktionary-app"]
  http:
    - route:
        - destination:
            host: docktionary-app
            subset: v1
          weight: 90
        - destination:
            host: docktionary-app
            subset: v2
          weight: 10

Sidecarless (ambient) mesh

The per-Pod sidecar proxy is also the biggest cost a mesh adds, so newer mesh architectures — Istio's Ambient mode, Cilium's eBPF-based mesh — move that work out of the Pod. A per-node proxy (and, in Istio Ambient's case, a lightweight per-namespace layer for mTLS) handles what the sidecar used to, so a Pod gets mesh features without paying for a proxy container of its own. It's a newer, actively-evolving approach, not yet the default most teams reach for — but it directly targets the resource cost that's historically been the strongest argument against adopting a mesh at all.

When it's not worth it

A mesh adds a proxy to every Pod, which costs CPU, memory, and latency, plus real operational complexity (the mesh's own control plane has to be upgraded and watched). For a handful of services with simple traffic patterns, that cost usually isn't worth it — plain Services, Ingress, and application-level retries cover most needs. The case for a mesh gets stronger as the number of services, the need for mTLS by policy (not just by convention), or the demand for fine-grained traffic control grows.