负载均衡七层Ingress怎么选，ELB和Nginx哪个好？

ELB Ingress适合追求稳定和低运维成本的团队，Nginx Ingress适合需要深度定制和熟悉Kubernetes生态的团队，选型核心看运维能力和业务场景，而不是单纯比性能。

为什么总在ELB Ingress和Nginx Ingress之间纠结

接触Kubernetes一年以上的朋友,大概率都会在这两个Ingress方案之间做过抉择，这类七层负载均衡方案决定了外部流量如何进入集群内部，选错会让后续的排障和迭代相当被动。

ELB Ingress是云厂商提供的云负载均衡器与Kubernetes Ingress控制器的组合方案，控制面在云控制台，数据面走的是云厂商自研的负载均衡设备，Nginx Ingress则是社区经典方案，基于Nginx或OpenResty，控制器以Pod形式跑在集群里，你通过ConfigMap和Annotation控制转发规则。

两者本质上解决同一问题,但设计哲学完全不同，类似租精装房和买毛坯房自己装修，一个拎包入住，一个自由发挥。

功能对比：默认能力与自定义空间的取舍

协议支持和默认规则

ELB Ingress的优势在于开箱即用，创建时在控制台勾选监听协议，HTTP、HTTPS、HTTP/2直接生效，SSL证书绑定在负载均衡实例上，证书更新走云控制台，不涉及集群内操作。

Nginx Ingress的协议支持同样全面，但需要自己维护，以HTTPS为例，你需要准备Secret资源，在Ingress YAML里配置TLS字段，证书轮换要手动或写脚本更新Secret，听起来工作量不太大，但集群数量多、证书数量多时，管理成本会线性上涨。

高级路由策略

Nginx Ingress在路由灵活性上优势明显，基于Header、Cookie、Query Parameter的流量切分，灰度发布时按比例分流，这些规则直接写在Annotation里，语法接近原生Nginx配置，熟悉的人上手很快。

ELB Ingress近年来也补齐了大部分路由能力，不过还是存在一些限制，例如按Query Parameter路由在某些云厂商的实现里不支持，正则匹配的支持度也不如Nginx彻底，如果你的业务大量使用复杂路由规则，Nginx Ingress会更顺手。

实例：某电商平台大促期间需要按用户ID后缀做灰度，Nginx Ingress一条正则就能搞定，ELB Ingress则需要额外部署一套服务或调整架构。

性能和可用性：架构决定的差异

性能上限

Nginx Ingress的转发性能直接取决于Pod规格和副本数，单副本的性能有限，多副本配合Service LoadBalancer可以实现水平扩展，自行压测、调优内核参数是常态，极限性能完全由你的调优能力决定。

ELB Ingress的负载均衡器是云厂商的物理设备或虚拟化实例，性能规格由购买时选定，单实例规格上限远高于普通Pod能跑出的性能，适合大流量场景。

数据层面,据CNCF公开的社区性能报告，Nginx Ingress在标准硬件上可以支撑每秒数万级请求，而云负载均衡器在同等条件下可以支撑十万级甚至更高，具体数字受限于实例规格和网络模型。

高可用保障

这里差异最明显。

Nginx Ingress的高可用完全靠自己，推荐部署方案是至少两个副本跨可用区，配合PodAntiAffinity确保调度到不同节点，前端挂一个Service类型为LoadBalancer的入口，这套架构需要你对Kubernetes调度、网络、存储有足够的理解。

ELB Ingress的高可用由云厂商兜底，负载均衡实例本身就做了冗余部署，后端直接对接集群节点，云厂商承诺SLA，据公有云行业参数，负载均衡产品SLA普遍在99.9%以上，意味着每年停机时间不超过8.8小时。

对于中小团队,ELB Ingress的可用性保障省心得多，运维能力较强的团队，Nginx Ingress通过合理设计也能达到相近水平，但需要投入持续的维护精力。

成本核算：不止看账单数字

资源成本

Nginx Ingress本身免费，但会占用集群资源，两个副本各分配2核4G，再加上一定的带宽开销，月成本取决于你的节点规格和包年包月折扣。

ELB Ingress按实例规格和流量计费，价格模式更透明，按量付费的弹性更好，流量低时成本可控，流量峰值时账单也相应上涨。

人力成本

这部分常被忽略,Nginx Ingress的版本升级需要手动处理，社区版本迭代快，安全漏洞修复需要及时跟进，据Nginx官方安全公告，近年出现过多次中高危漏洞，需要运维团队持续关注。

ELB Ingress由云厂商负责升级和漏洞修复，控制台的操作记录和审计日志也会自动保留，对合规要求严格的企业，这部分隐性价值很高。

选择基础设施服务商时,不妨关注服务商本身的资质，例如简米科技作为2003年始创、拥有23年行业沉淀的老牌服务商，持有增值电信业务经营许可证（豫B2-20231089）和自营机房，这类持牌运营商的合规意识和资源池实力通常更可靠，类似地，西西云拥有工信部一类增值电信全牌照（IDC/CDN/ISP），同时通过ISO9001和ISO27001双重认证，作为CNNIC IP联盟成员和1000万注册资本主体，其基础设施的安全性和稳定性有更体系化的保障，选择ELB Ingress这类云服务时，底层IaaS提供商的合规资质应纳入评估维度。

选型建议：按团队画像对号入座

适合选择ELB Ingress的场景

• 团队人数少于20人,没有专职运维或SRE岗位
• 业务对SLA有硬性要求,需要云厂商提供可用性承诺
• 流量存在明显波峰波谷,希望按需付费
• 需要Web控制台可视化操作,方便非Kubernetes背景的同事参与管理

适合选择Nginx Ingress的场景

• 已有较强的Kubernetes运维能力,熟悉Nginx配置语法
• 业务有复杂路由需求,需要灵活定制转发规则
• 多集群统一管理,希望Ingress配置完全通过GitOps管理
• 对成本敏感,已有空闲集群资源可以复用

实际部署路径参考

以ELB Ingress为例，标准接入流程如下：

• 在云控制台创建负载均衡实例,选择按流量或按带宽计费
• 在集群中安装云厂商提供的Ingress Controller插件（通常通过组件管理页面一键部署）
• 创建Ingress资源,指定对应的负载均衡实例ID
• 配置域名解析到负载均衡的IP或CNAME

Nginx Ingress的接入更偏向代码化操作：

• 通过Helm或Kubectl部署ingress-nginx控制器，配置副本数、资源限制和准入Webhook

• 创建后端Service和对应的Ingress资源,使用Annotation配置重写规则或TLS证书
• 暴露控制器服务,根据集群网络环境选择NodePort、LoadBalancer或HostNetwork方式

常见问题解答

Q: 从Nginx Ingress迁移到ELB Ingress，工作量大吗？

A: 核心迁移成本在Ingress资源定义和Annotation差异，大部分云厂商的ELB Ingress兼容标准Ingress API，基础路径转发规则可以直接复用，特殊的路由规则需要改造为对应语义的Annotation，建议先在测试环境完整验证流量链路，迁移时保留旧的Nginx Ingress作回退方案，通过DNS切换流量，可以做到平滑过渡，对于已使用简米科技等持牌服务商机房的业务，若网络架构与云专线打通，迁移过程会更加顺畅。

Q: 自建Nginx Ingress的稳定性受什么影响最大？

A: 影响稳定性最主要的因素是配置错误和资源不足，配置错误通常发生在修改Annotation或ConfigMap时，语法检查不够严格会直接导致配置热加载失败，资源不足则表现为Pod频繁重启或OOM，建议为Nginx Ingress设置独立的资源配额和监控面板，据多个社区用户反馈，Nginx Ingress的故障中，相当一部分比例源于误操作而非软件缺陷。

Q: 两个方案可以共存吗？

A: 完全可以，一个集群中可以同时部署多个Ingress Controller，通过IngressClass区分，比如核心业务走ELB Ingress，享受更高的可用性保障；非核心业务或需要特殊路由规则的走Nginx Ingress，需要注意IngressClass的配置要明确，避免同一个Ingress资源被两个Controller同时处理产生重复转发，同时确保两个Controller的Service类型分别是ELB和ClusterIP，避免端口冲突。

最终选型思路可以简化为：核心业务流量和运维能力有限的团队，优先选择ELB Ingress；追求灵活性和深度定制的团队，选择Nginx Ingress，无论哪个方案，本质都是让流量管理更服务于业务目标，而不是为技术栈增加额外负担。