本文发布时间超过一年。较旧的文章可能包含过时的内容。请检查页面中的信息自发布以来是否已变得不正确。

介绍 ingress2gateway；简化 Gateway API 的升级

作者：Lior Lieberman (Google), Kobi Levi (independent) |

今天，我们发布了 ingress2gateway，一个可以帮助您从 Ingress 迁移到 Gateway API 的工具。Gateway API 距离 GA 版本只有几周时间了，如果您还没有升级，现在是时候考虑一下了！

背景

在不断发展的 Kubernetes 世界中，网络发挥着至关重要的作用。随着越来越多的应用程序部署在 Kubernetes 集群中，如何有效地将这些服务暴露给客户端成为一个关键问题。如果您一直在使用 Kubernetes，您可能很熟悉 Ingress API，它一直是管理外部访问服务的首选解决方案。

Ingress API 提供了一种将外部流量路由到集群内应用程序的方法，使其成为许多 Kubernetes 用户不可或缺的工具。然而，Ingress 存在其局限性，并且随着应用程序变得越来越复杂，对 Kubernetes 集群的需求增加，这些局限性可能会成为瓶颈。

一些限制是

  • 通用公分母不足 - 通过尝试为各种 HTTP 代理建立通用公分母，Ingress 只能容纳基本的 HTTP 路由，迫使流量拆分和标头匹配等当代代理的更多功能进入提供商特定的、不可移植的注释中。
  • 权限模型不足 - Ingress 规范在一个对象中配置基础设施和应用程序配置。使用 Ingress，集群操作员和应用程序开发人员在同一个 Ingress 对象上操作，而彼此不知道对方的角色。这创建了一个不足的角色访问控制，并且具有很高的设置错误潜力。
  • 缺乏协议多样性 - Ingress 主要关注 HTTP(S) 路由，不提供对其他协议（如 TCP、UDP 和 gRPC）的本机支持。这种限制使其不太适合处理非 HTTP 工作负载。

Gateway API

为了克服这个问题，Gateway API 旨在提供一种更灵活、可扩展和强大的方式来管理到您的服务的流量。

Gateway API 距离 GA（正式发布）版本只有几周时间了。它为入口流量控制提供了一个标准的 Kubernetes API。它提供了扩展的功能、改进的自定义和更大的灵活性。通过专注于模块化和富有表现力的 API 资源，Gateway API 可以描述更广泛的路由配置和模型。

Kubernetes 中从 Ingress API 到 Gateway API 的过渡是由 Gateway API 提供的优势和高级功能驱动的，其基础建立在四个核心原则之上：面向角色的方法、可移植性、表达性和可扩展性。

面向角色的方法

Gateway API 采用面向角色的方法，该方法与组织内参与配置 Kubernetes 服务网络的传统角色保持一致。这种方法使基础设施工程师、集群操作员和应用程序开发人员能够共同处理 Gateway API 的不同方面。

例如，基础设施工程师在部署 GatewayClass 中发挥着关键作用，GatewayClass 是集群范围的资源，充当模板，明确定义从中派生的网关的行为，为强大的服务网络奠定基础。

随后，集群操作员使用这些 GatewayClass 来部署网关。Kubernetes Gateway API 中的网关定义了如何将外部流量定向到集群内的服务，本质上是将非 Kubernetes 源连接到 Kubernetes 感知的目标。它表示请求与 GatewayClass 规范对齐的负载均衡器配置。网关规范可能不详尽，因为某些详细信息可以由 GatewayClass 控制器提供，从而确保可移植性。此外，网关可以链接到多个路由引用，以将特定的流量子集引导到指定的服务。

最后，应用程序开发人员配置路由资源（例如 HTTPRoutes），以管理配置（例如超时、请求匹配/过滤器）和服务组合（例如到后端的路径路由）。路由资源定义了将来自网关的请求映射到 Kubernetes 服务的协议特定规则。HTTPRoute 用于多路复用 HTTP 或终止的 HTTPS 连接。它适用于您想要检查 HTTP 流并使用 HTTP 请求数据进行路由或修改的情况，例如使用 HTTP 标头进行路由，或在飞行中修改它们。

Diagram showing the key resources that make up Gateway API and how they relate to each other. The resources shown are GatewayClass, Gateway, and HTTPRoute; the Service API is also shown

可移植性

Gateway API 具有超过 20 个 API 实现，旨在在不同的实现、集群和环境中更具可移植性。它有助于减少 Ingress 对不可移植的、特定于提供商的注释的依赖，使您的配置在多个集群中更加一致且易于管理。

Gateway API 承诺支持最新的 5 个 Kubernetes 小版本。这意味着 Gateway API 目前支持 Kubernetes 1.24+。

表达性

Gateway API 为各种功能提供了标准的 Kubernetes 支持，例如基于标头的匹配、流量拆分、基于权重的路由、请求镜像等。使用 Ingress，这些功能需要自定义的特定于提供商的注释。

可扩展性

Gateway API 的核心功能是可扩展性。它没有强制执行一刀切的模型，而是提供了在 API 框架内的多个层链接自定义资源的灵活性。这种分层定制方法确保用户可以根据自己的特定需求定制配置，而不会使主结构不堪重负。通过这样做，Gateway API 可以进行更精细和上下文相关的调整，从而在标准化和适应性之间实现微调平衡。这在复杂的云原生环境中尤其有价值，在这些环境中，特定的用例需要细致的配置。一个关键的区别是，Gateway API 具有更广泛的功能基础和用于扩展的标准模式，这些模式比 Ingress 上的注释更具表现力。

升级到网关

从 Ingress 迁移到 Gateway API 可能看起来令人生畏，但幸运的是，Kubernetes 刚刚发布了一个工具来简化该过程。ingress2gateway 通过将您现有的 Ingress 资源转换为 Gateway API 资源来协助迁移。以下是如何开始使用 Gateway API 和 ingress2gateway 的方法

  1. 安装网关控制器 或 手动安装 Gateway API CRD。

  2. 安装 ingress2gateway。

    如果您在本地有 Go 开发环境，可以使用以下命令安装 ingress2gateway

    go install github.com/kubernetes-sigs/[email protected]

    这将把 ingress2gateway 安装到 $(go env GOPATH)/bin/ingress2gateway。

    或者，请按照 此处 的安装指南进行操作。

  3. 安装该工具后，您可以使用它将集群中的入口资源转换为 Gateway API 资源。

    ingress2gateway print

    上面的命令将

    1. 加载您当前的 Kubernetes 客户端配置，包括活动上下文、命名空间和身份验证详细信息。
    2. 在该命名空间中搜索入口和特定于提供商的资源。
    3. 将它们转换为 Gateway API 资源（目前仅支持网关和 HTTPRoute）。对于其他选项，您可以运行带有 -h 的工具，或者参考 https://github.com/kubernetes-sigs/ingress2gateway#options。

  4. 查看转换后的 Gateway API 资源，验证它们，然后将它们应用于您的集群。

  5. 向您的网关发送测试请求以检查它是否正在工作。您可以使用 kubectl get gateway <gateway-name> -n <namespace> -o jsonpath='{.status.addresses}{"\n"}' 获取您的网关地址。

  6. 更新您的 DNS 以指向新的网关。

  7. 一旦您确认没有更多流量通过您的 Ingress 配置，您可以安全地将其删除。

总结

实现可靠、可扩展和可扩展的网络一直是一项具有挑战性的目标。Gateway API 旨在改进当前的 Kubernetes 网络标准（如入口），并减少对特定于实现的注释和 CRD 的需求。

它是跨不同平台和实现一致的 Kubernetes 标准 API，最重要的是它具有面向未来的特性。Gateway API 是下一代 Ingress API，但其范围比这更大，扩展到处理网格和第 4 层路由。Gateway API 和 ingress2gateway 由 SIG Network 下的专门团队支持，该团队积极致力于此并管理生态系统。它也可能会收到更多更新和社区支持。

未来的道路

ingress2gateway 才刚刚起步。我们计划加入更多提供商，引入对更多类型的 Gateway API 路由的支持，并确保一切与 Gateway API 的持续开发顺利同步。

令人兴奋的是，Gateway API 也取得了显著进展。虽然 v1.0 即将发布，但仍有大量工作要做。此版本包含许多新的实验性功能，并且还有其他功能目前处于早期规划和开发阶段。

如果您有兴趣参与贡献，我们非常欢迎您！请查看社区页面，其中包含 Slack 频道和社区会议的链接。我们期待您的加入！