Cilium 1.20：从七层网关扩展到 TCP、UDP 与 IPv6 ENI IPAM

预计阅读时间：8 分钟

Cilium 1.20 已发布，作为 2026 年继 Cilium 1.19 之后的第二个主要开源版本，它把网络能力继续向 Gateway API 和云原生基础设施的边界推进。这个版本最值得关注的方向有三个：Gateway API ExternalAuth、TCPRoute/UDPRoute，以及面向 IPv6 的 ENI IPAM。

这些变化并不是简单增加几个 API 类型，而是让 Cilium 更适合承担集群入口、东西向流量治理和云网络地址分配等职责。升级时，建议把它当作一次能力评估，而不只是一次镜像替换。

Gateway API 不再局限于 HTTP

在很多 Kubernetes 集群中，Gateway API 已经逐步取代传统 Ingress，原因是它把流量入口、监听器、路由和后端服务拆成了更清晰的资源。Cilium 1.20 继续扩大这条路线：

ExternalAuth：为网关流量接入外部鉴权服务，适合统一认证、租户校验或策略检查。
TCPRoute：为非 HTTP 的 TCP 服务提供路由能力，例如数据库代理、消息队列或自定义 TCP 协议。
UDPRoute：覆盖 DNS、实时通信和其他基于 UDP 的服务。

这意味着入口层不必再为每一种协议维护完全不同的实现。可以用 Gateway 统一描述监听端口，再根据协议选择对应的 Route。

不过，ExternalAuth 的具体字段和支持范围应以所安装的 Cilium 1.20 CRD 及其 Gateway API 实现为准。生产环境不要直接把其他网关控制器的扩展字段复制过来；先检查 CRD、控制器日志和 status 条件。

一个可改造的 Gateway API 示例

下面的示例展示了一个 TCP 和 UDP 监听器，以及对应的路由。它假设集群中已经安装了 Cilium 1.20，并且 Cilium Gateway API 控制器使用名为 cilium 的 GatewayClass。不同安装方式可能使用不同的 GatewayClass 名称，应用前请用 kubectl get gatewayclass 确认。

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: edge-gateway
  namespace: edge
spec:
  gatewayClassName: cilium
  listeners:
    - name: tcp-app
      protocol: TCP
      port: 9000
      allowedRoutes:
        namespaces:
          from: Same
    - name: udp-dns
      protocol: UDP
      port: 5353
      allowedRoutes:
        namespaces:
          from: Same
---
apiVersion: gateway.networking.k8s.io/v1alpha2
kind: TCPRoute
metadata:
  name: app-tcp
  namespace: edge
spec:
  parentRefs:
    - name: edge-gateway
      sectionName: tcp-app
  rules:
    - backendRefs:
        - name: tcp-service
          port: 9000
---
apiVersion: gateway.networking.k8s.io/v1alpha2
kind: UDPRoute
metadata:
  name: dns-udp
  namespace: edge
spec:
  parentRefs:
    - name: edge-gateway
      sectionName: udp-dns
  rules:
    - backendRefs:
        - name: dns-service
          port: 5353

运行前准备命名空间和后端 Service，然后查看资源状态：

kubectl create namespace edge
kubectl apply -f gateway-routes.yaml
kubectl get gateway,tcproute,udproute -n edge
kubectl describe gateway edge-gateway -n edge

这个示例的重点不是复制 YAML 后立即用于生产，而是验证三件事：GatewayClass 是否正确、集群是否安装了相应的 Gateway API CRD，以及路由的 status 是否显示已绑定到监听器。若要加入 ExternalAuth，应先依据 Cilium 1.20 实际安装的 CRD 定义补充鉴权策略，并确认失败时采用拒绝请求还是降级放行。

IPv6 场景下重新审视 ENI IPAM

对运行在云厂商弹性网络接口（ENI）上的 Kubernetes 集群来说，IPAM 决定了 Pod 地址从哪里来、如何分配，以及地址耗尽时系统如何表现。Cilium 1.20 将 ENI IPAM 对 IPv6 的支持列为重要能力，这对双栈和 IPv6 优先集群尤其有价值。

采用 IPv6 ENI IPAM 时，需要同步检查：

云 VPC 或子网是否启用了 IPv6，并且 ENI 能够获得 IPv6 地址。
节点实例、路由表、安全组和网络 ACL 是否允许 Pod 使用的 IPv6 流量。
Pod CIDR、节点数量和地址池规模是否匹配，避免控制面显示启用 IPv6，但实际地址池很快耗尽。
外部负载均衡器、DNS、监控和审计系统是否真正支持 IPv6，而不只是 Kubernetes API 支持。

可以用 Helm 参数表达一个安装方向，但实际参数名称仍应以 Cilium 1.20 chart 的 values.yaml 为准：

helm repo add cilium https://helm.cilium.io
helm repo update

helm upgrade --install cilium cilium/cilium \
  --namespace kube-system \
  --create-namespace \
  --version 1.20.0 \
  --set ipam.mode=eni \
  --set ipv6.enabled=true

cilium status --wait
kubectl -n kube-system get pods -l k8s-app=cilium

这不是一条可以脱离云环境直接执行的通用升级命令。ENI IPAM 还依赖云平台权限、子网地址容量和 Cilium 对应的云集成配置。建议先在测试集群验证新节点加入、Pod 创建、节点重启和地址回收，再扩大范围。

升级时不要只看 Pod 是否 Running

Cilium 1.20 的价值集中在网络数据面与控制面协作，因此升级验收需要覆盖真实流量，而不仅是 DaemonSet 是否全部变成 Ready：

检查 Gateway、TCPRoute、UDPRoute 的 status.conditions。
验证 TCP 长连接在网关重启或后端切换时的行为。
验证 UDP 丢包、超时和大包场景，不要只用一次成功的 nc 测试。
在 IPv6 ENI IPAM 环境中确认 Pod 地址分配、节点重启后的恢复和地址回收。
检查 ExternalAuth 服务不可用时的安全策略，避免鉴权故障变成意外放行。
记录升级前后的延迟、连接数、丢包率和地址池使用率。

采用建议

如果当前集群只运行普通 HTTP Ingress，Cilium 1.20 的 TCPRoute、UDPRoute 和 ExternalAuth 可以作为逐步迁移的理由，但不必为了新 API 立刻改造所有入口。先挑选一条低风险业务验证 Gateway API，再迁移非 HTTP 协议。

如果集群运行在支持 IPv6 ENI 的云环境，升级前应把 IPAM 当作容量和权限项目评审，而不是单纯的 Cilium 配置项。最稳妥的路径是：

在预生产集群确认 Cilium 1.20 与当前 Kubernetes 版本兼容。
导出并审查现有 CRD、Helm values 和云 IAM 权限。
用一组 TCP、UDP、IPv4 和 IPv6 流量做回归测试。
逐步升级节点池，并保留回滚所需的旧镜像、配置和观测数据。

Cilium 1.20 的核心信号很明确：Kubernetes 网络入口正在从“只处理 HTTP”走向多协议和策略化，而 IPv6 也开始进入云原生 IPAM 的日常运维范围。真正的收益取决于团队是否同时补齐协议测试、地址容量规划和故障策略。