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

Cilium 1.20 shifts more Kubernetes traffic management into the Gateway API, a move that simplifies operations for platform teams. ExternalAuth and TCPRoute/UDPRoute allow authentication and non-HTTP traffic to be handled before requests reach applications, reducing the need for separate Ingress controllers. This consolidation means fewer moving parts, but teams already invested in Ingress NGINX or other controllers will face migration costs. The trade-off is clearer: adopt Gateway API for uniformity or maintain parallel systems for legacy compatibility. The release also aligns Cilium with Kubernetes-native resources like ClusterNetworkPolicy, offering a choice between Cilium-specific CRDs and portable upstream APIs. This dual support helps teams balance innovation with standardization, but adds complexity in deciding which path to prioritize for long-term maintainability.

The addition of IPv6 support in AWS ENI IPAM addresses a long-standing gap for teams running dual-stack clusters. Previously, ENI IPAM mode only worked with IPv4, forcing workarounds or separate IPAM solutions for IPv6. Now, pods on EKS can receive VPC-routable IPv6 addresses alongside IPv4, simplifying network design for environments requiring both protocols. However, this feature is still in beta, and teams should expect edge cases in production. The implementation relies on AWS Prefix Delegation, which may require adjustments to existing VPC configurations. For organizations already using Cilium in ENI mode, this change reduces operational friction, but those new to Cilium will need to evaluate whether the benefits outweigh the effort of switching IPAM modes.

Automatic datapath mode selection in Cilium 1.20 removes a key barrier to adopting netkit, the high-performance pod networking alternative to veth. Previously, netkit required manual node segmentation by kernel version, complicating rollouts across mixed fleets. Now, Cilium agents dynamically probe their host kernel at startup and fall back to veth if netkit isn’t supported. This simplifies configuration but introduces a new dependency: kernel compatibility. Teams running older kernels will still default to veth, missing out on netkit’s performance gains. The change also means monitoring becomes critical, admins need to track which nodes are using netkit versus veth to ensure consistent performance. For large-scale deployments, this feature reduces toil, but it doesn’t eliminate the need for kernel upgrades to fully leverage netkit’s benefits.