前段时间,Kubernetes SIG-Network 发布了备受期待的 Gateway API 0.5.0 版。主要组件的 Api 正在升级到 beta (v1beta1),这意味着我们很快就会看到更多使用这些原语的项目。
让我们回顾一下 Gateway API 的基础知识,它旨在解决什么,它有什么好处。
什么是 K8s Gateway API?
Gateway API 是新的官方 Kubernetes 资源的集合,它们定义了由供应商实现的规范,类似于 Ingress 由 Google、Amazon 等实现的方式。
它引入的新资源有:
- Gateway( beta )
- GatewayClass ( beta )
- HTTPRoute ( beta )
- ReferenceGrant(仍处于 alpha 阶段,替换 ReferencePolicy )
- TCPRoute(仍处于 alpha 阶段)
- TLSRoute(仍处于 alpha 阶段)
- UDPRoute(仍处于 alpha 阶段)
SIG-Network 所述的新Gateway API的目标是:
- 面向角色:Gateway 由 API 资源组成,这些 API 资源对使用和配置 Kubernetes 服务网络的组织角色进行建模。
- 便携:这不是一种改进,而是应该保持不变的东西。正如 Ingress 是一个具有多种实现的通用规范一样,Gateway API 被设计为一种可移植的规范,由许多实现支持。
- 富有表现力:Gateway API 资源支持诸如基于
header的匹配、流量加权和其他核心功能,这些功能只能通过自定义注释在 Ingress 中实现。 - 可扩展:Gateway API 允许在 API 的各个层链接自定义资源。这使得在 API 结构中的适当位置进行细粒度定制成为可能。
Gateway 和 GatewayClass 是基础设施级别的组件,它们是 XRoute 组件的底层(这就是这个版本令人兴奋的原因)。
让我们看看这个层次结构实际上是什么样子的:

面向角色的 API:一个集群,多个用户,不同角色
Gateway API 的第一个直接好处是它可以更好地分离关注点。
Ingress 对象很棒,是 Devops 和 App 工程师通常需要一起弄清楚配置的微妙对象,应用程序开发人员知道应用程序的路由,但通常不知道诸如 TLS 证书之类的细节,这些细节通常在 Devops 域,在同一个 Ingress 对象中发生的这个和其他配置正在阻止双方的自治,并为错误配置留出更多空间。
在新的 Gateway API 中,Gateway API 将这些和其他配置解耦为 Gateway 和 Route 对象,允许应用程序工程师和 Devops 工程师/集群操作员自由安全地行动,如下所示:

简化的功能
新 API 的另一个主要好处是,更多功能在 Gateway API 对象定义中表达,而不是让供应商通过自定义注释来定义。
此增强提供了几个好处:
- 可移植性:考虑到不同的网关供应商,对象不太容易发生变化
- 专业知识:让工程师专注于熟悉 Kubernetes 规范而不是供应商特定的规范。
让我们举个例子,这里是您如何使用 Ingress 对象和 AWS alb 定义流量拆分。
正如您所看到的,这里有很多供应商特定的定义,大量使用注释,但是,使用新的 Gateway API,等效的将是
如您所见,这里的配置要简洁很多,并且定义是完全可移植的!
跨命名空间路由
作为理解的一部分,在 Kubernetes 集群中有不同的角色操作不同的组件,因此需要支持跨命名空间引用,因为这些不同的组织单元通常在不同的命名空间中运行,同时仍然使用通用的基础设施组件,例如 TLS 证书,主机名等等。
为了实现上述功能,Gateway API 支持在一个集群中建立 Gateway 对象,并在引用它的每个应用程序/组织单元命名空间中创建 Route 对象。
以下是此类设置的说明:

基础设施运营商还可以明确限制谁可以将 Route 对象注册到网关,在我们的示例中,网关定义如下:
网关将只允许带有 shared-gateway-access: “true” 标签的命名空间使用共享网关,因此在我们的示例中,命名空间对象必须定义如下:
一旦部署了这些层,应用程序开发人员就可以注册他们的 Route 对象,引用共享网关。
在我们的示例中,store Route 对象将如下所示:
K8s 通用 API 的价值
本文严重依赖 Kubernetes SIG-Network,他们在记录新 API 方面做得非常出色,如果您现在有兴趣尝试 Gateway API,他们在此处列出了可用的实现。
Kubernetes 正在迅速变化,尽管适应这些变化很困难,有时令人沮丧。但这绝对值得。
在我看来,社区在收集案例研究并以负责任的方式统一它们方面做得非常出色。
让 Kubernetes 用户能够在通用 API 方面建立专业知识,而不是成为特定于供应商的专家,这将有助于构建更成熟的产品,专注于创造价值并更轻松地在不同环境中应用我们的技能。
















