进击云原生

V2

2022/08/13阅读:15主题:萌绿

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

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 方面建立专业知识,而不是成为特定于供应商的专家,这将有助于构建更成熟的产品,专注于创造价值并更轻松地在不同环境中应用我们的技能。

原文: https://www.groundcover.com/blog/k8s-gateway-api

交流

请关注微信公众号【进击云原生】,扫码关注,了解更多咨询,更有免费资源供您学习

扫码关注,加群学习
扫码关注,加群学习

分类:

后端

标签:

后端

作者介绍

进击云原生
V2

公众号:进击云原生