作者：望宸
本文希望提供一种更简单的方式，来理解这些容易混淆的技术概念：Nginx、Ingress、Ingress Controller、Ingress API、Nginx Ingress、Higress、Gateway API。
Nginx 和 Kubernetes
我们先按和 Kubernetes 是否有关，分为两类：
Nginx 是在没有 Kubernetes 的年代，流量入口上的事实标准，是独立运行在任何 Linux/Windows 服务器上的 Web 服务器。提供以下主要功能：
- 接收请求；
- 转发请求；
- 负载均衡；
- 简单的流量治理，例如限流、缓存、重写。
![]()
而 Ingress API、Ingress Controller、Nginx Ingress、Higress、Gateway API 都依赖 Kubernetes，Kubernetes 出现后，才有了这些概念。其中，Ingress API 是 Kubernetes 管理流量的规范，Ingress Controller 是规范的实现组件，Nginx Ingress 和 Higress 都是规范的完整实现和功能扩展，Gateway API 则是 Ingress API 的升级和下一代。
![]()
需要注意的是，Ingress 经常单独出现，需要基于语境来判断，有可能是指 Ingress API，也有可能是指 Ingress 资源，即用户编写的具体配置对象（YAML），遵循 Ingress API。
Ingress API 和 Ingress Controller
Ingress API 和 Ingress Controller 分别是 Kubernetes 流量管理的规范和执行器。
![]()
Ingress API：用声明式的方式，描述外部流量如何进入集群里的 Service，包括：
- 如何通过域名访问服务；
- 如何根据 URL 路径路由到不同后端服务；
- 后端服务是谁；
- 是否启用 HTTPS 加密。
形象地说，Ingress API 可以理解位 Kubernetes 中管理流量的说明书。
Ingress Controller：是 Ingress API 的实现组件，即执行者，包括：
- 监听 Ingress 资源变化；
- 将 Ingress 规则转换为实际的反向代理配置；
- 接收外部流量并按规则路由；
- 处理 TLS 终止（HTTPS 解密）；
- 提供健康检查、负载均衡、重试等流量治理能力。
通过以上能力，Ingress Controller 就实现了 Kubernetes 入口流量的管理。
Nginx Ingress 和 Higress
Nginx Ingress 和 Higress 都是 Ingress API 的完整实现和功能扩展。
![]()
Nginx Ingress：用 Nginx 作为底层实现的 Ingress API，控制面和数据面耦合在同一个进程/容器中。优点是简单、易用、社区广泛。
缺点是：
- 不是原生的 Ingress API，Ingress API 语义偏弱；
- 扩展靠 Annotation（工程噩梦）；
- 生成 nginx.conf + reload，动态配置能力弱（频繁 reload 影响性能）。
适用于简单、稳定、小规模的场景。
Higress：数据面是基于 Enovy，控制面给基于 istio，是原生的 Ingress API。
优点是：
- 控制面与数据面解耦，可独立扩缩容；
- 基于 xDS 协议，实现真正的动态配置（无 reload，零中断）；
- 原生支持插件扩展：Wasm、Lua、Go 插件由控制面统一管理并下发；
- 兼容多协议 & 多标准：同时支持 Ingress API 和 Gateway API。
缺点是，相比 Nginx 广泛的社区基础，Higress 为代表的原生 Ingress API，部署和维护存在学习成本。
适用于高性能、高扩展、企业级的场景。
Nginx Ingress 退役
11月，Kubernetes SIG Network 和安全响应委员会宣布 Ingress NGINX 退役。（⚠️ NGINX 并未退役。）
![]()
意味着：
- Ingress NGINX 尽力维护服务至 2026 年 3 月；
- 不再发布任何新版本；
- 不再修复任何漏洞；
- 也不会更新任何可能发现的安全漏洞；
- GitHub 代码库将设置为只读，仅供参考；
- 现有的 Ingress NGINX 部署将继续运行，安装文件也将继续可用。
引发退役的根本原因：：
- 多年来，该项目只有一两个人利用业余时间，在工作之余进行开发工作；
- 尝试和 Gateway API 社区合作开发一个替代控制器，但未能激发更多人参与 Ingress NGINX 的维护。
Higress：Nginx Ingress 退役的替代优先方案
![]()
- Kubernetes 官方推荐，即官方社区文档中进行了说明；
- 对 Nginx Ingress 的 Annotation 兼容度最高，支持 51 种，覆盖 90% 的用户场景，这意味着现有的 K8s Ingress YAML 文件无需大量修改即可完成迁移；
- 长期投入，并提供企业版服务，即阿里云 API 网关；
- 提供监听 K8s Ingress（Ingress 模式），适用于希望保持 K8s 原生工作流（如GitOps）的团队；和控制台配置 API（API 管理模式），适用于需要集中治理和精细化管理的场景。
Gateway API 和 Ingress API
Gateway API 是 Ingress API 规范的超集和下一代。他的出现，是为了解决 Ingress API 自身无法搞定的问题。其中，Higress 已经支持 Gateway API 标准，用户可从 Ingress API 平滑迁移至 Gateway API。
![]()
Ingress API 存在的问题，Gateway API 这样去解决：
职责不清，后果是 Ingress 是"一人写全"，没有权限边界。-> Gateway API 通过角色分离解决，定义基础设施提供者、集群管理员、应用开发者。
功能表达能力弱，依赖 Controller 特有扩展，后果是不标准、不同实现之间迁移成本高。-> Gateway API 通过 Wasm、插件、服务网格集成解决扩展的标准化。
仅支持 HTTP/HTTPS，无法处理 TCP/UDP/gRPC 等协议。-> 云原生应用早已不只是 Web 服务，Gateway API 通过统一的 API，管理所有南北向流量。
无法表达复杂路由逻辑，微服务治理需求远超 Ingress 能力。-> Gateway API 支持 Wasm、插件、服务网格集成，通过标准化的高级路由解决。
一个 Ingress Controller 全局共享，缺乏多租户隔离，多租户场景下存在安全和配置冲突风险。-> Gateway API 提供了独立 Gateway 的实例。
