Kubernetes流量管理：从Ingress到GatewayAPI演进
从 Ingress 到 Gateway API：Kubernetes 流量管理的演进与实战指南
在 Kubernetes 生态中，流量管理是连接集群内外服务的核心环节。从早期的 Ingress 到新一代的 Gateway API，K8s 流量管理方案经历了显著的演进。本文将系统梳理 Ingress、Gateway API 以及 Gateway API 之间的关系，解析它们的技术原理、适用场景，并通过实战案例对比两者的使用方式，帮助你理解 “为什么需要 Gateway API” 以及 “如何平滑迁移”。
一、从 “入口” 到 “网关”：K8s 流量管理的核心诉求
在 Kubernetes 集群中，服务（Service）通过虚拟 IP（ClusterIP）在集群内部提供访问能力，但外部流量（如用户浏览器、移动端请求）如何进入集群内部服务？这就是流量管理需要解决的核心问题：
- 外部流量接入：将集群外的 HTTP/HTTPS 请求转发到集群内的 Service（如将 https://api.example.com 转发到 api-service:8080）；
- 规则定义：通过域名、路径、端口等条件匹配流量（如 /v1 路径转发到 v1 版本服务，/v2 转发到 v2 版本）；
- 扩展功能：支持 HTTPS 加密、路径重写、流量分流、跨域（CORS）等高级特性；
- 标准化：提供统一的配置方式，兼容不同的网关实现（如 Nginx、Traefik、Istio）。
为满足这些需求，Kubernetes 社区先后推出了 Ingress 和 Gateway API 两种方案。其中，Gateway API 是 Ingress 的继任者，旨在解决 Ingress 存在的灵活性不足、功能有限等问题。
二、Ingress：K8s 流量管理的 “初代方案”
1. 什么是 Ingress？
Ingress 是 Kubernetes 最早标准化的流量管理 API（networking.k8s.io/v1），它通过Ingress 资源定义流量转发规则，通过Ingress 控制器（如 Nginx Ingress Controller）实现规则落地。
简单来说：
- Ingress 资源：是一个 YAML 配置文件，定义 “域名→路径→服务” 的映射关系（如 api.example.com/v1 → api-v1:80）；
- Ingress 控制器：是运行在集群中的组件（如 Nginx 容器），负责监听 Ingress 资源变化，生成对应的网关配置（如 Nginx 配置文件），并实际处理流量转发。
2. Ingress 的核心配置与局限
（1）基础配置示例
一个典型的 Ingress 资源定义如下（实现 HTTPS 访问和路径转发）：
apiVersion: networking.k8s.io/v1kind: Ingressmetadata:name: demo-ingressannotations:# 配置HTTPS重定向（依赖控制器支持）nginx.ingress.kubernetes.io/ssl-redirect: "true"spec:# 绑定TLS证书（存储在Secret中）tls:- hosts:- api.example.comsecretName: api-tls # 包含tls.crt和tls.key的Secretrules:- host: api.example.com # 匹配域名http:paths:- path: /v1 # 匹配路径pathType: Prefixbackend:service:name: api-v1 # 转发到v1版本服务port:number: 8080- path: /v2pathType: Prefixbackend:service:name: api-v2 # 转发到v2版本服务port:number: 8080（2）Ingress 的局限性
尽管 Ingress 解决了基础的流量转发问题，但在实际使用中暴露出诸多局限：
- 功能有限：仅支持 HTTP/HTTPS 协议，不支持 TCP/UDP 等其他协议；高级特性（如流量权重分流、跨域）依赖控制器特定的 annotations（如 nginx.ingress.kubernetes.io/ 前缀），缺乏标准化，换控制器需重构配置。
- 结构扁平：所有规则都定义在一个 Ingress 资源中，无法实现多团队协作（如开发团队和运维团队分别管理不同规则）。
- 扩展性差：无法灵活配置网关本身的属性（如端口、TLS 策略），只能被动依赖控制器的默认配置。
- 灰度发布支持弱：原生不支持基于权重的流量分流（如 90% 流量到 v1，10% 到 v2），需依赖控制器扩展（如 Istio 的 VirtualService）。
三、Gateway API：下一代 K8s 流量管理标准
为解决 Ingress 的局限性，Kubernetes 社区在 2021 年推出了 Gateway API（目前已进入 v1 稳定版），它是一套全新的流量管理 API 体系，而非单一资源。
1. Gateway API 的核心设计理念
Gateway API 采用分层设计，将流量管理职责拆分为不同的 API 资源，实现 “关注点分离”：
- 基础设施层：定义网关的类型和实例（如用 Nginx 还是 Istio 作为网关）；
- 路由层：定义流量转发规则（如域名、路径、权重）；
- 策略层：定义安全、监控等附加策略（如 TLS 配置、跨域规则）。
这种设计支持多团队协作（如运维团队管理网关基础设施，开发团队管理自己的路由规则），同时提供更强的标准化和扩展性。
2. Gateway API 的核心资源
Gateway API 包含多个资源对象，核心的三个是：GatewayClass、Gateway、HTTPRoute（以 HTTP 流量为例）。
| 资源对象 | 作用 | 管理角色 |
| GatewayClass | 定义网关的 “类型”（如 Nginx 网关、Istio 网关），关联具体的控制器实现 | 集群管理员 |
| Gateway | 网关实例，绑定端口、TLS 配置等网络属性，是流量进入集群的 “入口点” | 运维团队 |
| HTTPRoute | 定义 HTTP/HTTPS 流量的转发规则（域名、路径、后端服务） | 开发 / 应用团队 |
（1）GatewayClass：网关类型定义
apiVersion: gateway.networking.k8s.io/v1kind: GatewayClassmetadata:name: nginx-gateway-class # 网关类型名称spec:controllerName: nginx.org/ingress-controller # 关联的控制器（如Nginx）# 可选：配置该类型网关的默认参数（如TLS协议版本）parametersRef:group: k8s.nginx.orgkind: NginxGatewayname: nginx-default-params（2）Gateway：网关实例与网络配置
apiVersion: gateway.networking.k8s.io/v1kind: Gatewaymetadata:name: prod-gateway # 网关实例名称spec:gatewayClassName: nginx-gateway-class # 关联上述GatewayClasslisteners: # 定义监听端口和协议- name: https # 监听名称（自定义）port: 443 # 端口protocol: HTTPS # 协议hostname: "*.example.com" # 支持泛域名tls: # HTTPS配置mode: Terminate # 在网关层终止TLScertificateRefs: # 引用证书Secret- kind: Secretname: example-tls- name: httpport: 80protocol: HTTPhostname: "*.example.com"tls:mode: RedirectToHTTPS # HTTP自动重定向到HTTPS（3）HTTPRoute：路由规则定义
apiVersion: gateway.networking.k8s.io/v1kind: HTTPRoutemetadata:name: api-route # 路由规则名称spec:parentRefs: # 关联到上面的Gateway实例- name: prod-gatewaysectionName: https # 关联Gateway中定义的https监听hostnames: # 匹配域名- "api.example.com"rules: # 路由规则- matches: # 匹配条件- path:type: PathPrefixvalue: /v1 # 匹配/v1路径backendRefs: # 转发到的后端服务- name: api-v1port: 8080weight: 90 # 90%流量- matches:- path:type: PathPrefixvalue: /v2backendRefs:- name: api-v2port: 8080weight: 10 # 10%流量（原生支持权重分流）3. Gateway API 的核心优势
相比 Ingress，Gateway API 解决了诸多痛点：
- 标准化扩展：高级特性（如权重分流、跨域）通过 API 原生字段支持，而非控制器特定的 annotations，换控制器无需修改配置；
- 多团队协作：通过资源拆分（GatewayClass 由集群管理员管理，HTTPRoute 由开发团队管理），实现权限隔离；
- 多协议支持：除 HTTP/HTTPS 外，还支持 TCPRoute、TLSRoute 等，覆盖更多场景；
- 灵活的策略附着：可通过 PolicyAttachment 将安全策略（如 JWT 认证）、监控策略等附加到路由或网关上，无需侵入路由规则。
四、Ingress 与 Gateway API 的关系：不是替代，而是演进
很多人认为 Gateway API 是 Ingress 的 “替代品”，但实际上两者的关系更像是 “演进”：
- 兼容性：主流 Gateway API 控制器（如 Nginx Gateway Fabric、Traefik）同时支持 Ingress 资源，可实现 “新旧规则共存”；
- 迁移路径：可通过工具（如 ingress2gateway）将 Ingress 配置自动转换为 Gateway API 资源，实现平滑迁移；
- 适用场景：
-
- 简单场景（如基础 HTTP 转发、单团队管理）：Ingress 足够轻量，无需迁移；
-
- 复杂场景（如多团队协作、高级流量控制、多协议支持）：Gateway API 更适合。
五、实战：从 Ingress 迁移到 Gateway API
下面通过一个实际案例，演示如何将 Ingress 配置迁移到 Gateway API，并验证效果。
1. 环境准备
- 安装 Gateway API CRD：
kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.0.0/standard-install.yaml- 部署支持 Gateway API 的控制器（以 Nginx Gateway Fabric 为例）：
kubectl apply -f https://raw.githubusercontent.com/nginxinc/nginx-gateway-fabric/v1.2.0/deploy/manifests.yaml2. 迁移 Ingress 配置
假设现有 Ingress 配置如下（前文示例），我们通过 ingress2gateway 工具转换：
# 安装转换工具go install sigs.k8s.io/gateway-api/cmd/ingress2gateway@latest# 转换Ingress资源（输出Gateway和HTTPRoute）ingress2gateway convert --ingress-name demo-ingress --namespace default转换后会生成对应的 Gateway 和 HTTPRoute 资源，结构与前文手动定义的类似。
3. 验证迁移效果
- 查看生成的 Gateway API 资源：
kubectl get gateway,httproute- 测试流量转发：
# 向api.example.com/v1发送请求，应转发到api-v1服务curl -k https://api.example.com/v1 --resolve api.example.com:443:<网关IP>- 验证 HTTPS 重定向：
# 发送HTTP请求，应自动重定向到HTTPScurl -L -v http://api.example.com/v1 --resolve api.example.com:80:<网关IP>六、总结：如何选择？
- 用 Ingress 如果你：
-
- 需求简单（基础 HTTP/HTTPS 转发）；
-
- 已熟悉 Ingress 生态，不想引入新复杂度；
-
- 使用的控制器不支持 Gateway API。
- 用 Gateway API 如果你：
-
- 需要高级特性（权重分流、多协议、跨团队协作）；
-
- 希望配置标准化，减少对特定控制器的依赖；
-
- 正在规划长期演进的流量管理架构。
从 Ingress 到 Gateway API，Kubernetes 流量管理的标准化和灵活性在不断提升。无论选择哪种方案，核心目标都是 “更高效、更安全、更灵活地管理流量”。对于大多数团队，建议从了解 Gateway API 开始，逐步在新业务中实践，再通过渐进式迁移完成旧系统的升级。
如果你正在使用 Ingress，不妨尝试用 Gateway API 实现一个简单的路由规则，对比两者的配置体验 —— 相信你会感受到新一代 API 带来的便利。