Cilium1.20正式发布，扩展GatewayAPI支持并开放eBPF数据路径插件机制

Cilium 1.20 已正式发布，标志着该项目在 Kubernetes 网络层的演进迈入新阶段。本次更新聚焦四大方向：更全面的 Gateway API 支持、可扩展的 eBPF 数据路径、混合内核环境下的数据路径自动适配，以及无 sidecar 模式的双向 TLS（ztunnel）能力增强。这些改进共同指向一个目标——让 Cilium 从单一的容器网络接口（CNI）组件，逐步发展为覆盖服务网格、网关与底层数据平面的统一网络平台。

Gateway API 升级至 1.6，覆盖 HTTP 与非 HTTP 流量

Cilium 将 Gateway API 支持从 1.4 版本升级至 1.6，新增多项关键资源类型与功能。其中，ExternalAuth 允许 HTTPRoute 在请求抵达应用前调用外部授权服务，根据响应结果决定是否转发、重定向或拒绝请求，并可将身份标识头透传至后端应用。该机制显著简化了零信任架构下认证授权流程的部署复杂度。

TCPRoute 与 UDPRoute 的引入则填补了此前 Gateway API 在四层流量管理上的空白。过去，数据库、DNS 或其他非 HTTP 服务往往需依赖 LoadBalancer 或 NodePort 类型 Service 实现暴露；如今，这些服务可直接通过 Gateway API 统一配置，实现策略与声明式管理的一致性。

ListenerSets 是另一项重要补充，它解决了多团队协作中的权限边界问题：平台团队仍掌控共享网关的生命周期与准入控制，而应用团队可在自身命名空间中动态添加监听器（Listener），无需等待平台侧集中变更。LinkedIn 平台工程师 Mohamed Salem BEN ATAIA 指出，这一设计“消除了平台的一个瓶颈”，使路由配置真正实现自助化。

值得注意的是，Cilium 的 Gateway 实现并非仅作为附加功能，而是与其 CNI、服务网格等模块深度集成。同一套代码库即可提供网络连接、负载均衡与流量治理能力，避免了传统方案中多个控制器协同带来的配置冲突与运维负担。亚马逊云科技已在其负载均衡控制器中支持 Gateway API，但其方案需分别使用 ALB 和 NLB 实现不同协议支持；相比之下，Cilium 以单一项目统一处理，架构更为紧凑。

首次开放 eBPF 数据路径插件机制

Cilium 1.20 最具突破性的变化在于向第三方开放 eBPF 数据路径的扩展能力。此前，若云服务商或企业希望定制监控指标、QoS 策略或安全检测逻辑，必须修改上游代码或维护独立分支，升级成本高且易与主线脱节。

新版本引入的 Datapath Plugin 机制改变了这一局面：插件作为独立进程运行，通过小型自定义资源（Custom Resource）注册，并经由 gRPC 接口与 Cilium Agent 通信。插件可在数据包进入或离开 eBPF 程序前后插入 PRE hook 与 POST hook，执行自定义 BPF 字节码逻辑。例如，谷歌开发的参考插件即演示了如何在不侵入核心代码的前提下，实现细粒度流量追踪与统计。

该机制目前处于 Beta 阶段，官方明确提示其面向“对 Cilium 内部机制有深入了解的运维人员”，而非普通集群用户。文档强调，插件可能引发稳定性风险或削弱安全隔离，且需随 Cilium 内核演进持续维护。尽管如此，这一设计标志着 Cilium 正从“封闭式网络设备”转向“可编程网络操作系统”范式——类似 Linux 内核模块化思想在网络数据面的延伸。

自动适配 netkit 与 veth 数据路径

为缓解 Kubernetes 集群中因节点内核版本差异导致的兼容性问题，Cilium 1.20 引入了 Pod 数据路径自动选择功能。当配置 bpf.datapathMode: auto 后，每个 Cilium Agent 启动时将探测宿主机内核版本：若为 Linux 6.8 或更高，则启用基于 netkit 的高性能路径；否则回退至传统的 veth 对方案。

netkit 是一种新型内核网络设备，旨在替代传统 veth pair，减少上下文切换与内存拷贝开销，提升吞吐与延迟表现。但其依赖较新的内核特性，因此默认模式仍为 veth，确保现有集群无感知升级。该设计避免了运维人员为适配新特性而被迫将混合内核集群拆分为独立节点池的工程困境。

ztunnel 增强：无 sidecar 双向 TLS 的实用化推进

ztunnel 是 Cilium 1.19 中引入的 per-node 代理，用于在无 sidecar 模式下实现工作负载间双向 TLS（mTLS）。1.20 版本进一步完善其能力：支持用户在内部 CA 与 SPIRE 签发的工作负载身份之间灵活切换；新增 Prometheus 指标用于监控注册状态与连接健康度；并在 HBONE 隧道建立过程中优化 TLS 1.3 握手流程，支持连接复用与快速重连。

这一进展对大规模服务网格部署意义重大。sidecar 模式虽成熟，但带来约 10%~20% 的资源开销与复杂性；ztunnel 通过节点级代理降低侵入性，更适合对资源敏感或需快速迭代的场景。随着 Istio 社区对无 sidecar 模式的持续投入，Cilium 的 ztunnel 实现正成为该路径的重要技术选项。

行业背景：Gateway API 成为 Kubernetes 网络标准演进方向

Cilium 的此次更新并非孤立动作，而是顺应 Kubernetes 生态整体迁移趋势。Ingress API 因功能局限与扩展性不足已被社区逐步淘汰，Kubernetes 官方推荐采用 Gateway API 作为下一代流量入口标准。截至 2026 年，包括 Traefik、HAProxy、AWS Load Balancer Controller 在内的主流方案均已提供不同程度支持。

然而，多数实现仍局限于“网关控制器”角色，需与其他 CNI 或服务网格组件配合使用；Cilium 则试图以一体化架构打破模块割裂。这种整合优势在边缘计算、多云混合部署等复杂场景中尤为明显——单一控制平面即可管理从 Pod 网络到南北向流量的全链路策略。

从技术演进看，eBPF 正从“内核观测工具”走向“网络基础设施核心”。Cilium 作为最早系统化应用 eBPF 的项目之一，其插件化尝试为行业提供了可复用的扩展范式。未来，随着更多厂商接入该插件体系，或将催生围绕 eBPF 数据面的第三方生态，类似早期 Linux 内核模块生态的发展路径。

Cilium 1.20 的发布，标志着云原生网络正从“能用”迈向“好用”与“可定制”。在微服务规模持续膨胀、安全合规要求日益严苛的背景下，这种兼具统一性与开放性的架构设计，或将加速 Kubernetes 网络层的标准化进程。