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
将路由从入口分离允许引入多种类型的路由（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 的功能：
HTTPRoute 头部匹配 HTTPRoute 方法匹配 插件引用转换为 HTTPRoutes ExtensionRef 过滤器 TCPIngress 转换为 Gateway、TCPRoutes 和 TLSRoutes UDPIngress 转换为 Gateway 和 UDPRoutes
立即尝试 Gateway API
Gateway API 最近发布了 v1.0.0 GA 版本，引起了很多关注。
我们相信 Gateway API 是 Kubernetes 网络的未来。因此，在最新的 Kong Ingress 控制器版本 (v3.0.0) 中，Gateway API 是配置 Kong 的首选方式。
为了简化开始使用 Gateway API 的过程，我们已经发布了一个 Kong Ingress Controller 的 分步指南。您可以快速开始使用。
要了解如何使用 Gateway API，请观看 这个 视频。它包含了一个从头开始构建的示例的一些功能演示。在教程中使用的所有 manifests 都可以在 这里 找到。
结论
Gateway API 可能是 Kubernetes 历史上最具合作性的 API，多个厂商和许多社区成员共同努力，确保它成为一个可以持续多年的标准。随着 GA 发布，Gateway API 正式达到生产可用。
整个 Gateway API 社区都期待着听取用户对这个巨大的 Kubernetes 网络进步的反馈。立即开始使用 Kong Ingress Controller 3.0，告诉我们您的想法。
《Docker中Image、Container与Volume的迁移》
免责声明：本文内容来源于网络，所载内容仅供参考。转载仅为学习和交流之目的，如无意中侵犯您的合法权益，请及时联系Docker中文社区！
如有侵权请联系:admin#unsafe.sh