Cilium 1.17's tutorial does something blunt: it ships a concrete, Helm-first path that turns eBPF + Envoy into a real production mesh. The defaults? kube-proxy replacement, Hubble enabled, Envoy-based L7, encryption by default and an option to use SPIRE-backed mTLS — plus Hubble export to OpenTelemetry. That's an operational stance.
Why this is different: previous eBPF messaging often focused on fast L3/L4 filtering. Cilium 1.17 explicitly ties eBPF dataplane capabilities to Envoy for L7 and to SPIRE for identity — and it treats Hubble as a first-class telemetry export path. When the docs provide an end-to-end Helm flow that wires SPIRE, Hubble, and OpenTelemetry together, you're not looking at an experiment anymore. You're looking at a migration blueprint.
Istio isn't standing still. The ambient mesh docs also tilt Helm-first: install the CNI, the ztunnel DaemonSet, optional ingress gateways — and note the requirement to install Gateway API CRDs (supported Gateway API versions vary by Istio release). Ambient Istio + Gateway API removes the sidecar from the request path but increases the importance of carefully scoped CRDs and namespace boundaries. The practical result is more Helm charts, more CRDs, and more controller surface to manage — which is why CNCF and platform guidance pushing Helm as packaging and GitOps controllers for day-2 operations is timely.
The interoperable operational picture is messy but solvable. The Cilium <-> Istio integration docs call out concrete knobs that prevent collisions: the bpf-lb-sock-hostns-only flag, carefully scoped L7 policies, and selectively removing namespaces from ambient meshes. Those are the knobs you actually need during a progressive cutover (install Cilium next to Istio, run non-exclusive CNI, migrate namespaces one by one). It's not magic; it's choreography — and the tutorials lay out the steps, including using Hubble with OTLP/OpenTelemetry export to assert flows and identity during migration.
There are two platform-level implications that matter more than the feature list.
First: treat Helm as packaging, not runtime orchestration. Helm gets you a repeatable install and opinionated defaults; it should not be the long-term lifecycle controller for platform primitives. Use a GitOps controller (Argo CD or Flux) to drive day-2 state. The ecosystem saying this out loud is overdue — teams that still rely on manual helmfile/CI invocations for upgrades will hit surprises when CRDs change or when ambient mesh components require coordinated rollouts. This has been signaled in platform guidance advocating GitOps and treating Helm charts as artifacts, not runtime controllers.
Second: mixed meshes are now the realistic default path, not the exception. You'll run eBPF dataplane next to Istio; you'll scope ambient mesh namespaces; you'll flip SPIRE on for identity in sensitive namespaces and leave others on TLS-without-SPIRE. That flexibility is powerful, but it expands your operational surface: identity providers, OTel collectors, Hubble agents, Gateway API controllers, and Helm charts all need clear ownership and life-cycle rules.
Here's the blunt take: eBPF + Envoy is production ready. Platform teams that ignore it because "it sounds risky" will be left retrofitting security and telemetry later. But embracing it without clear GitOps practices, repo separation (platform vs app), and explicit collision-avoidance settings (bpf-lb-sock-hostns-only, namespace excision from ambient mesh) is asking for outages.
If you're planning a migration: install Cilium alongside Istio with non-exclusive CNI, enable Hubble and OTLP/OTel exports, carve a small namespace and cut it over, validate with traces and flow logs, and iterate. This week’s docs are a pragmatic blueprint for that path — follow it, and you won't be guessing where packets go.
Expect the next 12 months to look like a lot more mixed deployments and a lot fewer all-or-nothing mesh debates. The interesting battle will be platform governance: which controller owns service-level policy, who manages identities, and how teams separate Helm packaging from GitOps-driven lifecycle. Get that right now and the migration will be boring; get it wrong and you'll be in a support rotation reconciling identities and CRD changes.
For further reading on running eBPF meshes and sidecarless upgrades see the Cilium docs and release notes for 1.17+ and the broader Helm vs. GitOps lifecycle conversations.