Cilium’s sidecarless model just stopped being an academic footnote and became the default pattern your platform team will argue about in the next sprint. Isovalent’s “everything you need to know” narrative and the docs centered on the v1.19 baseline show how to run full L3–L7 policy, observability, and advanced L7 load balancing without injecting an Envoy into every pod — and how to do that as part of a Flux-driven GitOps pipeline and alongside Istio ambient mesh.
That matters because the operational model changes: kernel-resident eBPF replaces many per-pod proxies for traffic control and telemetry. Hubble remains the primary observability pivot (L3/L4 flow visibility out of the box, with integrations available for richer traces), while CiliumEnvoyConfig is the escape hatch when you still need Envoy-level HTTP routing — but crucially, you don’t have to make it the default for every workload.
Concrete knobs you should know
- For teams running Istio ambient mesh and wanting Cilium to own selected L7 policies, configure Cilium so socket-based load balancing is constrained to the host namespace and enable coexistence with Istio’s networking model. Exact Helm values differ by chart version; check the Cilium Helm chart docs for socketLB and CNI coexistence settings appropriate to your release.
- Flux CD patterns are explicit: register the Cilium Helm repository as a Flux HelmRepository, then deploy Cilium via Flux HelmRelease (or a Kustomization that applies templated Helm output). Enable Hubble and include any CiliumEnvoyConfig examples you need in the same GitOps repo so installs are repeatable and auditable.
- Treat Cilium v1.19 (and later patch releases) as the baseline many recent guides target; examples and flags in docs assume v1.19+. Confirm exact compatibility and values against your cluster and Helm chart version before upgrading.
The trade-offs, rendered bluntly
Public comparisons and blog benchmarks show different strengths depending on the test: Istio ambient can achieve higher requests-per-core in proxy-heavy scenarios, while Cilium tends to reduce user-space overhead by moving work into the kernel and eBPF. Translating that: ambient mode can win on richer per-core proxying throughput in some workloads, Cilium wins on simpler network stack placement and lower user-space resource cost. Neither is magic — they’re different engineering compromises.
Here’s the part that deserves a blunt take: if your platform still defaults to a sidecar-per-pod as the unquestioned design, you’re choosing complexity for its own sake. Sidecars give richer per-request features out of the box, but at the cost of lifecycle complexity, heavier resource footprints, and more noisy telemetry plumbing. Cilium’s story — sidecarless by default, Envoy when needed via CiliumEnvoyConfig — is the right call for most clusters where scale, observability cost, and operational simplicity matter.
Operational friction to expect
Switching to a sidecarless model is not a checkbox. You’ll need to re-evaluate:
- Policy and RBAC placement: namespace labels + Cilium-managed HTTP/network policies replace some Istio CRD patterns and require revisiting who owns which rules.
- Telemetry expectations: Hubble provides L3/L4 visibility; add tracing bridges where you need per-request distributed traces and keep an eye on how traces are correlated across kernel-handled and proxy-handled flows.
- Upgrade discipline: many docs assume v1.19+. If you’re behind, examples and Helm values may not match your installed chart.
Why this signals a deeper shift
These updates aren’t just feature releases; they’re integration plumbing. eBPF dataplanes are maturing into first-class service-mesh primitives, and vendors are standardizing control-plane handoffs (Istio ambient ↔ Cilium) rather than trying to own every stack layer. For platform teams, that means fewer ad-hoc hacks and more well-defined upgrade/opt-out patterns.
If you run a production cluster, start auditing which workloads actually need a per-pod proxy and which ones can be handled by Cilium’s kernel-driven policies. The future here isn’t “Envoy everywhere” or “kernel-only everywhere” — it’s hybrid models where eBPF does the heavy lifting and Envoy is used intentionally, not by default. Expect your observability and GitOps flows to be where these architectural choices show up in tickets and on-call metrics.
Link: if you want a deeper read on the v1.19 maintenance and sidecarless guidance, see our previous note Cilium 1.19.5: eBPF dataplane patch and sidecarless service mesh.
Final thought: eBPF didn’t just make networking faster — it changed the unit of operational complexity. Platform teams that treat sidecars as an implementation detail will be the ones rewriting runbooks next quarter. Teams that treat eBPF as the default dataplane will be the ones who sleep better.
Sources
- Cilium Service Mesh – Everything You Need to Know (Isovalent blog)
- Cilium Service Mesh use cases (official Cilium docs)
- How to Deploy Cilium Service Mesh with Flux CD
- Integration with Istio (Cilium 1.20.0-dev documentation)
- Scaling in the Clouds: Istio Ambient vs. Cilium (Istio blog)
- Cilium GitHub repository and releases