Gateway API : 在 Kubernetes 网络中掀起一场革命-工具盒子

Gateway API : 在 Kubernetes 网络中掀起一场革命第1张

Kubernetes Gateway API 代表了 Kubernetes 网络的关键进步。由多个厂商和社区成员共同开发，Gateway API 为管理入口流量提供了一个健壮且可扩展的新标准。随着最近 1.0.0 版本的正式发布，Gateway API 现已准备好投入生产使用。

Gateway API 的发布是 Kubernetes 网络的重要里程碑，有可能简化并增强 Ingress 管理。在这篇文章中，我们将探讨 Gateway API 是什么，它是如何改进现有的 Ingress API 的，以及如何开始使用它。

什么是 Gateway API？

Gateway API 最初在 2019 年的圣地亚哥 KubeCon 上提出，是 Kubernetes 的下一代 Ingress API。它旨在管理来自集群外部客户端到集群内部服务的流量 ------ 即入口或南北流量。然而，Gateway API 正逐渐成为管理服务间（东西）流量的热门方式，这得益于一个正在被多个实现尝试和测试的实验性项目 GAMMA。

Gateway API 与 Ingress API 之间的主要区别是添加了路由，这些路由是用于在 L4 和 L7 层实现路由的单独资源。当本文后面提到 *Route 时，它指的是 HTTPRoute、TCPRoute 或任何其他可用的 Gateway API 路由资源。

Gateway API 包含许多新资源。如果您想尝试使用它，创建 Gateway API 配置所需的最小资源集包括：

Gateway --- 集群访问点
GatewayClass --- 描述将处理 Gateway 流量的实际类型的网关控制器
*Route --- 实现从 Gateway 到后端服务的流量路由

为什么需要 Gateway API？

Ingress API 缺乏许多功能，使用户无法满足常见的路由需求。Ingress API 不能根据查询字符串参数进行匹配，也不能定义 L4 路由。同样的，基于头部或 HTTP 方法的匹配也无法实现。这种现成 API 功能的缺乏迫使各类 API 实现（Ingress controller）在 API 规范之上创建了自定义的扩展机制，例如各类 annotations。

这导致了我们今天所处的 Ingress API 注解地狱。您可以学习 Ingress API，但这只是您需要了解的 20%。如果您想尝试从一个提供商迁移到另一个提供商，则需要学习更多新的内容。Gateway API 解决了这个问题。

除了核心路由需求外，Ingress API 的权限模型对于实际使用来说还不够。Gateway API 通过引入新的 API 层（Routes），显著改进了权限模型，将管理集群生命周期的各种角色的任务隔离开来。

Kong Ingress Controller 如何改进原生 Ingress API

由于 Ingress API 没有专门为此而设计，实现者必须选择如何满足用户需求。Kong Ingress Controller 通过 annotations 和 CRD 改进了 Ingress API。

konghq.com/ 前缀的 annotations 丰富了 Ingress 语义，提供了 Kong 网关所提供的所有可能性和功能，如头部匹配、方法匹配和插件附件。

除了注解外，Kong Ingress 控制器还提供了新的 CRD，允许用户不仅暴露 L7，还可以暴露 L4 服务。TCPIngresses 允许路由 TCP 和 TLS 服务，而 UDPIngresses 用于 UDP 流量。这些资源与常规 Ingress 非常相似，但由于缺乏定义的上游标准，它们被实现为特定于供应商的资源。

此外，KongIngress 作为 Ingress 装饰器提供，允许在后端服务之上指定上游功能。一个常见的例子是控制如何将传入请求在多个服务之间进行负载均衡。

Gateway API 如何改进 Ingress API

Gateway API 在许多不同方面改进了 Ingress API。首先是将 Routes 作为单独的 API 引入。以下是 Ingress 和 Gateway API 在 API 和互连方面的差异图。

Ingress API

Gateway API : 在 Kubernetes 网络中掀起一场革命第2张 img

Gateway API

Gateway API : 在 Kubernetes 网络中掀起一场革命第3张 img

将路由从入口分离允许引入多种类型的路由（L4 和 L7），并将允许在未来引入新的路由。Gateway API 目前支持以下路由类型（以不同程度的成熟度表示）：

HTTPRoute (v1)
GRPCRoute (v1alpha2)
TLSRoute (v1alpha2)
TCPRoute (v1alpha2)
UDPRoute (v1alpha2)

除了这些 Routes 外，Gateway API 还添加了全新的路由功能，以便为用户提供服务。

HTTP 头部匹配

HTTPRoute 中的 Headers 字段允许进行 HTTP 请求头部匹配。多个匹配值被视为 AND，这意味着请求必须匹配所有指定的头部才能选择路由。

HTTP 方法匹配

HTTPRoute 中的 Method 字段指定要匹配的 HTTP 方法。当指定时，只有请求具有指定方法时才会进行匹配。

HTTP 查询参数匹配

HTTPRoute 中的 QueryParams 字段指定请求中必须存在的查询参数。多个匹配值被视为 AND，这意味着请求必须匹配所有指定的查询参数才能选择路由。

HTTP 路由后端权重

HTTPRoute backendRef Weight 指定将请求转发到引用后端的比例。这是通过 weight/(此 BackendRefs 列表中所有权重的总和) 计算的。如果服务 A 的权重为 200，服务 B 的权重为 100，那么 2/3 的请求将转发到服务 A。

HTTPRoute 过滤器

HTTPRoute 过滤器是一种指定附加行为的方式，例如在处理路由时修改请求头或启用请求镜像。有不同类型的过滤器，还可以通过 ExtensionRef 字段将自定义过滤器附加到规则。这个扩展点可以用于将 Kong 插件附加到路由。

跨命名空间引用

与 Ingress API 相反，现在可以以跨命名空间的方式引用对象。这里有两个主要用例：

命名空间 A 中的 Gateway 和 Route 引用命名空间 B 中的服务。这种引用默认情况下被阻止，可以通过 ReferenceGrant API 启用。
命名空间 B 中的 Route 配置命名空间 C 中的 Gateway。这也是默认阻止的，但可以使用 AllowedRoutes 字段启用。

向 API 添加功能的标准化方法

Gateway API 定义了通过 PolicyAttachment 规范自定义和丰富 API 功能的标准方法。这个规范的第一个示例是 BackendTLSPolicy，这是一个旨在通过 Service API 对象指定从网关到后端 pod/s 的 TLS 连接配置的 API。

从 Ingress 迁移到 Gateway API

Ingress API 已经存在很长时间了。手动从 Ingress 迁移到 Gateway API 是一个耗时且容易出错的过程。由于 Ingress API 是 Gateway API 功能的子集，因此可以以编程方式转换资源。这就是为什么我们构建了 ingress2gateway。

Ingress2gateway 主要关注将 Ingress 和特定于 Provider 的资源（CRD）转换为 Gateway API 资源。该项目是基于提供商的，这意味着任何 Gateway API 实现都可以贡献一个提供商，将所有与 Ingress 相关的注解和 CRD 转换为 Gateway API 资源。

Kong 已经实现了自己的 Provider，具有以下从 Ingress 正确转换为 Gateway 的功能：