System Design Cases
Service Mesh Deep: Istio xDS, mTLS, canary, ambient, Cilium eBPF
Service mesh internals deep dive across 3 layers (istio sidecar, ambient mesh, cilium-ebpf) with 4 scenarios: Istio mTLS auto, canary 95/5 traffic shift, AuthorizationPolicy deny, sidecarless (ambient ztunnel+waypoint and Cilium eBPF kernel path).
Service mesh: identity, transport and L7 are separate layers
In sidecar mode, application traffic passes through Envoy proxies while Istiod distributes configuration and identity material. In Istio ambient mode, per-node ztunnels provide L4 mesh transport and identity; an optional Envoy waypoint is the L7 policy and routing point. “Sidecarless” therefore does not mean “no proxy anywhere.”
Do not merge these guarantees
- IPsec or WireGuard can encrypt packets between node endpoints.
- Workload mTLS authenticates workload identities and encrypts a mesh transport.
- L7 policy parses protocols such as HTTP and applies route/auth rules.
- eBPF can implement L3/L4 capture and policy, but Cilium uses Envoy for L7 proxy features. “eBPF-only service mesh” is not an accurate universal model.
Istio mTLS policy is explicit: permissive and strict modes have different migration and security behavior. Verify effective policy and plaintext escape paths instead of assuming installation implies strict mTLS.
Control-plane failure
xDS delivery is asynchronous. Proxies ACK accepted versions and NACK invalid resources while retaining the last valid configuration. Treat mixed versions, NACKs, stale endpoints and certificate expiry as observable states. Existing data-plane traffic may continue during a control-plane outage, but that does not make configuration or certificate changes instantaneous.