Skip to content

Sidecar-based versus Sidecarless Architectures: CCA practice questions

Classic service meshes put a proxy into every application pod. A mutating webhook injects the sidecar container when the pod is created, and from then on all traffic the pod sends and receives passes through that proxy. Sidecarless designs move the proxy out of the pod, either to the node or to a shared deployment.

By Ibrahim Yesilay · Published · Updated

Independent community practice, not affiliated with or endorsed by CNCF or The Linux Foundation.

What Sidecar-based versus Sidecarless Architectures covers in CCA

Classic service meshes put a proxy into every application pod. A mutating webhook injects the sidecar container when the pod is created, and from then on all traffic the pod sends and receives passes through that proxy. Sidecarless designs move the proxy out of the pod, either to the node or to a shared deployment.

The Istio documentation compares both approaches for its own sidecar and ambient modes, and the comparison carries over well. In sidecar mode resources are provisioned for the worst case of every pod, so the average resource cost is large, while ambient mode is small; a workload with many replicas can share one waypoint proxy instead of running a sidecar per replica. Joining the mesh also differs: with sidecars you label the namespace and restart the pods, with ambient mode labeling is enough. A request between two sidecar workloads is processed at Layer 7 twice, once by each sidecar, and Kubernetes Jobs are awkward because the sidecar keeps running after the main container finishes.

The trade-off is in the security model. With sidecars each workload has its own keys, which Istio calls the strongest model, but a compromised application pod also exposes those mesh keys. In ambient mode a node agent only holds the keys of the workloads on its node, and a compromised application pod does not reveal them. Ambient mode handles Layer 4 in a node proxy called ztunnel and adds an optional Envoy-based waypoint for Layer 7 features.

Cilium is sidecarless from the start. IP, TCP and UDP processing happens in eBPF in the kernel, and protocols that need parsing, such as HTTP, gRPC and DNS, go to an Envoy proxy that runs once per node. When L7 features such as Ingress, Gateway API, L7 policies or L7 visibility are in use, the agent starts this Envoy as a separate process inside the agent pod, so L7 traffic then depends on the agent pod being available.

The alternative is the cilium-envoy DaemonSet, enabled with envoy.enabled=true. Envoy then has its own life cycle: agent restarts and upgrades do not interrupt proxied traffic, Envoy patch releases do not touch the agent, and both get separate resource limits, logs and health probes. In both modes the agent and Envoy talk over UNIX domain sockets for xDS configuration, access logs and the admin interface. Cilium can also run alongside Istio when a team needs its sidecar or ambient features.

Key points

  • Sidecars are injected at pod creation, so joining a namespace to a sidecar mesh needs pod restarts.
  • Istio rates per-workload keys as strongest, but a compromised sidecar pod exposes mesh keys.
  • Cilium runs one Envoy per node, embedded in the agent pod or as the cilium-envoy DaemonSet.
  • In embedded mode, L7 traffic depends on the availability of the Cilium agent pod.

Three sample questions

10 CCA questions on Sidecar-based versus Sidecarless Architectures, 10 with explanations. How practice works

Question 1

Which feature does Cilium Service Mesh offer that traditional sidecar-based service meshes do not?
  1. A.mTLS encryption between services
  2. B.Traffic routing based on HTTP headers
  3. C.Sidecarless architecture using eBPF
  4. D.Circuit breaking for backend services

Correct answer: C

Cilium service mesh needs no sidecar: L3/L4 processing happens in eBPF and L7 protocols are parsed by a per-node Envoy proxy that Cilium manages. Why the other options are wrong. mTLS, header-based routing and circuit breaking are offered by sidecar meshes too, so none of them is what sets Cilium apart.

Sources: Cilium docs: Service Mesh, Cilium docs: Envoy

Question 2

What is the primary advantage of Cilium's sidecarless service mesh architecture compared to traditional service meshes?
  1. A.It offers more protocol-awareness for L7 filtering
  2. B.It provides better integration with cloud provider load balancers
  3. C.It significantly reduces resource overhead and performance impact
  4. D.It simplifies certificate management for mTLS

Correct answer: C

Without a sidecar in every pod there are no per-pod proxy containers to size and run, so resource overhead drops; Cilium handles L3/L4 in eBPF and sends only L7 traffic through one Envoy per node. Istio documents the same trade-off: sidecar mode has a large average resource cost, node-level proxies a small one. Why the other options are wrong. Protocol awareness for L7 is the same Envoy capability in both designs. Cloud load balancer integration and certificate management are not what the sidecar choice changes.

Sources: Cilium docs: Service Mesh, Istio: Sidecar or ambient?

Question 3

According to the Istio data plane comparison, in which mode does a compromised application pod give access to mesh keys?
  1. A.Sidecar mode, where each pod's proxy holds keys
  2. B.Ambient mode, because the node proxy holds keys for many workloads
  3. C.Both modes equally
  4. D.Neither mode, because keys are stored only in the control plane

Correct answer: A

The Istio comparison table rates the sidecar security model as strongest because each workload has its own keys, but notes that a compromised application pod gives access to mesh keys in sidecar mode and not in ambient mode, where each node agent only holds keys for workloads on that node. Why the other options are wrong. "Ambient mode, because the node proxy holds keys for many ...": the table says a compromised application pod does not expose mesh keys in ambient mode. "Both modes equally": the comparison lists Yes for sidecar and No for ambient. "Neither mode, because keys are stored only in the control ...": the proxies hold workload keys, which is why the table differs.

Sources: CNCF CCA curriculum (CCA_Curriculum.pdf), Istio: Sidecar or ambient?, Cilium docs: Service Mesh

Practice this topic

Focus mode keeps every question on Sidecar-based versus Sidecarless Architectures until you leave it. 10 free guest answers, then a free account; no credit card.

Or open CCA practice across all topics.

Sources

The explanation above was checked against these official documents.