在云原生网络架构中，Ingress Controller 是流量入口的“咽喉”。从 Nginx、Traefik 到 ALB、APISIX，技术选型往往决定了未来三年的运维复杂度。本文基于我参与过的三个大型 K8s 集群迁移项目，深度剖析 Ingress 技术栈的演进逻辑。
一、Ingress 技术演进史
从 K8s 1.1 的简单 HTTP 路由，到 1.19 的 Ingress V1 标准化，再到现在的 Gateway API，Ingress 的功能边界在不断扩展。
- 第一代（Nginx Ingress）： 基于 ConfigMap 动态生成 nginx.conf，成熟但 reload 频繁时会有性能抖动。
- 第二代（Envoy/Istio）： 基于 xDS 协议动态配置，无 reload，性能更强，但复杂度陡增。
- 第三代（Gateway API）： 强调角色分离（网络团队 vs 应用团队），是未来标准，但目前生态尚在完善中。
二、主流方案深度对比
| 特性 | Ingress Nginx | Traefik | APISIX | ALB |
|---|---|---|---|---|
| 架构 | Monolithic | Monolithic | Control/Data Plane 分离 | 云厂商托管 |
| 配置方式 | Ingress Resource | Ingress/crd | APISIX Ingress | Console/API |
| 性能 (QPS) | ~20k | ~15k | ~40k | 弹性 |
| 学习曲线 | 低 | 中 | 高 | 低 |
| 适用场景 | 通用 | 微服务/Dynamic | 高网关/流量治理 | 公有云 |
三、为什么 80% 的团队首选 Nginx？
在我的观察中，除非有强烈的 WAF、限流、金丝雀发布需求，否则 Ingress Nginx 是最稳妥的选择。原因有三：
- 稳定性： 经过多年大规模验证，坑已被社区填平。
- 人才储备： 会 Nginx 的运维一抓一大把，招人容易。
- 生态兼容： 几乎所有 K8s 发行版默认集成。
四、何时该考虑替代方案？
当你遇到以下痛点时，可以考虑迁移：
- 配置生效慢： Nginx reload 在千级 Ingress 规则下可能需要秒级，对实时性要求高的场景不适用（选 APISIX/Envoy）。
- 复杂流量治理： 需要细粒度限流、熔断、镜像流量（选 Istio/APISIX）。
- 云原生深度集成： 全量在 AWS/Aliyun 上，直接用 ALB/NLB 更省心。
五、未来展望：Gateway API
Gateway API 将 Ingress 拆分为 GatewayClass, Gateway, HTTPRoute 等对象，解决了 Ingress 资源“职责不清”的问题。预计 2026 年后，新集群将逐步转向 Gateway API。
总结
技术选型没有银弹。对于大多数团队，Ingress Nginx + Cert-Manager + Prometheus 依然是 2026 年的“黄金组合”。保持简单，直到复杂成为瓶颈。
更多架构思考：https://mjj.728.hk/