作者：望宸

本文希望提供一种更简单的方式，来理解这些容易混淆的技术概念：Nginx、Ingress、Ingress Controller、Ingress API、Nginx Ingress、Higress、Gateway API。

01 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。

02 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 入口流量的管理。

03 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，部署和维护存在学习成本。

适用于高性能、高扩展、企业级的场景。

04 Nginx Ingress 退役

11月，Kubernetes SIG Network 和安全响应委员会宣布 Ingress NGINX 退役。（⚠️ NGINX 并未退役）

意味着：

• Ingress NGINX 尽力维护服务至 2026 年 3 月
• 不再发布任何新版本
• 不再修复任何漏洞
• 也不会更新任何可能发现的安全漏洞
• GitHub 代码库将设置为只读，仅供参考
• 现有的 Ingress NGINX 部署将继续运行，安装文件也将继续可用

引发退役的根本原因：：

• 多年来，该项目只有一两个人利用业余时间，在工作之余进行开发工作。
• 尝试和 Gateway API 社区合作开发一个替代控制器，但未能激发更多人参与 Ingress NGINX 的维护。

05 Higress：Nginx Ingress 退役的替代优先方案

• Kubernetes 官方推荐，即官方社区文档中进行了说明。
• 对 Nginx Ingress 的 Annotation 兼容度最高，支持51种，覆盖90%的用户场景，这意味着现有的 K8s Ingress YAML 文件无需大量修改即可完成迁移
• 长期投入，并提供企业版服务，即阿里云 API 网关
• 提供监听 K8s Ingress（Ingress 模式），适用于希望保持 K8s 原生工作流（如GitOps）的团队 ；和控制台配置 API（API 管理模式），适用于需要集中治理和精细化管理的场景 。

06 Gateway API 和 Ingress 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 的实例。