前段时间,​​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 组件的底层(这就是这个版本令人兴奋的原因)。

让我们看看这个层次结构实际上是什么样子的:

K8s 暴露服务的新方法 Gateway API 详解,它有什么好处?_命名空间

面向角色的 API:一个集群,多个用户,不同角色

Gateway API 的第一个直接好处是它可以更好地分离关注点。

Ingress 对象很棒,是 Devops 和 App 工程师通常需要一起弄清楚配置的微妙对象,应用程序开发人员知道应用程序的路由,但通常不知道诸如 TLS 证书之类的细节,这些细节通常在 Devops 域,在同一个 Ingress 对象中发生的这个和其他配置正在阻止双方的自治,并为错误配置留出更多空间。

在新的 Gateway API 中,Gateway API 将这些和其他配置解耦为 Gateway 和 Route 对象,允许应用程序工程师和 Devops 工程师/集群操作员自由安全地行动,如下所示:

K8s 暴露服务的新方法 Gateway API 详解,它有什么好处?_应用程序_02

简化的功能

新 API 的另一个主要好处是,更多功能在 Gateway API 对象定义中表达,而不是让供应商通过自定义注释来定义。
此增强提供了几个好处:

  1. 可移植性:考虑到不同的网关供应商,对象不太容易发生变化
  2. 专业知识:让工程师专注于熟悉 Kubernetes 规范而不是供应商特定的规范。

让我们举个例子,这里是您如何使用 Ingress 对象和 AWS alb 定义流量拆分。

apiVersion: /v1
kind: Ingress
metadata:
name: "groundcover-app"
namespace: "app"
annotations:
kubernetes.io/ingress.class: alb
/scheme: internet-facing
/target-type: ip
/actions.blue-green: |
{
"type":"forward",
"forwardConfig":{
"targetGroups":[
{
"serviceName":"groundcover-app-v1",
"servicePort":"80",
"weight":80
},
{
"serviceName":"groundcover-app-v2",
"servicePort":"80",
"weight":20
}
]
}
}
labels:
app: groundcover-app
spec:
rules:
- http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: blue-green
port:
name: use-annotation

正如您所看到的,这里有很多供应商特定的定义,大量使用注释,但是,使用新的 Gateway API,等效的将是

apiVersion: gateway./v1beta1
kind: Gateway
metadata:
name: prod-web
spec:
gatewayClassName: acme-lb
listeners:
- protocol: HTTP
port: 80
name: prod-web-gw
allowedRoutes:
namespaces:
from:
apiVersion: gateway./v1beta1
kind: HTTPRoute
metadata:
name: "hello-kubernetes"
labels:
gateway: prod-web-gw
spec:
hostnames:
- app.groundcover.com
rules:
- backendRefs:
- name: groundcover-app-v1
port: 80
weight: 90
- name: groundcover-app-v2
port: 80
weight: 10

如您所见,这里的配置要简洁很多,并且定义是完全可移植的!

跨命名空间路由

作为理解的一部分,在 Kubernetes 集群中有不同的角色操作不同的组件,因此需要支持跨命名空间引用,因为这些不同的组织单元通常在不同的命名空间中运行,同时仍然使用通用的基础设施组件,例如 TLS 证书,主机名等等。

为了实现上述功能,Gateway API 支持在一个集群中建立 Gateway 对象,并在引用它的每个应用程序/组织单元命名空间中创建 Route 对象。

以下是此类设置的说明:

K8s 暴露服务的新方法 Gateway API 详解,它有什么好处?_命名空间_03

基础设施运营商还可以明确限制谁可以将 Route 对象注册到网关,在我们的示例中,网关定义如下:

apiVersion: gateway./v1beta1
kind: Gateway
metadata:
name: shared-gateway
namespace: infra-ns
spec:
gatewayClassName: shared-gateway-class
listeners:
- name: https
hostname: ""
protocol: HTTPS
port: 443
allowedRoutes:
namespaces:
from: Selector
selector:
matchLabels:
shared-gateway-access: "true"
tls:
certificateRefs:
- name: foo-example-com

网关将只允许带有 shared-gateway-access: “true” 标签的命名空间使用共享网关,因此在我们的示例中,命名空间对象必须定义如下:

apiVersion: v1
kind: Namespace
metadata:
name: infra-ns
labels:
shared-gateway-access: "true"
---
apiVersion: v1
kind: Namespace
metadata:
name: site-ns
labels:
shared-gateway-access: "true"
---
apiVersion: v1
kind: Namespace
metadata:
name: store-ns
labels:
shared-gateway-access: "true"

一旦部署了这些层,应用程序开发人员就可以注册他们的 Route 对象,引用共享网关。

在我们的示例中,store Route 对象将如下所示:

apiVersion: gateway./v1beta1
kind: HTTPRoute
metadata:
name: store
namespace: store-ns
spec:
parentRefs:
- name: shared-gateway
namespace: infra-ns
rules:
- matches:
- path:
value: /store
backendRefs:
- name: store
port: 8080

K8s 通用 API 的价值

本文严重依赖 Kubernetes SIG-Network,他们在​​记录​​​新 API 方面做得非常出色,如果您现在有兴趣尝试 Gateway API,他们​​在此处​​列出了可用的实现。

Kubernetes 正在迅速变化,尽管适应这些变化很困难,有时令人沮丧。但这绝对值得。

在我看来,社区在收集案例研究并以负责任的方式统一它们方面做得非常出色。

让 Kubernetes 用户能够在通用 API 方面建立专业知识,而不是成为特定于供应商的专家,这将有助于构建更成熟的产品,专注于创造价值并更轻松地在不同环境中应用我们的技能。