K8s 暴露服务的新方法 Gateway API 详解，它有什么好处？

前段时间，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 对象定义中表达，而不是让供应商通过自定义注释来定义。
此增强提供了几个好处：

1. 可移植性：考虑到不同的网关供应商，对象不太容易发生变化

2. 专业知识：让工程师专注于熟悉 Kubernetes 规范而不是供应商特定的规范。

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

 

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: "groundcover-app"
  namespace: "app"
  annotations:
    kubernetes.io/ingress.class: alb
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip
    alb.ingress.kubernetes.io/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.networking.k8s.io/v1beta1
kind: Gateway
metadata:
  name: prod-web
spec:
  gatewayClassName: acme-lb
  listeners:
  - protocol: HTTP
    port: 80
    name: prod-web-gw
    allowedRoutes:
      namespaces:
        from: Same

apiVersion: gateway.networking.k8s.io/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 对象。

以下是此类设置的说明：

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

apiVersion: gateway.networking.k8s.io/v1beta1
kind: Gateway
metadata:
  name: shared-gateway
  namespace: infra-ns
spec:
  gatewayClassName: shared-gateway-class
  listeners:
  - name: https
    hostname: "foo.example.com"
    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.networking.k8s.io/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 方面建立专业知识，而不是成为特定于供应商的专家，这将有助于构建更成熟的产品，专注于创造价值并更轻松地在不同环境中应用我们的技能。