Cilium 1.18 Turns the CNI into a Full Network Security Platform for Kubernetes

July 29, 2025. The Cilium team ships version 1.18 with 3,298 commits, 955 contributors, and one unambiguous signal: this is no longer just a CNI plugin. Load Balancing redesign, native overlay encryption, ingress bandwidth control, Gateway API v1.3.0, and Mutual Authentication (mTLS) without sidecars — the release checks every box of a network platform.

July 2026. Cilium is the default CNI on GKE, AKS, and EKS. Istio pushes its sidecar-free Ambient mode. Calico bets on AI-assisted operations. But with 1.18, Cilium set a milestone the competition hasn’t matched: it no longer just routes packets — it is the network and security control plane for the cluster.

What Cilium 1.18 Actually Delivers

The release is massive. Five workstreams shift the landscape.

Load Balancing: A Ground-Up Rewrite

The service load-balancing control plane inside the Cilium agent was completely redesigned. The direct payoff: 45% faster policy and service application at scale. Agent memory consumption drops measurably, freeing node resources for actual workloads.

The rewrite was led by Jussi Mäki and Damian Sawicki (Isovalent/Cisco), documented in PR #38469. The architecture was designed for extensibility — future load-balancing features will integrate without another rewrite cycle.

Native Overlay Encryption (VinE)

Cilium 1.18 introduces VXLAN in IPsec (VinE) — transparent encryption of overlay traffic with no additional tunnel overhead. In practice: inter-node VXLAN traffic gets automatically encrypted via kernel-level IPsec, with zero sidecar containers, zero user-space proxies. All backed by eBPF-level performance.

This is critical for multi-tenant clusters or deployments spanning untrusted networks (public cloud, edge). It joins existing encryption modes: transparent WireGuard and classic IPsec.

Ingress Bandwidth Control

The Cilium bandwidth manager already handled egress rate limiting at the pod level. Version 1.18 adds ingress rate limiting — PR #36351. Platform teams can now define bidirectional bandwidth caps per pod, directly in network policies, with no application code changes.

Mutual Authentication (mTLS) Without Sidecars

This is Cilium’s most aggressive play against Istio. Since v1.14, Cilium has shipped beta Mutual Authentication based on SPIFFE/SPIRE. In 1.18, the feature firms up: the mTLS handshake between Cilium agents is stable, the authentication cache enables identity-level handshakes rather than per-connection, and integration with CiliumNetworkPolicy works end-to-end.

The difference versus Istio? Zero sidecars. Mutual authentication runs in the kernel via eBPF. No Envoy proxy per pod, no ztunnel DaemonSet to deploy, no waypoint proxy to configure for L7 policies. It is native to the CNI.

Caveat: the feature remains beta in 1.18 — WireGuard integration, per-connection handshake, and a formal security audit are on the roadmap. Version 1.20 (expected mid-2026) is slated to promote mTLS to stable.

Hubble: Observability Without External Agents

Hubble is not new, but 1.18 ships three game-changing improvements:

• Policy names in flows: hubble observe now shows which CiliumNetworkPolicy allowed or denied a flow. No more grepping YAML to trace a dropped packet to its rule.
• Free-text log field: each policy can carry an arbitrary text field, exposed in Hubble flows. It is a built-in search engine for your network control plane.
• Encapsulated traffic decoding: Hubble now peeks inside VXLAN and Geneve traffic, delivering full visibility even on encrypted overlays.

IPv6, BGP, Gateway API: The Foundation Widens

Version 1.18 is not just a security release. The networking foundation broadens on three fronts:

• IPv6: tunnel mode now supports an IPv6 underlay, including with IPsec encryption. Kube-proxy replacement works over IPv6 underlay. Egress Gateway policies match IPv6 address ranges.
• BGP: BGP CRDs graduate to stable API (v1). Route aggregation lands, alongside Router ID generation from MAC addresses or IP pools.
• Gateway API v1.3.0: native support for the Gateway API spec at v1.3.0, plus the CiliumGatewayClassConfig object enabling fine-grained GatewayClass tuning (source IP ranges, service type, parameters).

Cilium, Calico, Istio: How to Choose in 2026

By July 2026, the CNI and service mesh landscape has shifted substantially. Here is the lay of the land.

Cilium: The All-in-One Platform

Strengths: CNI + L3/L4/L7 network policies + service mesh + observability + encryption, all running in the kernel via eBPF. P99 latency of 0.9 ms in v1.18 (benchmarks from Calico v3.28 vs. Cilium v1.18). No sidecars, no per-pod user-space proxies. The fastest and most integrated option available.

Limitations: eBPF complexity (kernel-level debugging is non-trivial), mTLS still beta in 1.18, no fault injection or circuit breaking (present in Istio).

Istio Ambient: The L7 Specialist

Strengths: mature Envoy ecosystem, advanced L7 features (canary, fault injection, retries, circuit breaking), per-node ztunnel instead of per-pod sidecars. Ambient mode dramatically reduces memory overhead compared to the historical sidecar approach.

Limitations: requires an external CNI (Calico or Cilium underneath), two layers to maintain (ztunnel + waypoint), no Windows support.

Calico: Operational Simplicity

Strengths: straightforward deployment, standard Kubernetes NetworkPolicy without CRDs, AI Assistant (v3.31+) for natural-language troubleshooting, native BGP.

Limitations: no native L7 without additional CRDs, no integrated service mesh, higher latency than Cilium (iptables vs. eBPF).

Verdict

If your cluster already runs Cilium on an earlier version and you rely on load-balancing or network policies at scale, upgrading to 1.18 is a no-brainer — the 45% policy application speedup and lower memory footprint justify the move on their own.

If you are starting from scratch and network security is your top priority, Cilium 1.18 gives you a complete network control plane without stacking components: CNI, policies, encryption, observability, Gateway API, and mTLS in a single deployment. That is fewer YAML files to maintain than a Calico + Istio Ambient stack.

If you need advanced L7 (fault injection, circuit breaking, complex retries), Istio Ambient remains the best choice — but keep Cilium as the underlying CNI. The two are not mutually exclusive: Cilium officially documents Istio integration, including Ambient mode.

One year after release, Cilium 1.18 remains the marker of a category shift. It is no longer a CNI to compare against Flannel or Calico. It is a network platform that competes with Istio on service mesh, with Calico on policy, and wins on both when kernel-level performance matters.

References

• Cilium 1.18.0 Release Notes — GitHub, July 29, 2025
• Cilium 1.18 Blog Post — Isovalent — Isovalent/Cisco, August 7, 2025
• Cilium Mutual Authentication Documentation — docs.cilium.io
• Service Mesh: Istio vs Cilium vs Linkerd 2026 — Luca Berton, 2026
• Cilium vs Calico: The 2026 Kubernetes CNI Showdown — Sanj, March 2026
• Load Balancing Redesign — PR #38469 — cilium/cilium
• Ingress Rate Limiting — PR #36351 — cilium/cilium