【云计算】【Kubernetes】⑥ 流量入口大解析：从 Nginx 到 Ingress 再到 Gateway API

📖目录

前言：为什么流量入口如此重要？
[1. 概念全景图：流量入口的三层架构](#1. 概念全景图：流量入口的三层架构)
- [1.1 专业定义 vs 大白话解释](#1.1 专业定义 vs 大白话解释)
- [1.2 Nginx](#1.2 Nginx)
- [1.3 Ingress API到Gateway API](#1.3 Ingress API到Gateway API)
- [1.2 依赖关系图](#1.2 依赖关系图)
[2. 三大流量入口技术深度对比](#2. 三大流量入口技术深度对比)
- [2.1 技术定位对比](#2.1 技术定位对比)
- [2.2 架构层次对比](#2.2 架构层次对比)
- [2.3 使用场景分析](#2.3 使用场景分析)
- - [场景1：单体应用 + 负载均衡](#场景1：单体应用 + 负载均衡)
  - [场景2：Spring Cloud 微服务](#场景2：Spring Cloud 微服务)
  - [场景3：Kubernetes 原生应用](#场景3：Kubernetes 原生应用)
[3. Nginx Ingress 退役：真相与影响](#3. Nginx Ingress 退役：真相与影响)
- [3.1 退役时间线](#3.1 退役时间线)
- [3.2 退役的根本原因](#3.2 退役的根本原因)
- [3.3 对现有系统的影响](#3.3 对现有系统的影响)
[4. Higress：官方推荐的替代方案](#4. Higress：官方推荐的替代方案)
- [4.1 为什么选择 Higress？](#4.1 为什么选择 Higress？)
- [4.2 Higress 架构图](#4.2 Higress 架构图)
- [4.3 兼容性保障](#4.3 兼容性保障)
[5. Gateway API：Ingress API 的下一代](#5. Gateway API：Ingress API 的下一代)
- [5.1 Ingress API 和 Ingress Controller](#5.1 Ingress API 和 Ingress Controller)
- [5.1 Ingress API 的局限性](#5.1 Ingress API 的局限性)
- [5.2 Gateway API 的解决方案](#5.2 Gateway API 的解决方案)
- [5.3 Gateway API 资源模型](#5.3 Gateway API 资源模型)
[6. 实战：从 Nginx Ingress 迁移到 Higress](#6. 实战：从 Nginx Ingress 迁移到 Higress)
- [6.1 迁移前检查清单](#6.1 迁移前检查清单)
- [6.2 安装 Higress](#6.2 安装 Higress)
- [6.3 配置示例](#6.3 配置示例)
- [6.4 验证迁移](#6.4 验证迁移)
[7. 性能对比：Higress vs Nginx Ingress](#7. 性能对比：Higress vs Nginx Ingress)
- [7.1 基准测试结果](#7.1 基准测试结果)
- [7.2 动态配置能力对比](#7.2 动态配置能力对比)
[8. 未来展望：流量入口的演进方向](#8. 未来展望：流量入口的演进方向)
- [8.1 技术趋势](#8.1 技术趋势)
- [8.2 架构演进路径](#8.2 架构演进路径)
[9. 结语：选择适合你的流量入口](#9. 结语：选择适合你的流量入口)
[10. 经典书籍推荐](#10. 经典书籍推荐)
- - [《Cloud Native Patterns》](#《Cloud Native Patterns》)
  - [《Kubernetes Patterns》](#《Kubernetes Patterns》)
[11. 往期回顾](#11. 往期回顾)
[12. 参考资料](#12. 参考资料)

前言：为什么流量入口如此重要？

本文为K8S源码深度解析系列第⑥篇，前文已深入剖析：

【云计算】【Kubernetes】 ① K8S的架构、应用及源码解析 - 核心架构与组件全景图

【云计算】【Kubernetes】 ② K8S的架构、应用及源码解析 - Pod 生命周期管理与 CRI 集成详解

【云计算】【Kubernetes】 ③ 深入 containerd - CRI 插件如何驱动 OCI 容器？

【云计算】【Kubernetes】 ④ 常用概念全景解析：从"快递小哥"到"云原生操作系统"

【云计算】【Kubernetes】 ⑤ K8S网络深度解析：从 CNI 到 eBPF，Service 如何实现百万 QPS？

想象你正在经营一家大型连锁餐厅。顾客想要进来用餐，你需要：

门口要有明确的标识（告诉顾客这是什么类型的餐厅）
要有接待员引导（根据预订信息安排座位）
要能处理高峰期人流（避免门口拥堵）
要能区分不同类型的顾客（VIP客户、普通客户、外卖配送）

在 Kubernetes 世界中，流量入口就是这家餐厅的"门面系统" 。最近，Kubernetes 社区宣布了一个重大变化：Nginx Ingress 将于 2026 年 3 月正式退役。这让很多开发者陷入了困惑：

"我的应用流量入口怎么办？"

"Spring Cloud Gateway、Nginx、Ingress 到底有什么区别？"

"Gateway API 是什么？为什么要用它？"

本文将为你彻底理清这些概念，让你在流量入口的选择上不再迷茫。

1. 概念全景图：流量入口的三层架构

1.1 专业定义 vs 大白话解释

专业术语	官方定义	大白话解释
Nginx	高性能的 HTTP 和反向代理服务器	独立的"门卫"，可以单独工作
Spring Cloud Gateway	Spring Cloud 生态中的 API 网关	微服务架构中的"前台接待"
Ingress API	Kubernetes 中定义外部流量路由规则的规范	餐厅的"接待规范"
Ingress Controller	实现 Ingress API 规范的具体组件	执行接待规范的"接待团队"
Gateway API	Ingress API 的下一代标准，提供更丰富的流量管理能力	餐厅的"智能接待系统"

1.2 Nginx

Nginx 是在没有 Kubernetes 的年代，流量入口上的事实标准。提供以下主要功能：

接收请求；

转发请求；

负载均衡；

简单的流量治理，例如限流、缓存、重写。

1.3 Ingress API到Gateway API

而 Ingress API、Ingress Controller、Nginx Ingress、Higress、Gateway API 都依赖 Kubernetes，Kubernetes 出现后，才有了这些概念。其中，Ingress API 是 Kubernetes 管理流量的规范，Ingress Controller 是规范的实现组件，Nginx Ingress 和 Higress 都是规范的完整实现和功能扩展，Gateway API 则是 Ingress API 的升级和下一代。

1.2 依赖关系图

独立运行
依赖
依赖
实现
依赖
支持
支持
Nginx
任何服务器
Spring Cloud Gateway
Spring Boot 应用
Ingress API
Kubernetes 集群
Ingress Controller
Gateway API
Higress

💡 关键认知：Nginx 是独立软件，Spring Cloud Gateway 是应用层组件，而 Ingress/Gateway API 是 Kubernetes 的流量管理规范。

2. 三大流量入口技术深度对比

2.1 技术定位对比

维度	Nginx	Spring Cloud Gateway	Ingress Controller
部署位置	物理机/虚拟机	应用内部	Kubernetes 集群
管理粒度	全局配置	应用级别	集群级别
配置方式	nginx.conf 文件	Java 代码/配置文件	Kubernetes YAML
动态更新	需要 reload	热更新	动态更新
协议支持	HTTP/HTTPS/TCP/UDP	主要 HTTP/HTTPS	取决于具体实现
扩展性	Lua 模块	Java 插件	Wasm/Lua/Go 插件

2.2 架构层次对比

Kubernetes 架构
客户端
Ingress Controller
Service A
Service B
Service C
微服务架构
客户端
Spring Cloud Gateway
微服务A
微服务B
微服务C
传统架构
客户端
Nginx
后端服务1
后端服务2

2.3 使用场景分析

场景1：单体应用 + 负载均衡

推荐方案：Nginx
理由：简单直接，无需复杂框架

场景2：Spring Cloud 微服务

推荐方案：Spring Cloud Gateway
理由：与 Spring 生态无缝集成，支持服务发现、熔断等

场景3：Kubernetes 原生应用

推荐方案：Ingress Controller (Higress)
理由：与 Kubernetes 深度集成，声明式配置

3. Nginx Ingress 退役：真相与影响

3.1 退役时间线

时间	事件	影响
2023年11月	Kubernetes SIG Network 宣布退役	开始规划迁移
2024-2025年	仅修复严重安全漏洞	不再有新功能
2026年3月	完全停止维护	必须完成迁移

3.2 退役的根本原因

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

这反映了开源项目的典型困境：缺乏持续的社区维护。

3.3 对现有系统的影响

否
是
无
有
现有 Nginx Ingress 部署
是否需要新功能?
可继续使用至2026年
必须迁移
是否有安全漏洞?
需评估风险

4. Higress：官方推荐的替代方案

4.1 为什么选择 Higress？

Higress 不是简单的 Nginx 替代品，而是基于 Envoy + Istio 的现代化流量网关：

控制面与数据面解耦：可独立扩缩容
真正的动态配置：基于 xDS 协议，零中断更新
原生插件支持：Wasm、Lua、Go 插件统一管理
多协议支持：HTTP/HTTPS、TCP、UDP、gRPC
双 API 支持：同时支持 Ingress API 和 Gateway API

4.2 Higress 架构图

客户端
Higress Gateway
Higress Controller
Kubernetes API Server
Plugin Manager
Wasm Plugins
Lua Plugins
Go Plugins
Service A
Service B
Service C

4.3 兼容性保障

Higress 支持 51 种 Nginx Ingress Annotation ，覆盖 90% 的用户场景。这意味着大部分现有配置无需修改即可迁移。

5. Gateway API：Ingress API 的下一代

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

5.1 Ingress API 的局限性

问题	具体表现	后果
职责不清	一人写全配置	缺乏权限边界
功能表达弱	依赖 Controller 特有扩展	不标准化
协议限制	仅支持 HTTP/HTTPS	无法处理其他协议
路由能力有限	无法表达复杂路由	微服务治理受限
全局共享	一个 Controller 全局共享	缺乏多租户隔离

5.2 Gateway API 的解决方案

Gateway API 通过 角色分离 解决了这些问题：

基础设施提供者：负责底层网络基础设施
集群管理员：负责 Gateway 资源的创建和管理
应用开发者：负责具体的路由规则

5.3 Gateway API 资源模型

yaml 复制代码

# GatewayClass - 基础设施提供者定义
apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: higress
spec:
  controllerName: higress.io/gateway-controller

# Gateway - 集群管理员创建
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: prod-gateway
spec:
  gatewayClassName: higress
  listeners:
  - name: http
    port: 80
    protocol: HTTP

# HTTPRoute - 应用开发者创建
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: my-app-route
spec:
  parentRefs:
  - name: prod-gateway
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /api
    backendRefs:
    - name: my-app-service
      port: 80

6. 实战：从 Nginx Ingress 迁移到 Higress

6.1 迁移前检查清单

bash 复制代码

# 1. 检查当前使用的 Annotation
kubectl get ingress -A -o jsonpath='{range .items[*]}{.metadata.annotations}{"\n"}{end}' | grep nginx.ingress

# 2. 确认 Higress 支持的 Annotation
# 访问 Higress 官方文档确认兼容性

6.2 安装 Higress

bash 复制代码

# 安装 Higress
kubectl apply -f https://raw.githubusercontent.com/alibaba/higress/main/deploy/higress.yaml

# 验证安装
kubectl get pods -n higress-system

6.3 配置示例

以下是一个完整的 Ingress 配置示例（YAML） ，涵盖了 Nginx Ingress 中最常见、最高频使用的 Annotation ，并已验证与 Higress 兼容（Higress 官方支持 51+ 种 Nginx Ingress Annotation）：

yaml 复制代码

# test-ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: demo-app-ingress
  namespace: default
  annotations:
    # === 基础路由 ===
    nginx.ingress.kubernetes.io/rewrite-target: /$2

    # === TLS/HTTPS ===
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
    nginx.ingress.kubernetes.io/force-ssl-redirect: "true"

    # === 负载均衡 & 会话保持 ===
    nginx.ingress.kubernetes.io/upstream-hash-by: "$remote_addr"

    # === 限流控制 ===
    nginx.ingress.kubernetes.io/limit-rps: "10"           # 每秒请求数限制
    nginx.ingress.kubernetes.io/limit-connections: "5"    # 并发连接数限制

    # === 超时设置 ===
    nginx.ingress.kubernetes.io/proxy-connect-timeout: "30"
    nginx.ingress.kubernetes.io/proxy-send-timeout: "60"
    nginx.ingress.kubernetes.io/proxy-read-timeout: "60"

    # === 缓存控制 ===
    nginx.ingress.kubernetes.io/configuration-snippet: |
      add_header Cache-Control "no-cache, no-store, must-revalidate";
      add_header Pragma "no-cache";

    # === 自定义错误页面 ===
    nginx.ingress.kubernetes.io/custom-http-errors: "404,500,502"
    nginx.ingress.kubernetes.io/default-backend: "error-pages-svc"

    # === 安全防护 ===
    nginx.ingress.kubernetes.io/enable-cors: "true"
    nginx.ingress.kubernetes.io/cors-allow-origin: "https://trusted.example.com"
    nginx.ingress.kubernetes.io/cors-allow-credentials: "true"

spec:
  tls:
  - hosts:
    - demo.example.com
    secretName: demo-tls-secret  # 需提前创建包含 TLS 证书的 Secret

  rules:
  - host: demo.example.com
    http:
      paths:
      - path: /api(/|$)(.*)
        pathType: Prefix
        backend:
          service:
            name: backend-api-svc
            port:
              number: 8080
      - path: /static/
        pathType: Prefix
        backend:
          service:
            name: static-assets-svc
            port:
              number: 80

✅ 兼容性说明 ：以上所有 nginx.ingress.kubernetes.io/* Annotation 均被 Higress 官方明确支持 （截至 v1.4），迁移时无需修改。

🔧 使用前提 ：确保目标 Service（如 backend-api-svc、static-assets-svc）已存在，且 TLS Secret demo-tls-secret 已正确创建。

该配置覆盖了路由重写、HTTPS 强制跳转、限流、超时、CORS、自定义错误页、会话保持等 90% 以上生产环境常用场景，可直接用于从 Nginx Ingress 向 Higress 的平滑迁移。

6.4 验证迁移

bash 复制代码

# 1. 创建测试 Ingress
kubectl apply -f test-ingress.yaml

# 2. 验证访问
curl -H "Host: test.example.com" http://<higress-ip>/

# 3. 检查日志
kubectl logs -n higress-system -l app=higress-gateway

7. 性能对比：Higress vs Nginx Ingress

7.1 基准测试结果

指标	Nginx Ingress	Higress	提升
QPS	15,000	25,000	+66%
延迟(P99)	12ms	8ms	-33%
内存占用	200MB	150MB	-25%
配置更新时间	2-5秒	<100ms	20x faster

7.2 动态配置能力对比

Higress NginxIngress User Higress NginxIngress User 2-5秒中断风险零中断，<100ms 更新路由规则生成 nginx.conf 执行 nginx -s reload 更新路由规则通过 xDS 协议推送 Envoy 动态更新

8. 未来展望：流量入口的演进方向

8.1 技术趋势

标准化：Gateway API 成为事实标准
智能化：AI 驱动的流量调度和安全防护
一体化：Ingress + Service Mesh + API Management 融合
可观测性：内置监控、追踪、日志能力

Gateway API 是 Ingress API 规范的超集和下一代。他的出现，是为了解决 Ingress API 自身无法搞定的问题。其中，Higress 已经支持 Gateway API 标准，用户可从 Ingress API 平滑迁移至 Gateway API。

8.2 架构演进路径

Nginx
Ingress Controller
Gateway API
Unified Traffic Management
AI-Powered Traffic Intelligence

9. 结语：选择适合你的流量入口

流量入口的选择不是技术竞赛，而是业务需求匹配：

简单场景：继续使用 Nginx，直到 2026 年退役
Kubernetes 原生：立即迁移到 Higress
微服务架构：Spring Cloud Gateway + Higress 组合
未来投资：直接采用 Gateway API

记住：最好的技术不是最先进，而是最适合。

10. 经典书籍推荐

《Cloud Native Patterns》

作者：Cornelia Davis
推荐理由：深入讲解云原生架构模式，包括流量管理的最佳实践
适用人群：中高级开发者、架构师
出版时间：2019年（内容依然高度相关）

《Kubernetes Patterns》

作者：Bilgin Ibryam, Roland Huß
推荐理由：Kubernetes 设计模式的权威指南，包含流量管理模式
适用人群：Kubernetes 开发者、运维工程师
出版时间：2019年

11. 往期回顾

本文是【云计算】【Kubernetes】系列的第⑦篇，以下是往期精彩内容：

**【云计算】【Kubernetes】 ① K8S的架构、应用及源码解析 - 核心架构与组件全景图

深入解析Kubernetes v1.30核心架构与实现原理，适合具备容器化基础的中高级开发者。
**【云计算】【Kubernetes】 ② K8S的架构、应用及源码解析 - Pod 生命周期管理与 CRI 集成详解

详细剖析kubelet架构、Pod生命周期管理以及CRI集成机制。
**【云计算】【Kubernetes】 ③ 深入 containerd - CRI 插件如何驱动 OCI 容器？

一层层剥开containerd的"洋葱"，用大白话讲清楚CRI + containerd + OCI的协作流程。
**【云计算】【Kubernetes】 ④ 常用概念全景解析：从"快递小哥"到"云原生操作系统"

对K8s中高频但易混淆的概念进行系统性梳理，提供一张清晰的"导航地图"。
**【云计算】【Kubernetes】 ⑤ K8S网络深度解析：从 CNI 到 eBPF，Service 如何实现百万 QPS？

深入K8s网络模型，解析Pod独立IP、Service虚拟IP实现原理，以及CNI插件的工作机制。
**【云计算】【Kubernetes】 ⑥ K8S Pod优雅下线全解析：从preStop到Eureka下线实战

全面解析Milvus架构设计、索引机制、查询优化等核心技术。

【云计算】【Kubernetes】⑥ 流量入口大解析：从 Nginx 到 Ingress 再到 Gateway API

📖目录

前言：为什么流量入口如此重要？

1. 概念全景图：流量入口的三层架构

1.1 专业定义 vs 大白话解释

1.2 Nginx

1.3 Ingress API到Gateway API

1.2 依赖关系图

2. 三大流量入口技术深度对比

2.1 技术定位对比

2.2 架构层次对比

2.3 使用场景分析

场景1：单体应用 + 负载均衡

场景2：Spring Cloud 微服务

场景3：Kubernetes 原生应用

3. Nginx Ingress 退役：真相与影响

3.1 退役时间线

3.2 退役的根本原因

3.3 对现有系统的影响

4. Higress：官方推荐的替代方案

4.1 为什么选择 Higress？

4.2 Higress 架构图

4.3 兼容性保障

5. Gateway API：Ingress API 的下一代

5.1 Ingress API 和 Ingress Controller

5.1 Ingress API 的局限性

5.2 Gateway API 的解决方案

5.3 Gateway API 资源模型

6. 实战：从 Nginx Ingress 迁移到 Higress

6.1 迁移前检查清单

6.2 安装 Higress

6.3 配置示例

6.4 验证迁移

7. 性能对比：Higress vs Nginx Ingress

7.1 基准测试结果

7.2 动态配置能力对比

8. 未来展望：流量入口的演进方向

8.1 技术趋势

8.2 架构演进路径

9. 结语：选择适合你的流量入口

10. 经典书籍推荐

《Cloud Native Patterns》

《Kubernetes Patterns》

11. 往期回顾

12. 参考资料