Cilium 对 Gateway API 的支持适合哪些入口场景

如果把 Cilium 只当成“另一个 Ingress Controller”，很容易低估它对 Gateway API 的影响。Cilium 官方文档给出的实现路径是：Gateway API 资源由 Cilium 控制器处理，入口流量进入 Cilium 的网络栈后，再由 eBPF 与 Envoy 配合承载 L7 流量。因此，它更适合已经把 Cilium 当作 CNI、并且希望入口策略和网络策略处在同一条数据路径上的集群。

官方文档地址：https://docs.cilium.io/en/stable/network/servicemesh/gateway-api/gateway-api/

先看它与普通入口控制器的模式差异

我在评估这类方案时，第一步不会看资源清单有多长，而会先问：入口流量是不是希望继续留在现有网络栈里。Cilium 文档明确指出，它的 Ingress 和 Gateway API 支持与 CNI 紧密结合，流量到达入口 Service 后，由 eBPF 代码拦截，再透明转发到 Envoy。这与“单独部署一个入口控制器，再由 Service 把流量送过去”的思路不同。

这条边界带来的实际价值，是入口流量可以和 Cilium 的网络策略一起被看待。文档把来自集群外部的流量通常标成 world，进入 Envoy 后又会落到特殊的 ingress 身份；因此策略设计不能只放行一个方向，还要同时考虑 world 到 ingress，以及 ingress 到后端工作负载的两段逻辑边界。

哪些入口场景更适合 Cilium Gateway API

第一个适配场景，是集群已经使用 Cilium，希望入口层不要再引入一套完全独立的数据路径。此时 Gateway API 的角色更像网络栈上方的声明接口：团队用 Gateway、HTTPRoute 或 GRPCRoute 表达入口关系，Cilium 负责把这些资源接到自己的 Envoy 与策略体系里。官方稳定文档也列出了 TLSRoute、BackendTLSPolicy、ReferenceGrant 等资源，但具体是否启用某类能力，仍要按对应 CRD 和版本说明核对。

第二个场景，是入口和东西向流量需要使用相近的 L7 策略边界。Cilium 文档说明，入口和 Gateway API 流量会经过每节点的 Envoy，Envoy 可以与 eBPF 策略引擎交互。对已经维护 CiliumNetworkPolicy 的平台团队来说，这种关联比“入口控制器只负责七层转发、网络策略另行处理”更容易形成统一的责任边界；但它也意味着策略评审必须理解 world 和 ingress 两个身份。

第三个场景，是外部暴露方式不固定，需要在 LoadBalancer、NodePort 和 Host Network 之间做取舍。Cilium 默认创建 LoadBalancer 类型 Service，也支持通过参数调整服务形态；开发环境或没有集群外部负载均衡器的环境，可以考虑 Host Network。不过这不是“换一个开关就完全等价”：Host Network 与 LoadBalancer 服务模式互斥，监听器会暴露在节点接口上，端口规划也会转化为节点级约束。

把入口暴露方式和限制放进决策

可以把选择压缩成三个问题。第一，环境是否能提供 LoadBalancer？如果能，默认模式通常更符合云上或已有外部负载均衡的入口模型。第二，是否只需要通过节点端口接入？如果是，NodePort 是更明确的边界。第三，是否处于没有集群外部负载均衡器的开发或边缘环境？这时 Host Network 有吸引力，但必须接受它在所有匹配节点上监听、端口不能冲突，以及协议支持不同等代价。

gatewayAPI:
  enabled: true # 打开 Cilium Gateway API 控制器
  hostNetwork:
    enabled: true # 仅在没有合适 LoadBalancer 时评估节点网络暴露

# Host Network 与 LoadBalancer 服务模式互斥，部署前要选定一种入口边界

这里的配置只用来表达决策边界，不应直接当成所有环境的完整 values 文件。官方文档还特别指出，Host Network 模式不兼容 TCPRoute 和 UDPRoute；如果入口计划承载这两类协议，不能只看 HTTP/HTTPS 示例是否正常，还要把暴露模式一起纳入设计。

落地前先检查四个前置条件

第一，确认 Cilium 使用了 kube-proxy replacement。第二，确认 L7 proxy 已启用；官方文档把它列为 Gateway API 的前置条件。第三，检查 TPROXY 所需的内核与 iptables/netfilter 能力，尤其是默认 bpf.tproxy=false 的环境。第四，安装与目标能力对应的 Gateway API CRD，并确认 GatewayClass 的控制器名是 io.cilium/gateway-controller。

# 查看 Cilium 运行状态，先确认基础组件是否可用
cilium status

# 查看 GatewayClass，确认控制器名称和状态
kubectl get gatewayclass -o wide

# 查看入口路由的条件，区分 Accepted 与后端引用错误
kubectl describe httproute -A

# 只列出 Gateway 相关 CRD，避免把未安装的可选协议当成已支持
kubectl get crd | grep gateway

最后一条检查尤其重要：Gateway API 的资源支持是分层的，TCPRoute、UDPRoute 或 ListenerSet 等能力可能需要额外安装对应 CRD。即使 Gateway 对象已经创建，也要看资源条件和控制器状态；例如后端 Service 不存在时，HTTPRoute 可能出现 ResolvedRefs=False，这不等于 Cilium Gateway 控制器没有工作。

判断清单：什么时候应该选，什么时候先别选

如果集群已经使用 Cilium，入口流量需要和 CiliumNetworkPolicy 协同，团队能接受 Envoy 与 eBPF 的组合，并且已经明确 LoadBalancer、NodePort 或 Host Network 的暴露边界，那么 Cilium Gateway API 值得优先评估。它的优势不在于“资源名称更现代”，而在于入口控制和网络数据路径可以放在一个系统里理解。

反过来，如果团队刻意要求入口控制器与 CNI 解耦，基础环境无法满足 kube-proxy replacement 或 L7 proxy，或者业务依赖 Host Network 传输 TCPRoute/UDPRoute，那么应先解决这些结构性冲突，再谈迁移。Gateway API 是标准接口，不会自动抹平实现方的网络前置条件。

相关问题

Cilium Gateway API 是否只能使用 LoadBalancer？

不是。官方文档说明可以使用 LoadBalancer 或 NodePort，也可以选择 Host Network；但 Host Network 与 LoadBalancer 模式互斥，且会带来节点监听、端口冲突和协议限制。

用了 Cilium CNI，就一定应该用 Cilium Gateway API 吗？

不一定。Cilium 的优势是入口流量与 CNI、Envoy 和网络策略结合得更紧。若团队更重视入口控制器独立升级、独立运维或跨 CNI 迁移，应把解耦要求放在评估表里。

为什么 HTTPRoute 创建成功，后端仍然没有流量？

先查看 HTTPRoute 的 Conditions，确认后端 Service 是否存在、parentRefs 是否指向正确 Gateway，再检查 GatewayClass 和 Cilium 的基础状态。资源被 API 接受，不代表后端引用和数据路径已经全部满足。

这篇判断基于 Cilium 当前稳定文档的架构与限制，实际部署前还应结合目标 Cilium 版本的升级说明和集群网络环境做配置核对。