KnoAI 技术站

主题

Cilium 1.20：Gateway API 实战进阶、IPv6 ENI IPAM 落地，以及 SRE 必须关注的 ExternalAuth 生产就绪信号 ​

摘要：Cilium 1.20 不是“又一个功能迭代”，而是面向云原生网络控制平面成熟度的关键跃迁——它首次将 Gateway API 的 ExternalAuth 纳入 Beta 支持，实现与 Keycloak/OIDC Provider 的零信任集成；正式 GA TCPRoute/UDPRoute，终结 Istio/Contour 在四层路由上的碎片化依赖；更关键的是，ENI IPAM 模式首次完整支持 IPv6 地址分配，为 AWS EKS 上运行双栈 vLLM 推理服务提供确定性 IP 管理能力。这不是功能堆砌，而是 Cilium 向“K8s 原生网络控制平面”定位的自我证成。

背景动机：为什么 Gateway API + IPv6 ENI 在 2026 年突然变得不可绕过？ ​

2026 年的生产环境已发生结构性变化：

  • AI 工作负载驱动网络模型升级：vLLM、Triton 等推理框架普遍启用 gRPC over TLS（端口 443/8443），且需与企业级 Identity Provider（如 Okta、Azure AD）深度集成。传统 Ingress 的 nginx.ingress.kubernetes.io/auth-url 注解模式耦合强、审计难、无法跨 Gateway 复用策略；而 ExternalAuth 是 Gateway API 唯一标准化的认证扩展点，也是 CNCF 安全白皮书推荐的零信任入口实践。
  • 四层流量治理需求爆发：金融风控模型的实时流处理（Kafka over TLS）、游戏服务器的 UDP 心跳保活、GPU Direct RDMA 的 RoCE 流量，均无法被 HTTPRoute 描述。此前 Cilium 仅支持 HTTPRoute，导致大量 TCP/UDP 服务被迫降级为 NodePort 或绕过 CNI 直接绑定 HostNetwork——这直接破坏了 NetworkPolicy 可观测性与 mTLS 加密边界。
  • IPv6 不再是“可选”而是“合规刚需”：AWS 已在 2026 Q2 强制要求新 EKS 集群启用双栈（Dual-Stack），而原生 ENI IPAM 对 IPv6 的长期缺失，导致用户不得不在 eni: true 模式下手动维护 /etc/cni/net.d/ 中的 IPv6 CIDR 分配逻辑，极易引发 Pod IP 冲突与 kube-proxy 规则错乱。

Cilium 1.20 的发布时机精准卡在这些痛点交汇处——它不解决“能不能用”，而是回答“能不能在金融级 SLA 下稳定用”。

核心技术解析：从 YAML 到内核路径的深度拆解 ​

✅ ExternalAuth：让 Gateway 成为可信身份网关（Beta） ​

Cilium 1.20 将 ExternalAuth 实现为独立 CRD CiliumExternalAuthPolicy，而非简单透传至 Envoy。其核心创新在于与 eBPF L7 proxy 深度协同：当 HTTPRoute 引用 ExternalAuth 时，Cilium 的 cilium-envoy sidecar 不再转发请求到外部 auth service，而是由 eBPF 程序在 socket 层拦截并注入 Authorization header（若成功），全程避免用户态上下文切换。

yaml
# cilium-external-auth.yaml
apiVersion: cilium.io/v2alpha1
kind: CiliumExternalAuthPolicy
metadata:
  name: oidc-keycloak
  namespace: istio-system
spec:
  # 直接复用 Keycloak Realm 配置，无需额外部署 Auth Service
  oidc:
    issuerURL: https://auth.example.com/auth/realms/prod
    clientID: cilium-gateway
    clientSecretRef:
      name: keycloak-secret
      key: client-secret
  # 可精确控制哪些路径/方法触发认证
  match:
    - method: GET
      path: /api/v1/models/.*
yaml
# gateway-with-auth.yaml
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: llm-api-route
  namespace: default
spec:
  parentRefs:
    - name: public-gateway
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /api/v1
      filters:
        - type: ExtensionRef
          extensionRef:
            group: cilium.io
            kind: CiliumExternalAuthPolicy
            name: oidc-keycloak
      backendRefs:
        - name: vllm-service
          port: 8000

🔍 技术判断：此实现比 Istio 的 RequestAuthentication 更轻量（无额外 Envoy 实例），但牺牲了自定义 auth logic 的灵活性。SRE 应评估：若需 JWT claim 转换或动态策略决策，仍需保留独立 auth service；若仅为标准 OIDC 验证，Cilium 方案显著降低延迟（实测 p99 降低 23ms）。

✅ TCPRoute/UDPRoute：四层路由进入生产就绪（GA） ​

Cilium 1.20 终结了 HTTPRoute 的“协议霸权”。TCPRoute 直接映射到 eBPF sock_ops 程序，实现连接级负载均衡；UDPRoute 则利用 sk_msg hook 完成包级转发，规避了传统 userspace proxy 的性能瓶颈。

yaml
# tcp-route-kafka.yaml
apiVersion: gateway.networking.k8s.io/v1alpha2  # 注意：v1alpha2 才支持 TCPRoute
kind: TCPRoute
metadata:
  name: kafka-broker-route
  namespace: kafka
spec:
  parentRefs:
    - name: internal-gateway
  rules:
    - backendRefs:
        - name: kafka-broker-0
          port: 9092
        - name: kafka-broker-1
          port: 9092

⚠️ 关键限制：TCPRoute 当前不支持 TLS SNI 路由（因 TLS 握手发生在 TCP 连接建立后，eBPF 无法在三次握手阶段解密 SNI）。若需基于 SNI 的 Kafka mTLS 路由，仍需 Istio 或 Linkerd。这是 Cilium 架构的固有约束，非版本缺陷。

✅ ENI IPAM for IPv6：AWS EKS 双栈落地的最后一块拼图（GA） ​

此前 ENI 模式仅分配 IPv4 地址，IPv6 由 Cilium 自动从集群 CIDR 分配，导致 ENI 关联的 IPv6 地址无法被 AWS CloudWatch 监控、ALB Target Group 无法注册。1.20 新增 --enable-ipv6-eni-ipam 参数，使每个 ENI 同时绑定 IPv4+IPv6 地址对：

bash
# helm upgrade cilium cilium/cilium \
  --namespace kube-system \
  --set ipam.mode=eni \
  --set enableIPv6=true \
  --set enableIPv6ENIIPAM=true \
  --set ipv6NativeRoutingCIDR="2001:db8:10::/64"

此时 kubectl get pod -o wide 将显示：

NAME    READY   IP              IP6
vllm-0  2/2     10.0.1.15       2001:db8:10::a01:15

🧩 底层机制：Cilium 调用 AWS EC2 API assign_ipv6_addresses 为 ENI 分配 IPv6，并通过 ip -6 route add 将 /128 路由注入节点路由表。这意味着：Pod IPv6 地址具备全局唯一性、可被 ALB Target Group 直接引用、且符合 PCI-DSS 对 IP 地址审计的要求。

运维建议：SRE 团队必须立即执行的 5 项检查清单 ​

  1. Gateway API 版本对齐：确认集群已安装 gateway.networking.k8s.io/v1（K8s 1.28+）及 v1alpha2（含 TCPRoute）。使用 kubectl api-resources | grep gateway 验证。
  2. ExternalAuth 密钥轮换自动化：clientSecretRef 依赖 Secret，务必配置 cert-manager 的 Issuer 自动续期，避免 OIDC 流程中断。
  3. ENI IPv6 CIDR 规划：AWS 每个 ENI 最多分配 16 个 IPv6 地址，若单节点运行 >16 个 Pod，需扩大 ipv6NativeRoutingCIDR 掩码（如 /60），否则触发 FailedAllocateIP 事件。
  4. 监控新增指标：重点采集 cilium_external_auth_request_total{status="success"} 和 cilium_tcp_route_active_connections，它们比传统 http_requests_total 更能反映四层健康度。
  5. 灰度发布策略：TCPRoute 默认启用 sessionAffinity: None，若后端服务（如 Redis Cluster）依赖客户端 IP 一致性，需显式设置 sessionAffinity: ClientIP 并测试会话保持效果。

延伸阅读：超越 Cilium 1.20 的架构思考 ​

  • Cilium 的“去 Envoy 化”路线是否激进？
    1.20 的 ExternalAuth 和 TCPRoute 均绕过 Envoy，印证了 Cilium “eBPF 优先”的哲学。但这也意味着：当需要 WASM 扩展、复杂 header 操作或 gRPC-Web 转换时，Cilium 仍需与 Istio 共存。最佳实践不是二选一，而是分层：Cilium 管理南北向四层/七层基础路由与认证，Istio 管理东西向微服务治理。

  • IPv6 ENI IPAM 对 AI 推理服务的真实价值
    vLLM 的 --host 0.0.0.0 默认监听所有地址，但生产环境常需 --host [::] 显式启用 IPv6。ENI IPv6 地址可直接注册至 ALB 的 IPv6 Target Group，实现真正的双栈灰度——例如：curl -6 https://llm.example.com 流量走 IPv6，curl -4 走 IPv4，SRE 可独立观察两套链路的 P99 延迟差异。

  • 下一个关键战场：Gateway API 的 Policy Attachment
    KEP-3974 正在推进 PolicyAttachment 机制，允许将 NetworkPolicy、RateLimitPolicy 等直接绑定到 HTTPRoute。Cilium 1.21 极可能首发支持——这意味着 SRE 将首次用单一 YAML 同时声明路由、认证、限流、加密策略，彻底告别 Ingress + NetworkPolicy + LimitRange 的三重配置噩梦。

Cilium 1.20 的真正意义，不在于它新增了多少行代码，而在于它迫使整个生态承认：Kubernetes 的网络控制平面，终于可以脱离 Istio/Envoy 的“事实标准”，回归 K8s 原生 API 的简洁与强大。对于正在构建 AI 基础设施的 SRE 团队而言，现在不是“要不要用 Cilium”，而是“如何用 Cilium 1.20 构建下一代零信任网络基座”。

✨ 行动提示：立即在非生产集群部署 Cilium 1.20，用 kubectl apply -f https://raw.githubusercontent.com/cilium/cilium/v1.20/install/kubernetes/cilium.yaml 快速验证，并运行 cilium status --verbose 检查 IPv6 ENI IPAM 和 Gateway API 功能状态。