K8s Gateway API 深度解析：新一代 Ingress 网关详解 – wiki词典

作者： /

K8s Gateway API 深度解析：新一代 Ingress 网关详解

前言：为何我们需要新的 Ingress？

在 Kubernetes 的世界里，Ingress API 自诞生以来，一直是将集群外部流量引入内部服务的标准方式。它简单、易于理解，通过一个 Ingress 对象，我们可以定义 HTTP/S 路由规则，将外部请求转发到集群内的 Service。然而，随着云原生应用的复杂性日益增加，Ingress API 的局限性也愈发明显：

  1. 功能贫乏与厂商锁定：Ingress 标准功能非常有限，仅覆盖了基础的主机和路径路由。诸如流量切分、Header 匹配、权重路由、重试等高级功能，都不得不通过 annotations 来实现。这导致了 Ingress 配置在不同 Ingress Controller（如 Nginx, Traefik, HAProxy）之间几乎无法移植，annotations 的语法和功能千差万别，造成了事实上的厂商锁定。
  2. 权限模型混乱：Ingress 对象通常由应用开发者创建，但它直接关联到底层的基础设施（负载均衡器）。这打破了职责分离的原则。基础设施管理员、集群运维和应用开发者之间的权限界限模糊，一个错误的 Ingress 配置可能影响整个集群的流量。
  3. 扩展性不足：除了 HTTP/S，现代应用还需要暴露 TCP、UDP 甚至 gRPC 服务。Ingress API 对此支持不佳，无法提供统一的配置模型。

为了解决这些痛点，Kubernetes 社区推出了新一代的流量管理规范 —— Gateway API。它并非 Ingress 的简单升级，而是一次彻底的、面向角色的、功能丰富的重新设计，旨在提供更强大、更具扩展性且真正标准化的 Kubernetes 服务暴露方式。

Gateway API 核心理念：面向角色的资源模型

Gateway API 最核心的设计是其面向角色的资源模型。它将一个完整的流量接入链路，拆分成了三个核心的、关注点分离的 API 资源，分别对应云原生环境中的三类典型角色：

  • 基础设施提供商 (Infrastructure Provider)
  • 集群运维 (Cluster Operator)
  • 应用开发者 (Application Developer)

Gateway API Roles

这种分离带来了清晰的权责划分，我们通过具体的资源来理解：

1. GatewayClass：网关模板

  • 角色：基础设施提供商 或 集群管理员。
  • 作用：GatewayClass 是一个集群级别的资源，它定义了一类网关的“模板”或“类别”。它描述了某种类型的负载均衡器实现，比如 “这是一个基于 Nginx 的网关”、“这是一个来自云厂商 XYZ 的 L4 负载均衡器”。
  • 示例：

yaml
apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
name: my-nginx-gateway-class
spec:
controllerName: "example.com/nginx-gateway-controller" # 关键：指定哪个控制器来实现这个 GatewayClass
parametersRef: # 可选：指向一个 CRD，用于定义该类网关的特定配置
group: "example.com"
kind: NginxGatewayConfig
name: my-nginx-config

2. Gateway：网关实例

  • 角色：集群运维。
  • 作用：Gateway 代表了一个网关实例的请求。集群运维通过创建 Gateway 资源，向基础设施申请一个具体的流量入口点（如一个公网 IP 的负载均衡器）。Gateway 绑定一个 GatewayClass，并定义监听的端口、协议和 TLS 证书等。
  • 示例：

yaml
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
name: my-gateway
namespace: networking
spec:
gatewayClassName: my-nginx-gateway-class
listeners:
- name: http
protocol: HTTP
port: 80
allowedRoutes:
namespaces:
from: Selector # 只允许特定标签的 Namespace 在此监听器上附加路由
selector:
matchLabels:
expose-apps: "true"
- name: https
protocol: HTTPS
port: 443
tls:
mode: Terminate
certificateRefs:
- name: my-tls-secret

这个设计非常精妙。集群运维现在可以精确控制哪些 Namespace 的应用可以附加到这个网关上（通过 allowedRoutes），实现了安全隔离。

3. HTTPRoute (及其他 Route 类型)：路由规则

  • 角色：应用开发者。
  • 作用：这是应用开发者用于定义具体路由逻辑的资源。他们不再关心底层是哪个负载均衡器，只需将自己的服务（通过 HTTPRoute）“附加”到一个已经存在的 Gateway 上即可。
  • 示例：

yaml
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
name: my-app-route
namespace: my-app
labels:
# 这个 namespace 必须匹配 Gateway 中 allowedRoutes 的 selector
expose-apps: "true"
spec:
parentRefs: # 核心：定义附加到哪个 Gateway
- name: my-gateway
namespace: networking # 跨 Namespace 附加
hostnames:
- "myapp.example.com"
rules:
# 规则1：将 /api 路径的流量转发到 api-service
- matches:
- path:
type: PathPrefix
value: /api
backendRefs:
- name: api-service
port: 8080
# 规则2：演示高级功能 - 基于 Header 的流量切分（金丝雀发布）
- matches:
- path:
type: PathPrefix
value: /
headers:
- type: Exact
name: env
value: canary
backendRefs: # 100% 流量到 v2 版本
- name: web-service-v2
port: 80
# 规则3：默认规则，90% 流量到 v1，10% 到 v2
- matches:
- path:
type: PathPrefix
value: /
backendRefs:
- name: web-service-v1
port: 80
weight: 90
- name: web-service-v2
port: 80
weight: 10

除了 HTTPRoute，Gateway API 还定义了 TCPRoute, UDPRoute, TLSRoute 和 GRPCRoute，为不同类型的应用流量提供了标准化的路由配置方案。

Gateway API vs. Ingress API：一次全面的进化

特性 Ingress API Gateway API 优势分析
角色模型 单一资源，权责不清 GatewayClass, Gateway, *Route 三层模型 清晰的职责分离，提升安全性与协作效率
表现力 基础的主机/路径匹配 权重、Header/Query 匹配、流量镜像、重试等 标准化的高级路由能力，告别 annotations 噩梦
可移植性 依赖 annotations，几乎为零 核心 API 保证跨实现的一致性 一次编写，多处运行。轻松更换网关实现
协议支持 主要是 HTTP/S HTTP, HTTPS, TCP, UDP, TLS, gRPC 统一的 API 模型管理所有类型的四层和七层流量
扩展性 通过 CRD 自行扩展，无标准 parametersRef 和自定义 *Route 类型 提供了官方指导的、结构化的扩展模式
所有权 Ingress 对象归属应用开发者 Gateway 归属集群运维，Route 归属开发者 Gateway 和 Route 的解耦，运维和开发互不干扰

GAMMA 计划：将 Gateway API 延伸至服务网格

Gateway API 的雄心不止于 Ingress（南北向流量）。GAMMA (Gateway API for Mesh Management and Administration) 计划旨在将 Gateway API 的能力扩展到服务网格（东西向流量）的管理。

传统上，服务网格（如 Istio, Linkerd）使用自己独有的 CRD（如 VirtualService, ServiceProfile）来配置服务间的流量。这带来了与 Ingress annotations 类似的问题：学习成本高，厂商锁定。

GAMMA 的核心思想是复用 HTTPRoute 等路由资源来定义服务网格内的流量规则。其关键实现是让 HTTPRoute 的 parentRefs 不仅可以指向一个 Gateway，还可以直接指向一个 Service。

yaml
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
name: reviews-route
namespace: default
spec:
parentRefs:
- name: reviews # 直接指向一个 Service
kind: Service
group: core
port: 9080
rules:
- backendRefs: # 定义 reviews 服务调用 ratings 服务时的策略
- name: ratings-v1
port: 9080
weight: 90
- name: ratings-v2
port: 9080
weight: 10

当 parentRef 是一个 Service 时，服务网格控制器会捕获这个 HTTPRoute，并将其规则应用到所有发往 reviews 服务的流量上。这意味着，无论是来自网关的外部流量，还是来自集群内其他服务的内部流量，都可以用同一套 API (HTTPRoute) 来进行精细化管理。

自 Gateway API v1.1 起，对服务网格的支持已进入 GA 阶段，这标志着使用一套 API 统一管理南北向和东西向流量的时代已经到来。

生态与未来

Gateway API 已经得到了业界的广泛支持。主流的 Ingress Controller 和服务网格项目都已经提供了实现：

  • Ingress Controllers: Nginx Gateway Fabric, Contour, Traefik, Kong, F5 BIG-IP 等。
  • Service Meshes: Istio, Linkerd, Kuma/Kong Mesh 等。

随着核心 API (GatewayClass, Gateway, HTTPRoute, GRPCRoute) 的相继 GA (General Availability)，Gateway API 已经足够稳定，可以在生产环境中使用。它不再是“未来的技术”，而是“现在的标准”。

结论

Kubernetes Gateway API 是对集群网络流量管理的一次彻底革新。它通过面向角色的设计，解决了 Ingress API 在权限、功能和扩展性上的诸多弊端。其丰富的内置功能和强大的可移植性，使复杂的流量场景（如金丝雀发布、A/B 测试）变得前所未有的简单和标准化。

更重要的是，通过 GAMMA 计划，Gateway API 成功地将 Ingress 和服务网格的管理模型统一起来，为实现云原生应用的流量治理提供了一个终极的、统一的控制平面。如果你还在为 Ingress 的 annotations 而烦恼，或是正在为如何选择和集成服务网格而困惑，那么现在就是拥抱 Gateway API 的最佳时机。它代表了 Kubernetes 流量管理的未来，一个更标准、更强大、更灵活的未来。

滚动至顶部