Cilium Helm + GitOps: eBPF Service Mesh Install Patterns (1.17+)

The most useful part of the recent Cilium content isn't a new API — it's the playbook. Production tutorials for Cilium 1.17 and later show you how to install a kube-proxy-replacing, eBPF-based service mesh with Helm, wire up Hubble for observability, expose north–south traffic with Gateway API/ingress, and then manage all of it from Git using Argo CD or Flux. That sounds incremental, but for platform teams it changes the operational model: Cilium can be treated like a versioned, auditable control plane component rather than a half-baked CNI you tweak ad hoc on clusters.

What these docs and sample repos make explicit is the recommended rollout path: start with L3/L4 eBPF policies and kube-proxy replacement, enable Hubble for visibility, then add L7 and mTLS (SPIRE-based mTLS is a common example) once you’ve validated connectivity and telemetry. This staged approach is exactly right. Teams that try to flip on L7 policies and ambient mTLS on day one consistently get entangled in opaque failures — eBPF datapath changes can surface in surprising places. (If you worried about datapath stability, recall the datapath fixes in the 1.16.x series: the datapath matters.)

Helm-first, GitOps-second

The practical artifacts matter: there are Helm value sets and example manifests showing how to set kubeProxyReplacement="strict", enable Hubble, and configure ingressController for dedicated load-balancer behavior and privileged port bindings in current release branches. Those Helm charts are what teams commit to Git. The GitOps recipes use Flux primitives (HelmRepository + HelmRelease or Kustomization) or Argo CD Applications that pass Helm values, with health checks attached to the cilium DaemonSet so a bad values roll doesn't silently bring down node networking.

A tiny Helm values snippet most teams will recognize:

kubeProxyReplacement: "strict"
hubble:
  enabled: true
ingressController:
  enabled: true
# actual flags for socket LB, CNI chaining, and privileged ports vary by chart version

The Helm values that keep reappearing in integration guides are the knobs you use to avoid surprising interactions with other control planes. In practice you limit where Cilium's socket-based load balancing runs, choose the CNI chaining or exclusivity model that matches your cluster, and explicitly eject or include workloads from other meshes when you want Cilium to handle L7 policy.

Coexistence with Istio (and why it’s tricky)

If you're running Istio, the docs call out the values and topology decisions you need: limit Cilium's socket LB to host namespaces or specific nodes, choose a non-exclusive CNI chaining mode if you need multiple CNIs, and selectively eject workloads from Istio's ambient mesh when you want Cilium to enforce L7 policy for those pods. The upshot: you can run both — but you must plan trust and policy boundaries. My take: platform teams that treat Cilium and Istio as one magical stack will be unpleasantly surprised; it’s better to define which layer handles what and codify that in your GitOps manifests.

Multi-cluster and ClusterMesh

ClusterMesh examples show a practical path for cross-cluster service mesh: automate ClusterMesh values generation (people use scripts or simple automation tools), distribute certificates, and then restart Cilium agents so they pick up new ClusterMesh certs. This is not a one-click solution, but it’s repeatable and fits neatly into an ops repo. If your topology needs cross-cluster pod-to-pod connectivity for mesh workloads, this is the pattern you’ll use.

The real implication

Cilium’s Helm + GitOps story is now operable at scale. That means platform teams must treat Cilium like any other core control plane (versioned, tested, rollout-gated) and adopt the L3/L4-first progression. If you’re still treating kube-proxy as an immutable baseline in 2026, you’re missing out on an operational simplification: eBPF-based service discovery and LB reduce hop count and complexity — when done carefully. Teams that ignore the coexistence rules with Istio or that try to turn on L7/mTLS immediately will be the ones paging at 2 a.m.

Final thought: this is overdue. The ecosystem is moving from experimental eBPF proof-of-concepts to opinionated, repeatable installation patterns managed by Git. If you manage platform deliverables, make Cilium Helm values and health checks part of your infra repo this quarter — otherwise you’ll be rebuilding those runbooks under pressure later.

Cilium Helm + GitOps: eBPF Service Mesh Install Patterns (1.17+)

Sources

Helm 4.x: Wasm-based plugins, OCI digest pinning, and observability chart updates

Helm 4.2.2 Stable: Observability Charts Take Center Stage with Grafana Mimir Helm Chart v6.0

Cilium 1.16.2: datapath eBPF stability fixes for production clusters