The striking thing this week isn't a new feature — it's that the kernel is increasingly the place you install networking and L7 controls. Cilium 1.19.5, released June 16, 2026, is a small but important patch that keeps the eBPF dataplane reliable. That stability matters because production operators are moving L3–L7 enforcement into eBPF and expecting it to behave like a CNI: low-latency, highly available, and declaratively managed.
On the surface 1.19.5 is maintenance: fixes to eBPF map handling, datapath crash hardening, and reconciler edge cases so Cilium's DaemonSet behaves under resource pressure. Those plumbing fixes are what make sidecarless architectures tenable: when enforcement lives in the kernel rather than a pod, upgrade and failure modes change and the dataplane must be resilient to transient host-level conditions.
Why the attention on sidecarless? Two converging forces. First, eBPF removes the per-pod resource cost and CPU amplification of ubiquitous Envoy sidecars. Second, Istio Ambient and Cilium Service Mesh are showing that you can retain much L7 functionality without per-pod proxies: Istio moves Envoy/Wasm extension points out of individual pods; Cilium enforces L3–L7 with kernel hooks and selectively invokes userspace for stateful or complex logic. Benchmarks from project and community tests indicate Ambient can reduce per-request overhead compared with sidecared Envoy in some workloads, though results depend heavily on traffic shape and TLS profiles.
That doesn't mean sidecars are dead. They still win when you need per-pod filter chains, local TLS termination per identity, or very fine-grained per-process telemetry. But the old assumption — "every pod must host its own Envoy" — is now a brittle operational stance. Platform teams that keep designing on that assumption will pay in cost and scheduler pressure.
Operationally the ecosystem is stitching these pieces together with GitOps. Flux v2 workflows typically manage Cilium via source-controller and helm-controller resources (HelmRepository/HelmRelease), Kustomization for overlays, and health checks on DaemonSets plus reconciliation of CRDs like CiliumNetworkPolicy. This matters: you don't want ad‑hoc kubectl changes to debug dataplane state housed in kernel maps. Declarative lifecycle management and centralized observability (Hubble) are minimal control-plane features for sidecarless productionization.
Two practical trade-offs platform engineers should care about:
- Observability model: Sidecarless shifts telemetry from per-pod Envoy metrics to centralized collectors (Hubble, kernel counters, eBPF maps). That lowers metric cardinality but changes debugging flows — you lose proxy-local tap-and-replay workflows and must instrument hosts and collectors accordingly.
- Feature surface and scale: Cilium's eBPF-first enforcement is cost-efficient for many L3–L7 use cases and reduces per-pod overhead; Istio Ambient is compelling when you need Envoy's extension ecosystem (Wasm, complex filter chains, or exact Envoy behavior) and when teams rely on that richer L7 feature set. Choose based on where you want to spend CPU and operator effort, not on ideology.
My take: this is the right direction, but it will force honest platform work that many teams are not budgeting for. Sidecarless meshes reduce infrastructure waste, but they shift complexity into kernel resource management, CRD-driven policy orchestration, and GitOps pipelines that actually understand how to reconcile dataplane state. If you treat sidecars as an implementation detail you can ignore, you're already behind.
If you run or operate clusters today: bake eBPF map pressure and Hubble collector scaling into your readiness tests, manage Cilium via your GitOps flow (HelmRepository/HelmRelease, Kustomization), and benchmark encrypted L7 paths with your real traffic shape before you rip out sidecars. Over the next 12 months expect greenfield clusters to default to sidecarless deployments; legacy apps will keep sidecars longer, but platform tooling will increasingly assume kernel-native enforcement as the baseline.
Final note: this isn't a turf war between Envoy and BPF. It's a shift in where the control plane's guarantees are enforced. Treat that shift as a platform-design decision — because it changes what you monitor, how you upgrade, and what failure modes you automate for.
Sources
- cilium/cilium GitHub repository (Releases – 1.19.5 latest)
- Cilium Service Mesh – Use cases (official Cilium docs)
- Cilium Service Mesh – Everything You Need to Know (Isovalent blog)
- Scaling in the Clouds: Istio Ambient vs. Cilium (Istio blog)
- Extending Sidecarless Applications with Wasm in Istio Ambient Mesh (Solo.io talk on YouTube)
- How to Deploy Cilium Service Mesh with Flux CD (OneUptime technical guide)