Kubernetes流量管理：从Ingress到GatewayAPI演进

K_i1342025-10-20 16:40

从 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/v1

kind: Ingress

metadata:

name: demo-ingress

annotations:

# 配置HTTPS重定向（依赖控制器支持）

nginx.ingress.kubernetes.io/ssl-redirect: "true"

spec:

# 绑定TLS证书（存储在Secret中）

tls:

- hosts:

- api.example.com

secretName: api-tls # 包含tls.crt和tls.key的Secret

rules:

- host: api.example.com # 匹配域名

http:

paths:

- path: /v1 # 匹配路径

pathType: Prefix

backend:

service:

name: api-v1 # 转发到v1版本服务

port:

number: 8080

- path: /v2

pathType: Prefix

backend:

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/v1

kind: GatewayClass

metadata:

name: nginx-gateway-class # 网关类型名称

spec:

controllerName: nginx.org/ingress-controller # 关联的控制器（如Nginx）

# 可选：配置该类型网关的默认参数（如TLS协议版本）

parametersRef:

group: k8s.nginx.org

kind: NginxGateway

name: nginx-default-params
（2）Gateway：网关实例与网络配置
复制代码
复制代码 
apiVersion: gateway.networking.k8s.io/v1

kind: Gateway

metadata:

name: prod-gateway # 网关实例名称

spec:

gatewayClassName: nginx-gateway-class # 关联上述GatewayClass

listeners: # 定义监听端口和协议

- name: https # 监听名称（自定义）

port: 443 # 端口

protocol: HTTPS # 协议

hostname: "*.example.com" # 支持泛域名

tls: # HTTPS配置

mode: Terminate # 在网关层终止TLS

certificateRefs: # 引用证书Secret

- kind: Secret

name: example-tls

- name: http

port: 80

protocol: HTTP

hostname: "*.example.com"

tls:

mode: RedirectToHTTPS # HTTP自动重定向到HTTPS
（3）HTTPRoute：路由规则定义
复制代码
复制代码 
apiVersion: gateway.networking.k8s.io/v1

kind: HTTPRoute

metadata:

name: api-route # 路由规则名称

spec:

parentRefs: # 关联到上面的Gateway实例

- name: prod-gateway

sectionName: https # 关联Gateway中定义的https监听

hostnames: # 匹配域名

- "api.example.com"

rules: # 路由规则

- matches: # 匹配条件

- path:

type: PathPrefix

value: /v1 # 匹配/v1路径

backendRefs: # 转发到的后端服务

- name: api-v1

port: 8080

weight: 90 # 90%流量

- matches:

- path:

type: PathPrefix

value: /v2

backendRefs:

- name: api-v2

port: 8080

weight: 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.yaml

2. 迁移 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请求，应自动重定向到HTTPS

curl -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 带来的便利。

相关推荐
蓝色土耳其love5 小时前
centos 7.9 安装单机版k8s
linux·运维·服务器·kubernetes·centos
七度光阴；6 小时前
Docker入门手册
运维·docker·容器
007php0078 小时前
百度面试题解析：Zookeeper、ArrayList、生产者消费者模型及多线程(二)
java·分布式·zookeeper·云原生·职场和发展·eureka·java-zookeeper
weixin_405023378 小时前
使用docker 安装部署easy-mock
运维·docker·容器
Asuncion0078 小时前
Docker核心揭秘：轻量级虚拟化的革命
服务器·开发语言·docker·云原生
ZLRRLZ8 小时前
【Docker】Docker Image（镜像）
运维·docker·容器
小熊h8 小时前
Kubernetes(K8s) —— 部署（保姆级教程）
云原生·容器·kubernetes
祁同伟.10 小时前
【C++】二叉搜索树（图码详解）
开发语言·数据结构·c++·容器·stl
一个处女座的暖男程序猿10 小时前
若依微服务 nacos的配置文件
微服务·云原生·架构
热门推荐
01GitHub 镜像站点02BongoCat - 跨平台键盘猫动画工具03UV安装并设置国内源04GitLab 零基础入门指南：从安装到项目管理全流程05Linux下V2Ray安装配置指南06KGG转MP3工具|非KGM文件|解密音频07两千字总结：Codex 国内如何安装和使用的教程，以及如何设置中文回答082025软件测试面试八股文（含答案+文档）09NVIDIA显卡驱动、CUDA、cuDNN 和 TensorRT 版本匹配指南10在VSCode配置Java开发环境的保姆级教程（适配各类AI编程IDE）