白追追1. 为什么我们需要替代 Nginx Ingress？
在 Kubernetes 生态中，Nginx Ingress 长期占据着入口网关的主导地位。但随着云原生技术栈的演进，传统基于反向代理的 Ingress 方案开始暴露出一些架构性限制。我在多个生产集群的运维实践中发现，当集群规模超过 200 个节点时，Nginx Ingress 的配置热更新延迟会显著增加，有时甚至需要 10-15 秒才能完成全量配置推送。
更本质的问题在于数据平面与控制平面的割裂。Nginx 作为独立的进程运行，需要通过 Ingress Controller 不断同步资源状态。这种架构导致：
- 网络策略需要在 Nginx 和 CNI 插件中分别配置
- 可观测性数据分散在多个系统
- 安全策略难以统一实施
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. Cilium + Gateway API 的技术栈解析
2.1 Cilium 的 eBPF 革命
Cilium 的核心优势在于其基于 eBPF 的内核层网络实现。不同于传统方案在用户空间处理数据包，eBPF 允许我们将网络逻辑直接加载到内核中执行。具体到入口流量场景：
- 四层负载均衡通过
bpf_lb实现 - 七层路由规则编译为 eBPF 字节码
- 连接跟踪在内核完成
实测数据显示，这种架构可以将 HTTP 请求的转发延迟从 Nginx 的 1.2ms 降低到 0.3ms 左右。更重要的是，eBPF 程序是动态加载的，规则更新无需重启任何进程。
2.2 Gateway API 的声明式模型
Gateway API 是 Kubernetes 官方推出的下一代入口规范，与传统的 Ingress 相比有几个关键改进：
yaml复制apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
name: http-route-example
spec:
parentRefs:
- name: internet-gateway
rules:
- matches:
- path:
type: PathPrefix
value: /shop
backendRefs:
- name: shop-service
port: 8080
这种声明式 API 天然支持多租户场景，通过 parentRefs 字段实现路由的分层管理。我在金融云项目中就利用这个特性，让每个业务部门可以自主管理自己的路由规则，而网络团队只需控制 Gateway 实例的部署。
3. 迁移实施全流程指南
3.1 前置条件检查
开始迁移前需要确认：
- Kubernetes 版本 ≥ 1.24
- 已安装 Cilium CNI 且版本 ≥ 1.13
- 内核版本 ≥ 5.4（推荐 5.10+）
使用以下命令验证 eBPF 支持：
bash复制cilium status | grep BPF
# 预期输出应包含 "BPF enabled: true"
3.2 逐步迁移策略
我推荐采用蓝绿迁移方案：
-
并行部署阶段：
- 保持现有 Nginx Ingress 运行
- 部署 Cilium L7 策略和 Gateway API
bash复制helm install cilium-gateway cilium/cilium \ --namespace kube-system \ --set gatewayAPI.enabled=true -
流量切换验证：
通过 DNS 权重逐步将流量切到新网关，监控以下指标：- 请求成功率
- 第 99 百分位延迟
- TCP 重传率
-
旧组件下线：
确认新网关稳定运行 72 小时后，再卸载 Nginx Ingress。
4. 生产环境验证要点
4.1 性能基准测试
在我的压力测试中，使用 8 核 16GB 的节点时：
| 场景 | QPS | 平均延迟 | P99延迟 |
|---|---|---|---|
| Nginx Ingress | 32,000 | 1.8ms | 15ms |
| Cilium Gateway | 58,000 | 0.9ms | 8ms |
注意：实际性能提升取决于具体负载特征。对于大量小包请求，eBPF 的优势会更明显。
4.2 关键故障排查点
在迁移过程中遇到过几个典型问题：
-
HTTP/2 连接中断：
原因是早期 Cilium 版本对 HTTP/2 的 GOAWAY 帧处理有缺陷。解决方案：bash复制kubectl edit cm cilium-config -n kube-system # 添加 enable-http2: "true" -
WebSocket 连接不稳定：
需要显式配置空闲超时：yaml复制apiVersion: gateway.networking.k8s.io/v1beta1 kind: Gateway spec: listeners: - protocol: HTTP idleTimeout: 3600s
5. 进阶配置与优化
5.1 安全策略集成
Cilium 的网络策略可以直接作用于 Gateway：
yaml复制apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
name: gateway-policy
spec:
endpointSelector:
matchLabels:
io.cilium.k8s.policy.gateway: "true"
ingress:
- fromEntities:
- cluster
toPorts:
- ports:
- port: "443"
protocol: TCP
这种策略会在内核层直接丢弃非法流量，比在 Nginx 用 Lua 脚本实现效率高得多。
5.2 可观测性增强
Cilium 的 Hubble 组件提供了前所未有的流量洞察：
bash复制hubble observe --from-namespace kube-system \
--label k8s:io.cilium.k8s.policy.gateway=true \
-t verdict
这个命令可以实时显示网关的流量判决情况，包括被策略拒绝的请求详情。
迁移完成后，集群的入口流量处理从原来的多组件协作变成了统一的数据平面，不仅性能提升显著，运维复杂度也大幅降低。特别是在需要频繁更新路由规则的环境中，Gateway API 的声明式模型让配置变更更加可靠。不过需要注意的是，当前 Cilium 的 L7 处理能力在某些极端场景（如超大 Header）下仍不如 Nginx 成熟，建议根据实际业务需求评估。