Most clusters do not need a service mesh. A service mesh puts a proxy (a sidecar) next to every pod and routes all traffic between pods through it, so mutual TLS, retries, traffic shifting, and per-request telemetry happen without changes to your application. Istio's proxy is Envoy. This provides substantial capability, at the cost of a proxy in every pod. Add a mesh when you need HTTP-level control or provable encryption between services that Cilium alone cannot provide, not before. Syself Autopilot does not include or manage a mesh; you install and run it yourself.

What a mesh gives you#

• mTLS between services. Every service proves its identity with a certificate and traffic is encrypted, so a pod cannot reach a service merely because it runs in the same cluster.
• Resilience. A retry resends a request that has just failed; outlier detection stops sending traffic to a pod that keeps failing. Together they turn a brief network disruption into a slightly slower response instead of an error. See Handle unreliable networks with Istio .
• Traffic control. Weighted routing, canary releases (send a small share of traffic to a new version), and per-route timeouts.
• Telemetry. Latency, error rates, and a dependency map, because every request passes through the mesh.

Why teams adopt a mesh at scale#

The list above describes the mechanics. What makes a mesh worth its cost at scale is that it provides an organization with one standardized, provable layer for traffic and security:

• Provable zero-trust encryption. Every service-to-service connection is encrypted and identity-checked with mTLS. You can demonstrate that a connection is encrypted, rather than merely assert that the network is trusted. That is what an audit or a compliance framework requires, and it is the zero-trust property regulators look for.
• One standard for every service. Access rules, retries, and timeouts are written the same way for every service, instead of each team reinventing them in application code.
• Uniform observability. Because every request crosses the mesh, you get consistent metrics, distributed traces, a live traffic map, and alerts across all services, without instrumenting each one.
• Richer postmortems. When something breaks or slows down, the mesh's per-request telemetry answers which call failed and why, or where the added latency came from, instead of leaving you to guess from scattered logs.

These are why a mesh justifies its cost once you run many services or carry compliance requirements, and why it is excessive for a handful.

What Cilium already gives you, and where it stops#

Cilium is the cluster network on every Syself Autopilot cluster, and it covers part of the list already:

• Flow visibility through Hubble: which pods talk to which, and which connections are dropped. See See flows with Hubble .
• L3 and L4 network policy: control which workloads may connect to which, by identity, not IP. See Segment with network policies .

Where Cilium stops is Layer 7: HTTP-aware policy (allow only GET /api) and per-request retries. Cilium can express L7 rules, but Syself Autopilot rejects them at apply time by design. An L7 rule pulls every matched connection out of the eBPF datapath and through a userspace proxy on the node. That path is heavier and far more complex than the L3/L4 rules that stay in eBPF, and it has been a source of correctness bugs: a 2026 Cilium security advisory (CVE-2026-33726⁠) found the L7 proxy could bypass a NetworkPolicy for same-node traffic, letting through connections a policy was meant to block. A policy engine that silently allows traffic it should deny is worse than none, so the platform keeps network policy to the identity-based L3/L4 rules that run entirely in eBPF and behave predictably. Other major providers that run Kubernetes on Cilium currently gate L7 the same way. For genuine L7 control, use a service mesh, where the proxy is a deliberate part of the design rather than a policy side effect. The full reasoning is in Segment with network policies .

Which mesh#

Use sidecar mode, not ambient#

Istio comes in two modes. Sidecar mode runs a proxy in each of your pods. Ambient mode drops the sidecars and does the work in the node's network instead. On Syself Autopilot, use sidecar mode. Ambient mode is not supported.

A sidecar is part of your workload. It sits in your pod, you run it, and if it breaks, it breaks that one pod. Ambient reaches into the node's network, which is Syself's to run and keep stable . Put the mesh there and it is no longer yours to manage, and one piece of it handles traffic for every meshed pod on the node.

Ambient is not ready for that yet. It does not have feature parity with sidecar mode, parts of it are still beta⁠, and Syself runs production on stable, released software. Sidecar mode does everything the guides here need. We look at ambient again with each Kubernetes release and will support it when it is ready. Cilium's own Layer 7 network rules are off for now for similar reasons; the detail is in Networking and Cilium .

The cost of sidecars#

A sidecar mesh puts a proxy container in every pod. That adds CPU and memory per pod and a small amount of latency per hop, and it is one more component to upgrade and debug. For a small number of services, the operational cost can outweigh the benefit. As the number of services grows, and especially once you have compliance requirements around encrypting traffic between services or need HTTP-level resilience, the mesh begins to justify its cost. Base the decision on your actual requirements, not on adopting technology for its own sake.

Where to go next#

• Handle unreliable networks with Istio
• Add retries and outlier detection