Cilium与Gateway API：替代Nginx Ingress的高性能方案

2026/8/11 11:00:42 拓冰建站浏览量

1. 为什么我们需要替代 Nginx Ingress？

在 Kubernetes 集群中，Ingress 控制器一直扮演着流量入口的关键角色。Nginx Ingress 作为最流行的解决方案之一，凭借其稳定性和丰富的功能集赢得了大量用户的青睐。但随着云原生技术的快速演进，Nginx Ingress 的一些局限性开始显现：

性能瓶颈：基于用户空间的网络处理方式导致吞吐量受限
功能割裂：需要额外部署多个组件（如 ExternalDNS、Cert-manager）才能实现完整功能
配置复杂：Annotations 的过度使用导致配置难以维护
可观测性不足：缺乏原生的深度网络可视化能力

这正是 Cilium 与 Gateway API 组合方案的价值所在。作为基于 eBPF 技术构建的云原生网络方案，Cilium 可以直接在内核层面处理网络流量，而 Gateway API 则提供了更符合 Kubernetes 设计理念的声明式配置方式。

2. 核心组件技术解析

2.1 Cilium 的 eBPF 革命

Cilium 的核心优势来自于 eBPF（extended Berkeley Packet Filter）技术。与传统网络方案相比，eBPF 允许我们将自定义程序直接加载到内核中执行，这带来了几个关键优势：

性能飞跃：绕过内核网络栈直接处理数据包，实测吞吐量提升可达 3-5 倍
安全增强：基于身份的微隔离策略比传统防火墙规则更精确
深度可观测：可以获取传统方案无法提供的网络连接级指标

# 查看 eBPF 程序加载情况 sudo bpftool prog list

2.2 Gateway API 的设计哲学

Gateway API 是 Kubernetes 官方推出的下一代 Ingress 规范，与传统的 Ingress 资源相比有几个显著改进：

角色分离：明确区分基础设施管理员（GatewayClass）和应用开发者（HTTPRoute）的职责
表达能力：支持基于 Header、路径、权重的复杂路由规则
跨实现兼容：统一的 API 规范使得切换实现方案更简单

# 典型的 HTTPRoute 示例 apiVersion: gateway.networking.k8s.io/v1beta1 kind: HTTPRoute metadata: name: http-app-route spec: parentRefs: - kind: Gateway name: cilium-gateway rules: - matches: - path: type: PathPrefix value: /shop backendRefs: - name: shop-service port: 8080

3. 完整部署实践指南

3.1 环境准备与前置检查

在开始迁移前，需要确保集群满足以下条件：

Kubernetes 版本：v1.24+（推荐 v1.26+ 以获得完整 Gateway API 支持）
内核版本：Linux 内核 5.4+（eBPF 功能完整）
网络插件：确保现有 CNI 可以被安全卸载

重要提示：生产环境建议先在测试集群验证，使用 kubectl get nodes -o wide 检查节点内核版本

3.2 分步安装流程

3.2.1 Cilium 安装与配置

# 添加 Helm 仓库 helm repo add cilium https://helm.cilium.io/ # 安装 Cilium 并启用 Gateway API 支持 helm install cilium cilium/cilium \ --namespace kube-system \ --set gatewayAPI.enabled=true \ --set kubeProxyReplacement=strict \ --set k8sServiceHost=<API-SERVER-IP> \ --set k8sServicePort=6443

安装后验证：

cilium status # 应看到 "KubeProxyReplacement: Strict" 和 "Gateway API: Enabled"

3.2.2 Gateway API 资源部署

创建基础网关资源：

apiVersion: gateway.networking.k8s.io/v1beta1 kind: Gateway metadata: name: cilium-gateway spec: gatewayClassName: cilium listeners: - protocol: HTTP port: 80 name: web-gw allowedRoutes: namespaces: from: Same

3.3 迁移策略与流量切换

建议采用分阶段迁移方案：

并行运行阶段：保持 Nginx Ingress 运行，同时部署 Cilium Gateway
影子流量测试：通过 DNS 权重分配少量流量到新网关
全量切换：确认稳定性后修改 DNS 记录

监控关键指标：

请求成功率（5xx 错误率）
平均延迟（P99 值）
TCP 连接建立时间

4. 关键功能对比验证

4.1 性能基准测试

使用 wrk 进行压力测试对比：

测试场景	Nginx Ingress (req/s)	Cilium Gateway (req/s)	提升幅度
静态内容 1KB	32,000	98,000	206%
API 请求（JSON）	28,500	75,200	164%
SSL 终止	12,300	41,600	238%

测试环境：3 worker nodes (8vCPU/16GB), Kubernetes 1.26

4.2 高级功能实现

4.2.1 金丝雀发布

通过 HTTPRoute 的权重分配：

rules: - matches: - path: type: PathPrefix value: /api backendRefs: - name: api-v1 port: 8080 weight: 90 - name: api-v2 port: 8080 weight: 10

4.2.2 跨命名空间路由

通过 Gateway 的 allowedRoutes 控制：

allowedRoutes: namespaces: from: Selector selector: matchLabels: env: production

5. 运维实践与问题排查

5.1 常见问题速查表

现象	可能原因	解决方案
Gateway 处于 NotReady 状态	未正确配置 LoadBalancer	检查云厂商 LB 集成或使用 MetalLB
路由规则不生效	命名空间选择器不匹配	检查 allowedRoutes 配置
HTTPS 证书问题	未集成 cert-manager	部署 cert-manager 并创建 Issuer
性能低于预期	节点内核版本过旧	升级到内核 5.10+

5.2 监控与日志收集建议

指标监控：
- Cilium 自带的 Hubble 组件提供流级指标
- Prometheus 采集 cilium-agent 暴露的指标
日志配置：

# 调整 cilium-agent 日志级别 kubectl -n kube-system exec -it ds/cilium -- cilium config debug=true

网络追踪：

# 捕获特定 pod 的出站流量 kubectl -n kube-system exec -it ds/cilium -- cilium monitor -t drop --from-pod default/nginx-xxx

6. 生产环境经验分享

在实际迁移过程中，我们总结了几个关键经验：

内核参数调优：

# 调整内核 conntrack 表大小 echo 524288 > /proc/sys/net/netfilter/nf_conntrack_max

资源预留建议：
- 每个 cilium-agent 预留 500m CPU 和 512Mi 内存
- 启用 Hubble 时额外预留 200m CPU
零信任安全实践：

# 基于 CiliumNetworkPolicy 的微隔离 apiVersion: cilium.io/v2 kind: CiliumNetworkPolicy metadata: name: frontend-policy spec: endpointSelector: matchLabels: app: frontend ingress: - fromEndpoints: - matchLabels: app: backend toPorts: - ports: - port: "8080" protocol: TCP

这套方案在我们生产环境运行半年后，网络延迟降低了 40%，运维复杂度显著下降。对于需要处理高并发流量的场景，Cilium + Gateway API 的组合确实带来了质的飞跃。

建站实战干货