You can now put your service mesh under GitOps and stop pretending proxies are the only control plane you need. Recent examples show Flux CD sourcing Cilium’s Helm repo, creating HelmRelease objects for the agent, operator, Hubble, and mesh features, and wrapping those in Kustomization objects for reconciliation, health checks, and drift correction. That’s not a cute demo — it’s the operational pattern teams will use to manage an eBPF dataplane as code.
This matters because Cilium isn’t a drop-in replacement for Envoy sidecars in every respect. It shifts much of L3–L4 packet processing into the kernel via eBPF, and it provides observability hooks (Hubble) and policy enforcement at the datapath. For full L7 functionality — routing, TLS termination, and complex protocol handling — Cilium integrates with Envoy or uses specific eBPF-based helpers depending on configuration and feature-set. Flux managing HelmReleases for Cilium means the entire dataplane — agent, operator, and telemetry — can be reconciled from Git the same way you already do Deployments and CRDs.
There are real trade-offs. Istio’s Ambient mode and Cilium are converging on the same problem space (reduce per-pod proxies, retain L7 control), but benchmarks vary by workload and test methodology: some tests show Ambient-mode approaches lowering tail latency, while other measurements highlight Cilium’s efficiency in CPU usage for different traffic patterns. The right choice isn’t “which is better” — it’s “which trade-offs do you accept”: throughput vs CPU, centralized waypoint proxies vs kernel-local dataplane, and how you want to handle encryption and L7 extensibility.
WASM alters the calculus for Ambient-mode Istio: waypoint proxies can host WASM plugins (Proxy-WASM runtimes are common), so you get L7 extensibility without injecting or restarting application containers. That’s a clear win for teams needing dynamic L7 policies and telemetry. Cilium, meanwhile, continues to evolve its extensibility model around eBPF hooks and integrations that trade higher-level extensibility for lower-level efficiency.
Operational reality: GitOps makes lifecycle predictable, but the kernel is now part of your control plane. Flux will happily reconcile a HelmRelease that relies on specific eBPF features; it won’t upgrade your kernel, enable CO-RE, or resolve a conflicting CNI. Expect failure modes to move from "bad YAML" to "unsupported kernel feature set" and "node-level incompatibility."
Check these before you flip the switch:
- Node kernel and config: verify BPF CO-RE support, sufficient BPF program and map limits, and that your distro kernels provide the features Cilium requires. Newer Cilium features need modern kernels.
- CNI compatibility: ensure Cilium is deployed as the cluster CNI or otherwise that other CNIs and iptables/kube-proxy modes won’t interfere with Cilium’s datapath.
- Observability and policy: install Hubble and validate CiliumNetworkPolicy enforcement; use the cilium CLI to inspect status and loaded BPF programs. Useful commands include: cilium status --verbose cilium bpf list cilium monitor
- Reconciliation & health: include readiness/health checks for the Cilium DaemonSet and operator in your Flux Kustomization and HelmRelease manifests; treat them as high-priority health signals in GitOps alerts.
This is the right operational move: putting the mesh under Flux makes upgrades, rollbacks, and drift detection reliable. But it will bite teams that treat nodes as cattle without standardizing kernel versions, boot args, or distro images. If you run heterogeneous node pools or let teams install CNIs at will, you’ll see packet-flow bugs that look like "mesh" problems but are really kernel/compatibility failures.
One more implication that’s easy to miss: observability and security tooling must move from pod-level to node-level thinking. Hubble and cilium CLI diagnostics become as critical as Prometheus metrics for app owners. L7 telemetry will be available (via WASM plugins or Cilium’s integrations), but you must design where that telemetry is produced and stored — don’t assume it appears automatically because Flux applied a HelmRelease.
In the next 12 months we’ll see two things: GitOps-managed eBPF meshes becoming the default for teams optimizing for efficiency and scale, and a new class of platform work: kernel lifecycle management. If you’re building a platform, stop pretending node images are operational detail. Treat kernels, BPF feature-sets, and CNI contracts as first-class, versioned artifacts in your GitOps flow — or be prepared to debug the most expensive class of "infrastructure" bugs: those that only surface under load.
Sources
- How to Deploy Cilium Service Mesh with Flux CD - OneUptime
- Cilium Service Mesh - Everything You Need to Know - Isovalent
- Cilium Service Mesh Use Cases
- Scaling in the Clouds: Istio Ambient vs. Cilium
- Extending Sidecarless Applications with Wasm in Istio Ambient Mesh (talk)
- cilium/cilium GitHub repository