Kubernetes Gateway API V1.0：您应该切换吗？

本文介绍: 与 Ingress API 不同，Gateway API 是多个 API（HTTPRoute、Gateway、GatewayClass 等）的集合，每个 API 满足不同的组织角色。因此，如果您重新开始并在 Ingress 和 Gateway API 之间进行选择，如果您选择的 API 和实现支持您想要的所有功能，我建议您选择 Gateway API。去年，当网关 API升级为测试版时，我曾写过有关该 API的文章，但一年后，问题仍然存在。即，API 为自定义扩展留有空间，同时确保其遵循标准。

自Kubernetes Gateway API 发布 v1.0以来已经过去两个多月了，这标志着其一些关键 API 已经进入普遍可用状态。

去年，当网关 API升级为测试版时，我曾写过有关该 API的文章，但一年后，问题仍然存在。您是否应该从 Ingress API 切换到 Gateway API？

我去年的回答是你不应该。我有充分的理由。

Gateway API 及其实现仍处于起步阶段。另一方面，Ingress API 很稳定，涵盖了一些可能适合大多数用户的主要用例。

对于需要更多功能的用户，我建议通过权衡可移植性（在不同 Ingress 实现之间切换）来使用 Ingress 控制器提供的自定义资源。

随着 v1.0 版本的发布，这种情况可能会改变。Gateway API 现在功能更加强大，其20 多个实现正在迅速赶上。

因此，如果您重新开始并在 Ingress 和 Gateway API 之间进行选择，如果您选择的 API 和实现支持您想要的所有功能，我建议您选择 Gateway API。

Ingress API 出了什么问题？

Ingress API工作得很好，但仅适用于一小部分常见用例。为了扩展其功能，Ingress 实现开始使用自定义注释。

例如，如果您选择 Nginx Ingress，那么如果您决定切换到Apache APISIX等其他 Ingress 实现，您将使用其数十个不可移植的注释中的一些注释。

这些特定于实现的注释管理起来也很麻烦，并且违背了以 Kubernetes 原生方式管理 Ingress 的目的。

最终，Ingress 控制器实现开始开发其 CRD，以向 Kubernetes 用户公开更多功能。这些 CRD 特定于 Ingress 控制器。但如果您可以牺牲便携性并坚持使用一个 Ingress 控制器，那么 CRD 会更易于使用并提供更多功能。

Gateway API 旨在通过提供 Ingress API 的供应商不可知性和 CRD 的灵活性来一劳永逸地解决这个问题。它处于非常有利的位置来实现这一目标。

从长远来看，Ingress API预计不会获得任何新功能，并且将尽一切努力与Gateway API融合。因此，当您无意中触及 Ingress API 的功能限制时，采用 Ingress API 可能会导致问题。

明显的好处

富有表现力、可扩展和面向角色是塑造 Gateway API 开发的关键思想。

与 Ingress API 不同，Gateway API 是多个 API（HTTPRoute、Gateway、GatewayClass 等）的集合，每个 API 满足不同的组织角色。

例如，应用程序开发人员只需要关心 HTTPRoute 资源，他们可以在其中定义路由流量的规则。他们可以将集群级别的详细信息委托给管理集群的操作员，并确保它使用网关资源满足开发人员的需求。

这种面向角色的API 设计允许不同的人在保持控制的同时使用集群。

Gateway API 的功能也比 Ingress API 强大得多。Gateway API 开箱即用地支持 Ingress API 中需要注释的功能。

官方扩展

尽管 Gateway API 是官方的 Kubernetes API，但它是作为一组 CRD 实现的。

这与使用默认的 Kubernetes 资源没有什么不同。但你只需像安装官方扩展一样安装这些 CRD即可。

APISIX 的网关 API 支持

Ingress 控制器将 Kubernetes 资源转换为 API 网关实现的 APISIX 配置。

与缓慢走向长期稳定的 Kubernetes 相比，这允许快速迭代。

它会扩散吗？

正如这位著名的 XKCD 漫画经常提醒我们的那样，标准往往会激增。

在 Ingress 和 Gateway API 中可以看到这样的一个版本。通常是这样的：

出现了一个标准来统一不同的项目/它们的标准（Kubernetes Ingress API）。
统一标准存在实施者想要克服的局限性（Ingress API 受到限制）。
由于这些限制（自定义 CRD、注释），实现与标准有所不同。
现在每个实现都有其标准（不可移植的 CRD、注释）。
一个新标准的出现来统一这些不同的标准（Kubernetes Gateway API）。

有理由认为 Gateway API 可能不是这里的最终游戏。但我相信它完全有可能成为 Kubernetes 中路由的标准。

再说一次，我有我强有力的理由。

广泛采用对于防止标准扩散至关重要，因为实施不同标准的动力较少。Gateway API 已经有超过 25 个实现。

实现可以在不同级别上符合网关 API：

核心：所有实现都应符合这些要求。
扩展：这些可能仅在某些实现中可用，但它们是标准 API。
特定于实现：特定于实现，但通过标准扩展点添加。

随着越来越多的实现支持这些功能，利基功能可以从特定于实现转移到扩展至核心。即，API 为自定义扩展留有空间，同时确保其遵循标准。

服务网格接口 (SMI)项目是一个类似的尝试，旨在标准化 Kubernetes 中的服务网格配置。然而，在服务网格项目最初参与之后，该项目几乎没有受到关注，并慢慢消亡。

SMI 不支持用户期望在服务网格中使用的许多共同特性。它的发展速度也不够快，无法支持这些功能。最终，服务网格实现在遵守 SMI 方面落后了（我曾经在CNCF TAG 网络下与 SMI 密切合作，从事一个报告 SMI 一致性的项目）。

这些都是普遍原因，但该项目现在正在通过 Gateway API 复活。用于网格管理和管理的网关 API (GAMMA) 计划旨在扩展网关 API 以与服务网格配合使用。

SMI 项目最近与 GAMMA 计划合并，这对于网关 API 来说非常好。Istio 无疑是最受欢迎的服务网格，它也宣布 Gateway API 将成为未来管理 Istio 的默认 API。这种收养可以防止扩散。

迁移指南

网关API 文档提供了有关将 Ingress 资源迁移到网关资源的全面指南。我们不再重述，而是尝试使用ingress2gateway工具将我们的 Ingress 资源转换为相应的 Gateway API 资源。

您可以直接从发布页面下载并安装适用于您的操作系统的二进制文件。

我们来看一个简单的 Ingress 资源：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: httpbin-route
spec:
  ingressClassName: apisix
  rules:
    - host: local.httpbin.org
      http:
        paths:
          - backend:
              service:
                name: httpbin
                port:
                  number: 80
            path: /
            pathType: Prefix

这会将具有提供的主机地址的所有流量路由到该httpbin服务。

要将其转换为网关 API 资源，我们可以运行：

ingress2gateway print --input_file=ingress.yaml

该网关 API 资源如下所示：

apiVersion: gateway.networking.k8s.io/v1alpha2
kind: HTTPRoute
metadata:
  name: httpbin-route
spec:
  hostnames:
  - local.httpbin.org
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /
    backendRefs:
    - name: httpbin
      port: 80