Flagger发布1.19.0版本带来Gateway API支持

Flagger 团队很荣幸为你带来 Kubernetes Gateway API 支持，作为1.19.0 版本[1]的一部分。阅读本文，了解为什么这是 Flagger 的一个重大发展，以及如何利用它。

Flagger 是什么？

Flagger 是一个渐进的交付工具，它为运行在 Kubernetes 上的应用程序自动化了发布过程。它通过在测量指标和运行一致性测试的同时，逐渐将流量转移到新版本，降低了在生产中引入新软件版本的风险。

Flagger[2]旨在让开发人员使用交付技术（如：

• 金丝雀（canary）发布（渐进式流量转移）
• A/B 测试（HTTP 头和 cookies 流量路由）
• 蓝/绿（流量交换和镜像）

Gateway API 是什么？

公告博客帖子将其设计原则定义为

• 表达能力——除了 HTTP 主机/路径匹配和 TLS 之外，Gateway API 还可以表达 HTTP 头操作、流量加权和镜像、TCP/UDP 路由以及其他只能在 Ingress 中通过自定义注释才能实现的功能。
• 面向角色的设计——API 资源模型反映了在路由和 Kubernetes 服务网络中常见的职责分离。
• 可扩展性——资源允许在 API 的不同层上附加任意的配置。这使得在最合适的地方可以进行细粒度定制。
• 灵活的一致性——Gateway API 定义了不同的一致性级别——核心（强制支持）、扩展（如果支持则可移植）和自定义（没有可移植性保证），统称为灵活的一致性[3]。这促进了一个高度可移植的核心 API（如 Ingress），它仍然为网关控制器实现者提供灵活性。

Gateway API 暴露了一个比 Ingress 更通用的代理 API，你可以将它用于更多的协议，而不仅仅是 HTTP（尽管大多数实现目前只支持 HTTP）。它对更多基础架构组件进行建模，以提供更好的部署和管理选项。Gateway API 有三个核心组件：

• GatewayClass：这让我们可以定义我们想要使用哪个控制器实现。
• Gateway：Gateway 资源被附加到 GatewayClass，并且与实际的负载平衡基础设施具有 1:1 的关系。它允许我们定义一组侦听器，通过这些侦听器，我们可以指定为路由评估哪些 Route 资源，等等。
• HTTPRoute：这是一个特定于 HTTP 请求的 Route 资源。它定义了路由规则，如过滤器、路径和报头匹配等。以及该请求应该被转发给哪些服务。

这在 Flagger 是怎么运作的？

Flagger 利用了这样一个事实，即 HTTPRoute 允许用户在路由规则中，定义与每个服务引用相关的权重。这些权重用于确定哪个服务应该接收请求。例如，如果我们想将 10%的流量发送给另一个服务，我们可以像这样定义一个 HTTPRoute：

apiVersion: gateway.networking.k8s.io/v1alpha2
kind: HTTPRoute
metadata:
  name: foo-route
spec:
  parentRefs:
  - name: example-gateway
  hostnames:
  - "foo.example.com"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /login
    backendRefs:
    - name: foo-primary
      port: 8080
      weight: 90
    - name: foo-canary
      port: 8080
      weight: 10

这将到达 foo.example.com/login 的所有请求中的 10%发送到新服务，其余 90%发送到稳定服务。你可以在这里[4]阅读更多关于 Gateway API 流量分割的内容。

Flagger 完全自动化了 HTTPRoute 的创建，包括适当的头匹配、路径匹配等，并将主服务和金丝雀服务附加到 HTTPRoute。在 canary 分析过程中，与两种服务相关的权重会相应地进行调整。

如果你想马上开始，可以看看我们的教程[5]，它向你展示了如何使用 Contour 的 Gateway API 实现和 Flagger 来自动化 canary 部署。这不会花很长时间，但会传达这种整合是多么强大。

Flagger 适用于所有实现

由于增加了对 Gateway API 的支持，Flagger 现在可以与所有实现[6]一起工作，这意味着到今天为止，这些实现都是原生支持的：Contour、Emissary-Ingress、Google Kubernetes Engine、HAProxy Ingress、HashiCorp Consul、Istio、Kong 和 Traefik。

Flagger 团队已经使用 v1beta2 Gateway API 成功测试了 Contour 和 Istio。从 Flagger v1.19 开始，Gateway API 是我们使用 Contour 实现的端到端测试套件的一部分。

指标是如何工作

Gateway API 为流量管理定义了一个公共接口，这使我们不必做任何特定于供应商的事情。但是与流量相关的指标仍然特定于你使用的入口/服务网格。Flagger 允许你定义一个定制的资源 MetricTemplate，它针对你的指标提供者运行查询，并计算错误率、延迟等统计数据。例如，如果你将 Istio 与 Gateway API 一起使用，下面的 MetricTemplate 将在 canary 分析期间使用 Prometheus 作为提供者来计算错误率：

apiVersion: flagger.app/v1beta1
kind: MetricTemplate
metadata:
  name: error-rate
  namespace: istio-system
spec:
  provider:
    type: prometheus
    address: http://prometheus.istio-system:9090
  query: |
    100 - sum(
        rate(
            istio_requests_total{
                reporter="source",
                destination_workload_namespace="{{ namespace }}",
                destination_workload=~"{{ target }}",
                response_code!~"5.*"
            }[{{ interval }}]
        )
    )
    /
    sum(
        rate(
            istio_requests_total{
                reporter="source",
                destination_workload_namespace="{{ namespace }}",
                destination_workload=~"{{ target }}"
            }[{{ interval }}]
        )
    ) * 100

类似地，当使用任何基于 Envoy 的入口/服务网格时，下面的 MetricTemplate 允许 Flagger 计算延迟：

apiVersion: flagger.app/v1beta1
kind: MetricTemplate
metadata:
  name: latency
  namespace: flagger-system
spec:
  provider:
    type: prometheus
    address: http://flagger-prometheus:9090
  query: |
    histogram_quantile(0.99,
      sum(
        rate(
          envoy_cluster_upstream_rq_time_bucket{
            envoy_cluster_name=~"{{ namespace }}_{{ target }}-canary_[0-9a-zA-Z-]+",
          }[{{ interval }}]
        )
      ) by (le)
    ) / 1000

总结

Gateway API 处于 alpha 阶段。截至 2022 年 3 月 11 日，其GitHub README[8]称

这个项目的v0.4.0 版本[9]发布的最新支持版本是 v1alpha2。这个版本的 API 有望在未来升级为 beta 版，只需做相对较小的改动。

一旦 API 成为测试版/稳定版，我们在 Flux 项目将更新集成。

非常感谢Sanskar Jaiswal[10]所做的实现[11]！

我们很高兴为你带来这一功能，我们喜欢反馈！请让我们知道你是否有反馈，问题或者你将如何使用它！

参考资料

[1]1.19.0 版本: https://github.com/fluxcd/flagger/releases/tag/v1.19.0

[2]Flagger: https://github.com/fluxcd/flagger

[3]灵活的一致性: https://gateway-api.sigs.k8s.io/concepts/guidelines/#conformance

[4]Gateway API流量分割: https://gateway-api.sigs.k8s.io/v1alpha2/guides/traffic-splitting/

[5]教程: https://docs.flagger.app/tutorials/gatewayapi-progressive-delivery

[6]所有实现: https://gateway-api.sigs.k8s.io/implementations/

[7]Kubernetes Gateway API: https://gateway-api.sigs.k8s.io/

[8]GitHub README: https://github.com/kubernetes-sigs/gateway-api#status

[9]v0.4.0 版本: https://github.com/kubernetes-sigs/gateway-api/releases/tag/v0.4.0

[10]Sanskar Jaiswal: https://github.com/aryan9600

[11]实现: https://github.com/fluxcd/flagger/pull/1108