Cilium 1.20 has arrived with a wider Gateway API surface, a more open eBPF datapath for Kubernetes, and further progress on sidecarless mutual TLS. The release also makes it easier to roll out the newer netkit network device across Kubernetes fleets running mixed Linux kernel versions.
Cilium 1.20 broadens Gateway API support
In the release announcement, Cilium engineers Nico Vibert and Donia Chaiehloudj described Gateway API as a “much broader traffic management layer” in version 1.20. The project moves from Gateway API 1.4 to 1.6 and adds ExternalAuth, ListenerSets, CORS filtering, TCPRoute and UDPRoute.
Those additions bring more than web traffic into the same Kubernetes API that already handles HTTP and gRPC. In practice, they let operators manage authentication and routing for non-HTTP services such as databases and DNS without falling back to separate Service types for every case.
ExternalAuth, TCPRoute and UDPRoute
ExternalAuth lets an HTTPRoute consult an external authorization service before forwarding a request to an application. Depending on the response, the gateway can allow the request through, send the user to a login page, or reject it outright. The authorizer can also pass identity headers to the application.
TCPRoute and UDPRoute fill another gap by covering plain Layer 4 traffic. That removes the need to rely on LoadBalancer or NodePort Services when a team wants to route TCP or UDP traffic through the same Kubernetes-native control plane.
ListenerSets are aimed at shared ownership
ListenerSets address a common platform issue: who gets to add new listeners to a shared gateway. With ListenerSets, application teams can add listeners from their own namespaces while a platform team keeps control of the shared Gateway and decides which namespaces may extend it.
Platform engineer Mohamed Salem BEN ATAIA wrote on LinkedIn that ListenerSets close the gap between teams owning Routes and needing a central change for a new hostname or port. In his assessment, “It removes a platform bottleneck.”
An extensible eBPF datapath, but not for everyone
The second major change in Cilium 1.20 opens its eBPF datapath to third-party plugins. Previously, cloud providers or other operators that wanted custom instrumentation or networking behavior had to push changes upstream or maintain a fork. Now a plugin can run as a separate process, be built and versioned independently, and be upgraded on its own schedule.
Cilium communicates with the plugin through a small custom resource and a gRPC interface. Vibert and Chaiehloudj described the shift as making Cilium “less like a sealed networking appliance and more like a network operating system.”
The plugin mechanism is in beta and is not being positioned as a general extension framework for ordinary cluster users. Cilium’s documentation says it is intended for operators with detailed knowledge of Cilium internals. It also warns that a plugin can break Cilium or weaken security, and that maintainers may need to update their code as the project’s internal architecture changes.
Netkit becomes easier to adopt in mixed fleets
Cilium 1.20 also introduces automatic selection of the pod datapath. When operators set bpf.datapathMode=auto, each agent checks its host at startup, uses netkit where the kernel supports it, and falls back to the traditional veth pair elsewhere.
Netkit requires Linux 6.8 or later, while the default remains veth. That means existing installations do not change unless an operator opts in. The goal, according to Vibert and Chaiehloudj, is to avoid splitting mixed fleets into separate node pools simply to pick a datapath mode.
Sidecarless mutual TLS gets another step forward
The fourth major area in the release is ztunnel, the per-node proxy introduced in Cilium 1.19 for sidecarless mutual TLS. Version 1.20 adds a choice between an internal certificate authority and SPIRE-issued workload identities, along with Prometheus metrics for enrollment and connection health.
Cilium says ztunnel now holds a new connection while it establishes TLS 1.3 over an HBONE tunnel. That avoids the first-packet loss possible with Cilium’s older mutual-authentication design and encrypts supported TCP traffic between pods on the same node.
How it fits into the wider Kubernetes networking shift
The release lands at a time when Kubernetes networking is moving further toward Gateway API. InfoQ has previously reported that the Kubernetes community recommends Gateway API as organizations move away from the retired Ingress NGINX controller. AWS has also reached general availability with Gateway API support in its Load Balancer Controller, covering HTTP and gRPC through Application Load Balancer and TCP and UDP through Network Load Balancer.
Cilium’s implementation is notable because the same project can provide the CNI, service networking and gateway functions. That broader scope is part of what makes the 1.20 release significant for operators evaluating whether to centralize more of their networking stack.
Upgrade considerations
Cilium’s ztunnel remains beta, and its older Mutual Authentication feature is now deprecated. The release notes also call out possible action for users of legacy Mutual Authentication, Kafka-aware policies, Envoy Go extensions, custom CNI configuration and several deprecated APIs.
For operators, the practical takeaway is that Cilium 1.20 is not just a feature bump. It expands the platform’s traffic-management model, introduces a controlled way to extend the datapath, and gives mixed Kubernetes fleets a gentler path to newer kernel-dependent networking features.
Source: Original report
Was this helpful?
Explore more: DevOps Services More Cloud & DevOps Tech News
Last Modified: October 21, 2026 at 10:32 pm
0 views
