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 的核心优势来自于 eBPFextended Berkeley Packet Filter技术。与传统网络方案相比eBPF 允许我们将自定义程序直接加载到内核中执行这带来了几个关键优势性能飞跃绕过内核网络栈直接处理数据包实测吞吐量提升可达 3-5 倍安全增强基于身份的微隔离策略比传统防火墙规则更精确深度可观测可以获取传统方案无法提供的网络连接级指标# 查看 eBPF 程序加载情况 sudo bpftool prog list2.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: 80803. 完整部署实践指南3.1 环境准备与前置检查在开始迁移前需要确保集群满足以下条件Kubernetes 版本v1.24推荐 v1.26 以获得完整 Gateway API 支持内核版本Linux 内核 5.4eBPF 功能完整网络插件确保现有 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.enabledtrue \ --set kubeProxyReplacementstrict \ --set k8sServiceHostAPI-SERVER-IP \ --set k8sServicePort6443安装后验证cilium status # 应看到 KubeProxyReplacement: Strict 和 Gateway API: Enabled3.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: Same3.3 迁移策略与流量切换建议采用分阶段迁移方案并行运行阶段保持 Nginx Ingress 运行同时部署 Cilium Gateway影子流量测试通过 DNS 权重分配少量流量到新网关全量切换确认稳定性后修改 DNS 记录监控关键指标请求成功率5xx 错误率平均延迟P99 值TCP 连接建立时间4. 关键功能对比验证4.1 性能基准测试使用 wrk 进行压力测试对比测试场景Nginx Ingress (req/s)Cilium Gateway (req/s)提升幅度静态内容 1KB32,00098,000206%API 请求JSON28,50075,200164%SSL 终止12,30041,600238%测试环境3 worker nodes (8vCPU/16GB), Kubernetes 1.264.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: 104.2.2 跨命名空间路由通过 Gateway 的 allowedRoutes 控制allowedRoutes: namespaces: from: Selector selector: matchLabels: env: production5. 运维实践与问题排查5.1 常见问题速查表现象可能原因解决方案Gateway 处于 NotReady 状态未正确配置 LoadBalancer检查云厂商 LB 集成或使用 MetalLB路由规则不生效命名空间选择器不匹配检查 allowedRoutes 配置HTTPS 证书问题未集成 cert-manager部署 cert-manager 并创建 Issuer性能低于预期节点内核版本过旧升级到内核 5.105.2 监控与日志收集建议指标监控Cilium 自带的 Hubble 组件提供流级指标Prometheus 采集 cilium-agent 暴露的指标日志配置# 调整 cilium-agent 日志级别 kubectl -n kube-system exec -it ds/cilium -- cilium config debugtrue网络追踪# 捕获特定 pod 的出站流量 kubectl -n kube-system exec -it ds/cilium -- cilium monitor -t drop --from-pod default/nginx-xxx6. 生产环境经验分享在实际迁移过程中我们总结了几个关键经验内核参数调优# 调整内核 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 的组合确实带来了质的飞跃。
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 的核心优势来自于 eBPFextended Berkeley Packet Filter技术。与传统网络方案相比eBPF 允许我们将自定义程序直接加载到内核中执行这带来了几个关键优势性能飞跃绕过内核网络栈直接处理数据包实测吞吐量提升可达 3-5 倍安全增强基于身份的微隔离策略比传统防火墙规则更精确深度可观测可以获取传统方案无法提供的网络连接级指标# 查看 eBPF 程序加载情况 sudo bpftool prog list2.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: 80803. 完整部署实践指南3.1 环境准备与前置检查在开始迁移前需要确保集群满足以下条件Kubernetes 版本v1.24推荐 v1.26 以获得完整 Gateway API 支持内核版本Linux 内核 5.4eBPF 功能完整网络插件确保现有 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.enabledtrue \ --set kubeProxyReplacementstrict \ --set k8sServiceHostAPI-SERVER-IP \ --set k8sServicePort6443安装后验证cilium status # 应看到 KubeProxyReplacement: Strict 和 Gateway API: Enabled3.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: Same3.3 迁移策略与流量切换建议采用分阶段迁移方案并行运行阶段保持 Nginx Ingress 运行同时部署 Cilium Gateway影子流量测试通过 DNS 权重分配少量流量到新网关全量切换确认稳定性后修改 DNS 记录监控关键指标请求成功率5xx 错误率平均延迟P99 值TCP 连接建立时间4. 关键功能对比验证4.1 性能基准测试使用 wrk 进行压力测试对比测试场景Nginx Ingress (req/s)Cilium Gateway (req/s)提升幅度静态内容 1KB32,00098,000206%API 请求JSON28,50075,200164%SSL 终止12,30041,600238%测试环境3 worker nodes (8vCPU/16GB), Kubernetes 1.264.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: 104.2.2 跨命名空间路由通过 Gateway 的 allowedRoutes 控制allowedRoutes: namespaces: from: Selector selector: matchLabels: env: production5. 运维实践与问题排查5.1 常见问题速查表现象可能原因解决方案Gateway 处于 NotReady 状态未正确配置 LoadBalancer检查云厂商 LB 集成或使用 MetalLB路由规则不生效命名空间选择器不匹配检查 allowedRoutes 配置HTTPS 证书问题未集成 cert-manager部署 cert-manager 并创建 Issuer性能低于预期节点内核版本过旧升级到内核 5.105.2 监控与日志收集建议指标监控Cilium 自带的 Hubble 组件提供流级指标Prometheus 采集 cilium-agent 暴露的指标日志配置# 调整 cilium-agent 日志级别 kubectl -n kube-system exec -it ds/cilium -- cilium config debugtrue网络追踪# 捕获特定 pod 的出站流量 kubectl -n kube-system exec -it ds/cilium -- cilium monitor -t drop --from-pod default/nginx-xxx6. 生产环境经验分享在实际迁移过程中我们总结了几个关键经验内核参数调优# 调整内核 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 的组合确实带来了质的飞跃。
