您现在的位置是：首页 > 文章详情

试用 Kubernetes Gateway API 的五大理由

日期：2024-08-28点击：143收藏

原文作者：Michael Pleshakov - F5 平台集成工程师

原文链接：试用 Kubernetes Gateway API 的五大理由

转载来源：NGINX 中文官网

NGINX 唯一中文官方社区，尽在 nginx.org.cn

Kubernetes 从早期阶段就包含一个 API — 内置 Ingress 资源，用于配置外部 HTTP 流量到 Service 的请求路由。虽然已被用户广泛采用并得到许多实现（如 Ingress controller）的支持，但 Ingress 资源在以下三大方面限制了其用户：

功能不足 – 减少了支持的用例数量。
可扩展性模型不佳 – 限制了对 NGINX 等许多数据平面中已有的高级功能的访问。
缺少不同的用户角色 – 阻碍了集群内多个团队之间安全共享数据平面基础设施。

为了应对这些限制，Kubernetes 社区设计了 Gateway API，这个新项目可更有效地替代 Ingress 资源。本文阐释了试用 Gateway API 的五大理由，并将其与 Ingress 资源进行了比较，另外还介绍了我们的开源项目 NGINX Gateway Fabric。该项目支持您在 Kubernetes 集群中启用 Gateway API，同时将 NGINX 用作数据平面。

注：Gateway API 支持与 Service 网络相关的多种用例，包括实验性 service mesh（服务网格）。不过，本文将重点介绍 Gateway API 的主要用例：将外部流量路由到集群中的 Service。此外，虽然 API 支持多个协议，但我们的探讨仅限于最常用的 HTTP 协议。

Gateway API 概述

Gateway API 是自定义资源的集合，可部署和配置数据平面，从而对集群内 Service 的 Service 网络流量进行建模。

以下是主要的 Gateway API 资源： 

GatewayClass – 定义尚未部署的数据平面模板。
Gateway – 从模板（GatewayClass）部署数据平面，并在其上配置入口点（端口）以接受外部流量。
HTTPRoute – 配置外部流量到集群内 Service 的 HTTP 请求路由规则，并将这些规则附加到 Gateway 定义的入口点。

Gateway API 的另一重要组成部分是网关实现，它是一个 Kubernetes 控制器，可根据 Gateway API 资源实际部署和配置数据平面。

如欲了解有关 API 的更多信息，请访问 Gateway API 项目网站或观看视频介绍。

试用 Gateway API 的理由有哪些？

以下为试用全新 Gateway API 的五大理由：

丰富的功能
强大的可扩展性模型
角色分离
可移植性
社区

下面我们来详细了解一下每个理由。

理由 1：丰富的功能

Gateway API 提供了大量功能，有助于解锁许多新用例，其中一些用例可能还未获得 Ingress 资源的全面支持。

这些用例包括：

灰度发布
A/B 测试
请求和响应操作
请求重定向
流量镜像
跨命名空间的流量路由

例如，下面是来自 HTTPRoute 的一个请求路由规则，它使用权重在两个 Kubernetes service 之间精分流量，以支持灰度发布用例。

 - matches: - path: type: PathPrefix value: / backendRefs: - name: my-app-old port: 80 weight: 95 - name: my-app-new port: 80 weight: 5

这样一来，数据平面将 95% 的请求路由到 Service my-app-old，将其余 5% 的请求路由到 my-app-new。

接下来的示例包含两个规则。其中一个规则利用了 Gateway API 高级路由功能，使用请求头和查询参数进行路由。

 - matches: # 规则 1 - path: type: PathPrefix value: /coffee backendRefs: - name: coffee-v1-svc port: 80 - matches: # 规则 2 - path: type: PathPrefix value: /coffee headers: - name: version value: v2 - path: type: PathPrefix value: /coffee queryParams: - name: TEST value: v2 backendRefs: - name: coffee-v2-svc port: 80

因此，在以下两种情况下，数据平面会将以 /coffee 开头的 URI 请求路由到 Service coffee-v2-svc：请求头版本为 v2，或者查询参数 TEST 为 v2（例如规则 2 中的 /coffee?TEST=v2）。同时，数据平面将所有对 /coffee 的请求路由到 coffee-v1-svc（如规则 1 所示）。

请参阅 HTTPRoute 文档，了解所有支持的功能。

理由 2：强大的可扩展性模型

Gateway API 采用强大的可扩展性模型，支持实现暴露 API 本身不支持的高级数据平面功能。尽管 Ingress controller 可通过应用注解（annotations）支持自定义扩展，从而绕过 Ingress 资源的一些限制，但 Gateway API 可扩展性模型还是优于 Ingress 可扩展性模型。

例如，在下面的示例中，使用 NGINX Ingress Controller 的注解扩展的资源可启用一些高级 NGINX 功能（对每项功能的说明已作为注释添加到注解旁边）：

 apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: webapp annotations: nginx.org/lb-method: "ip_hash" # 选择 ip_hash 负载均衡方法 nginx.org/ssl-services: "webapp" # 向后端开启 TLS nginx.org/proxy-connect-timeout: "10s" # 向后端配置超时 nginx.org/proxy-read-timeout: "10s" nginx.org/proxy-send-timeout: "10s" nginx.org/rewrites: "serviceName=webapp rewrite=/v1" # 重写请求 URI nginx.com/jwt-key: "webapp-jwk" # 启用对请求的 JWT 身份验证 nginx.com/jwt-realm: "Webb App" nginx.com/jwt-token: "$cookie_auth_token" nginx.com/jwt-login-url: "https://login.example.com" spec: rules: - host: webapp.example.com . . .

注解（annotations）本不适合用于表达如此大量配置，它只是简单的键值字符串对，缺乏结构、验证和细粒度。（我们所说的“缺乏细粒度”是指注解应用于整个资源，而不是像 Ingress 资源中的单个路由规则那样应用于资源的某些部分。）

Gateway API 包括一个功能强大的无注解可扩展性模型。该模型具有多个扩展点、自定义过滤器、策略附加及目的地，可支持 Gateway API 实现通过能够提供结构和验证的自定义资源来提供高级数据平面功能。此外，用户还可对资源的每个部分（如路由规则）应用扩展，从而进一步增加细粒度。

例如，以下是一个假想的 Gateway API 实现的自定义过滤器，它通过对 /coffee 规则精细应用速率限制来增强 HTTPRoute 中的路由规则：

 rules: - matches: - path: type: PathPrefix value: /coffee filters: - type: ExtensionRef extensionRef: group: someproxy.example.com kind: RateLimit name: coffee-limit backendRefs: - name: coffee port: 80

这样，Gateway API 实现将 coffee-limit 自定义资源中配置的过滤器应用于 /coffee 规则，其中速率限制规范如下所示：

 rateLimit: rate: 10r/s key: ${binary_remote_addr}

注：本例只是一个可能的扩展，而非具体实例，因为 NGINX Gateway Fabric 项目尚未利用 Gateway API 可扩展性模型。不过，未来这种情况将会改变，因为该项目将支持许多扩展，可让用户获得 Gateway API 无法提供的高级 NGINX 功能。

理由 3：角色分离

Ingress 资源仅支持单个用户角色（应用开发人员），该角色全权控制流量到达 Kubernetes 集群中应用的方式。但这种控制级别往往没有必要，甚至可能会妨碍多个开发人员团队安全地共享数据平面基础设施。

Gateway API 将部署和配置基础设施的职责分给三个角色：基础设施提供商、集群运维人员及应用开发人员。下表汇总了这些角色。

角色	Gateway API 资源的所有者	职责
基础设施提供商	GatewayClass	管理集群相关基础设施**
集群运维人员	Gateway, GatewayClass*	为应用开发人员管理集群
应用开发人员	HTTPRoute	管理应用

*如果集群运维人员安装并管理 Gateway API 实现，而非使用基础设施提供商提供的实现，那么他们将管理 GatewayClass 资源。

**类似于提供托管 Kubernetes 集群的云提供商。

上述角色实现了 RBAC 执行的职责分工。这种分工适用于企业的一种常见情况，即平台团队（集群运维人员）管理数据平面基础设施，并希望在集群中的多个开发人员团队（应用开发人员）之间对其进行安全共享。

理由 4：可移植性

Gateway API 的两个方面提高了其可移植性：

功能 – 如理由 1 所述，大量功能减少了对特定 Gateway API 实现扩展 API 的需求，这意味着用户将不太依赖于这些 API。相比之下，Ingress 用户高度依赖其 Ingress controller 的特定扩展。
一致性测试 – Gateway API 具有测试功能，可确保不同实现以一致的方式支持 API 功能。若要确保实现一致性，就必须通过一致性测试，如 NGINX Gateway Fabric 的测试结果所示。

得益于这种可移植性，用户可以轻松地从一个 Gateway API 实现切换到另一个 Gateway API 实现，这远比切换 Ingress controller 简单得多。

理由 5：社区

Gateway API 是一个社区驱动型项目，而且还是处于起步阶段的新项目。如果您希望为该项目贡献一己之力 — 无论是通过提出新功能还是提供反馈意见，请访问该项目的贡献页面。

如何试用 Gateway API

试用 Gateway API 只需简单两步：

将 Gateway API 安装到 Kubernetes 集群中。
安装一个 Gateway API 实现。

NGINX 创建了一个 Gateway API 实现 — NGINX Gateway Fabric。该实现将 NGINX 用作数据平面。若要试用，请按照其最新版本的安装说明进行操作。如要提出问题或参与项目，请查看我们的贡献指南。

我们的文档提供了若干指南和示例，展示了 Gateway API 支持的不同用例。如需更多支持，请查看 Kubernetes Gateway API 项目页面上的指南。

注：NGINX Gateway Fabric 是一个新项目，与我们类似的 NGINX Ingress Controller 项目相比，它尚未达到成熟的水平。此外，尽管 NGINX Gateway Fabric 支持 Gateway API 的所有核心功能（参见理由 1），但尚未为 NGINX 常用功能提供 Gateway API 扩展（参见理由 2），而 NGINX Ingress Controller 具备这些功能。