Cilium 1.20: Gateway API ExternalAuth, TCPRoute/UDPRoute, ENI IPAM for IPv6, and more

以下正文同步自 CNCF Blog，版权归原站所有，已转换为易读排版。

Cilium 1.20, the second major open source Cilium release of 2026 after Cilium 1.19, is finally here. Three themes stand out in this release:

- Gateway API becomes a much broader traffic management layer. Cilium jumps from Gateway API v1.4 to v1.6 and adds ExternalAuth, CORS filters, ListenerSets, and TCPRoute and UDPRoute for non-HTTP traffic. Platform and security teams can manage more of their north-south traffic through the same API, with authentication and authorization handled before a request reaches the application. If you are still running Ingress NGINX, now is the time to let the CNI you already run take on that traffic management too.

- Cilium becomes a platform that cloud providers can extend. Cilium is already a common networking foundation across hyperscalers and neoclouds. Datapath plugins, developed by Google, make Cilium less like a sealed networking appliance and more like a network operating system: a stable core that cloud providers can extend with their own eBPF programs, independently of the Cilium release cycle.

- Innovation and standardization move forward together. Cilium continues to push the datapath with innovations such as netkit, while aligning more closely with the wider Kubernetes ecosystem through stable MCS API support and Kubernetes ClusterNetworkPolicy. As capabilities Cilium supported early, including multi-cluster services and cluster-wide policy, take shape as upstream Kubernetes APIs, Cilium supports those APIs alongside its own established CRDs. Users get a choice between Cilium-native features and portable Kubernetes resources.

- choice between Cilium-native features and portable Kubernetes resources.

Thank you to every contributor, reviewer and maintainer who made Cilium 1.20 possible, including engineers from Datadog, Google, Microsoft and many other organisations across the Cilium community.

Networking

ENI IPAM mode with IPv6

One of the final gaps that stopped us from claiming feature parity across IPv4 and IPv6 in Cilium is gone. It even makes a footnote in Chapter 4 of Cilium: Up and Running redundant, and while we are a little sad that a note in the book is obsolete so soon after publication, we are glad that ENI mode on AWS finally supports IPv6, four years after the feature request was first raised.

Let’s recap. Up until now, running Cilium in AWS ENI IPAM mode (the AWS-specific mode that gives pods real VPC addresses) was only possible on IPv4. Now, as a beta feature in Cilium 1.20, ENI IPAM can allocate and hand out IPv6 as well. The operator attaches an IPv6 /80 prefix to each node’s ENI through Prefix Delegation (which we covered in detail in an earlier blog on how to overcome IP address exhaustion in Kubernetes), and the agent assigns pod addresses from it.

Enable ENI IPAM and IPv6 together:

ipam:

mode: eni

eni:

enabled: true

ipv6:

enabled: true

Pods on EKS then boot up dual-stack with VPC-routable IPv6:

NAME IPS

dualstack-demo-7f8876746b-5xvnk 192.168.128.71,2a05:d01c:38d:4c02:909e::e771

dualstack-demo-7f8876746b-8lj6z 192.168.177.118,2a05:d01c:38d:4c00:1cf5::57d1

dualstack-demo-7f8876746b-p84p7 192.168.169.190,2a05:d01c:38d:4c00:1cf5::f7ea

And here is the other side of it in the AWS console: the /80 IPv6 prefix delegated to a worker node’s ENI. The IPv6 address from the first pod above comes straight out of this 2a05:d01c:38d:4c02:909e::/80 range.

Kudos to the folks at Datadog, one of the most impactful organizations contributing to Cilium for years now, for building ENI IPv6 support and finally closing that gap. Watch the video for a short demo.

If you’d like to learn more about this feature, check the documentation for more information.

Automatic datapath mode selection (netkit auto)

In our post covering netkit, we described the newer pod network device as “The Final Frontier in Container Networking Performance”. You can call us out on the hyperbole, but since its release, Meta has rolled it out across millions of containers, while ByteDance has been deploying at a similar scale, reporting a 10% performance improvement in its tests.

The TL;DR on netkit is this: it replaces the traditional veth pair and its overhead, bringing pod networking performance to host-level throughput.

When it was initially released in Cilium, it needed a recent kernel (>= 6.8), so on a fleet with mixed kernel versions you either gave up on netkit everywhere or carved your nodes into pools by kernel version and configured them separately.

Cilium 1.20 adds bpf.datapathMode=auto: each agent probes its own host at startup, uses netkit when the kernel supports it, and quietly falls back to veth when it does not. That means you only need to configure one setting across a mixed fleet, making netkit easier to adopt across your environment. You can see which mode each node actually landed on through cilium-dbg status and the cilium_feature_datapath_config metric:

$ cilium-dbg status | grep Device

Device Mode: netkit [Configured: auto]

$ cilium-dbg metrics list | grep datapath_config

cilium_feature_datapath_config configured_mode=auto operational_mode=netkit 1.000000

While the default stays veth (meaning nothing changes until you opt in), we feel that the days of veth are numbered.

Check the documentation for more info.

Datapath Plugins

Previously, extending or instrumenting Cilium’s eBPF datapath beyond what the project already supported left you with two hard options: upstream your change, or maintain a fork. Both are high-effort, and a fork means carrying datapath patches across every Cilium upgrade.

While most end-users just use the off-the-shelf Cilium, some cloud providers – like Google, the authors of this new feature – would manage their own Cilium fork, with the maintenance efforts it comes up with.

Now, Cilium 1.20 introduces datapath plugins (beta): third-party code can instrument Cilium’s eBPF datapath as its own plugin, running as a separate process that Cilium reaches out to, without patching or forking Cilium itself. Because a plugin is its own image, it is built, versioned and rolled out on its own cadence and can be upgraded independently of Cilium. And because it runs on its own, a plugin crash does not take the agent down with it. It opens the door to specialised observability, security and networking extensions that ship and evolve independently of the Cilium release cycle, with no fork required.

A plugin registers itself with Cilium through a deliberately small CiliumDatapathPlugin custom resource:

apiVersion: cilium.io/v2alpha1

kind: CiliumDatapathPlugin

metadata:

name: example

spec:

# Fail closed if Cilium cannot reach the plugin.

attachmentPolicy: Always

# Bump this to reinitialise the datapath for a new plugin release.

version: 0.0.

Thanks to jrife for the feature.

If you’d like to learn more about this feature, check the documentation for more information.

Per-pod disable source IP verification

By default, Cilium enforces source IP verification: a pod may only send packets whose source IP matches its own. This stops a compromised or misbehaving pod from spoofing another workload’s address. There are – admittedly rare – circumstances where some workloads legitimately need to emit packets with a different source IP: for example, NAT gateways, firewalls and other appliance-style pods (such as VPN/Tailscale) .

Until now, source IP verification was a single cluster-wide switch (enable-source-ip-verification, on by default) with no per-pod control – so letting one workload use a foreign source IP meant turning it off for the entire cluster, weakening anti-spoofing everywhere.

Cilium 1.20 makes it a per-pod, opt-in decision, gated at two levels. First, a cluster administrator permits it for a namespace by annotating the namespace with config.cilium.io/delegate-source-ip-verification: “true”. Only then can a pod owner opt a specific workload out of source IP verification by annotating it with config.cilium.io/disable-source-ip-verification: “true”. Both annotations are required, so a namespace owner cannot quietly turn anti-spoofing off on their own, and the protection stays on everywhere else. This feature solves a problem for the workloads that need it, but make sure to use Kubernetes RBAC to restrict who can modify namespace annotations, so you don’t accidentally reduce your security posture.

If you’d like to learn more about this feature, check the documentation for more information.

Migrate cluster-pool IPAM to multi-pool IPAM

Multi-pool IPAM is steadily becoming the preferred way to hand out pod IPs in Cilium. Instead of drawing every address from one flat cluster-wide range, you carve the space into named pools and assign them where you want them – per namespace, per workload, per tenant. What had been difficult until now was the migration from the default cluster scope mode. Until now, if your cluster was already running cluster-scope IPAM, moving to multi-pool meant standing up a fresh cluster and migrating workloads across, which is not something anyone wants to do on a live platform.

Cilium 1.20 adds an in-place migration path. You can switch an existing cluster from cluster-pool to multi-pool, with no rebuild and no re-IP’ing, by using the operator option enable-cluster-pool-to-multi-pool-migration. Check out the migration documentation for more info.

Traffic distribution PreferSameZone / PreferSameNode

Introduced in Cilium 1.16, Service Traffic Distribution became the preferred method for keeping Service traffic close to its client, replacing the older topology-aware hints method. Service Traffic Distribution enables users to reduce latency and avoid cross-zone data-transfer charges, as Dean covered in this excellent post.

Until now, Cilium only supported the PreferClose value, indicating a preference for routing traffic to endpoints that are topologically proximate to the client.

In Cilium 1.20, Cilium honours recent changes to the upstream Kubernetes trafficDistribution specification and now supports two newer values. PreferSameZone keeps traffic within the client’s zone while a healthy backend is available there, and PreferSameNode prefers a backend on the very same node.

apiVersion: v1

kind: Service

metadata:

name: frontend

spec:

trafficDistribution: PreferSameZone

selector:

app: frontend

ports:

- protocol: TCP

port: 80

targetPort: 80

type: ClusterIP

Both values gracefully fall back to the rest of the cluster’s backends when no local one is healthy, so you get the locality benefit without trading away availability. Because this is the standard Kubernetes field rather than a Cilium-specific annotation, the same Service spec behaves consistently across conformant implementations.

Check the official Kubernetes documentation for more information on service traffic distribution.

EndpointSlice weights for Maglev backends

Cilium has supported Maglev as its load balancer hashing mechanism since Cilium 1.10. Originated at Google and named after the Japanese magnetic levitation train, Maglev provides consistent hashing to minimize disruption during node or backend changes (you can find more information about Maglev and other performance optimization features in Chapter 8 of Cilium Up and Running).

In prior releases, there was no supported way to give some backends of a Service a larger share of Maglev traffic than others, or to gracefully drain a group of backends. Traffic was evenly distributed across all available backends.

Now, Cilium 1.20 reads a service.cilium.io/weight annotation directly off the EndpointSlice. The weight applies to every backend in that slice, with valid values running from 0 to 65535 (note the weights are relative, so they do not need to add up to 100). This is aimed squarely at selectorless Services backed by several manually managed EndpointSlice objects, where each slice can carry a different weight: a classic weighted split such as 70/30 across two slices becomes a two line annotation change.

apiVersion: v1

kind: Service

metadata:

name: example-service

annotations:

service.cilium.io/lb-algorith

正文由 FLUX 从来源站点 RSS 同步，内容未经改写；遇到排版缺失或需要图片、视频时请以原文为准。