本文已发布一年多。较早的文章可能包含过时的内容。请检查页面信息自发布以来是否已过时或不正确。
介绍 ingress2gateway:简化到 Gateway API 的升级
今天我们发布了 ingress2gateway,这是一个可以帮助您从 Ingress 迁移到 Gateway API 的工具。Gateway API 距离晋升到 GA 状态仅有数周时间,如果您还没有升级,现在是时候考虑一下了!
背景
在不断发展的 Kubernetes 世界中,网络扮演着关键角色。随着越来越多的应用部署到 Kubernetes 集群中,如何有效地将这些服务暴露给客户端成为一个关键问题。如果您一直在使用 Kubernetes,您可能已经熟悉 Ingress API,它一直是管理外部访问服务的首选解决方案。
The Ingress API 提供了一种将外部流量路由到集群内部应用的方式,使其成为许多 Kubernetes 用户不可或缺的工具。然而,Ingress 也有其局限性,随着应用变得更加复杂以及对 Kubernetes 集群的需求增加,这些局限性可能会成为瓶颈。
一些局限性包括
- 共同点不足 - Ingress 试图为各种 HTTP 代理建立共同点,因此只能支持基本的 HTTP 路由,这将当代代理更多特性(如流量拆分和请求头匹配)强行塞入特定提供商的、不可迁移的 Annotation 中。
- 权限模型不完善 - Ingress Spec 将基础设施和应用配置合并在一个对象中。使用 Ingress 时,集群 Operator 和应用开发者操作同一个 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 服务网络的传统角色相一致。这种方法使得基础设施工程师、集群 Operator 和应用开发者能够共同处理 Gateway API 的不同方面。
例如,基础设施工程师在部署 GatewayClasses 中扮演着关键角色。GatewayClasses 是集群范围的资源,它们充当模板,明确定义从其派生的 Gateway 的行为,为健壮的服务网络奠定了基础。
随后,集群 Operator 利用这些 GatewayClasses 部署 Gateway。Kubernetes Gateway API 中的 Gateway 定义了如何将外部流量导向集群内部的服务,本质上是将非 Kubernetes 源连接到 Kubernetes 可感知的目的地。它表示根据 GatewayClass 规范请求负载均衡器配置。Gateway Spec 可能不包含所有细节,因为某些细节可以由 GatewayClass Controller 提供,从而确保可移植性。此外,一个 Gateway 可以关联到多个 Route 引用,以将特定流量子集引导到指定的服务。
最后,应用开发者配置 Route 资源(例如 HTTPRoutes),以管理配置(例如超时、请求匹配/过滤)和服务组合(例如,路径路由到后端)。Route 资源定义了协议特定的规则,用于将来自 Gateway 的请求映射到 Kubernetes 服务。HTTPRoute 用于多路复用 HTTP 或终止的 HTTPS 连接。它适用于需要检查 HTTP 流并使用 HTTP 请求数据进行路由或修改的场景,例如使用 HTTP Headers 进行路由或在传输中修改它们。
可移植性
凭借超过 20 种 API 实现,Gateway API 被设计得在不同实现、集群和环境之间更具可移植性。它有助于减少 Ingress 对不可移植的、特定提供商的 Annotation 的依赖,使您的配置在多个集群中更加一致且易于管理。
Gateway API 承诺支持最新的 5 个 Kubernetes 小版本。这意味着 Gateway API 目前支持 Kubernetes 1.24+。
表达性
Gateway API 为广泛的功能提供了标准的、由 Kubernetes 支持的能力,例如基于请求头的匹配、流量拆分、基于权重的路由、请求镜像等。使用 Ingress 时,这些功能需要自定义的特定提供商的 Annotation。
可扩展性
Gateway API 的核心特性是可扩展性。它没有强制采用一刀切的模型,而是在 API 框架内的多个层提供链接自定义资源的灵活性。这种分层的定制方法确保用户可以根据特定需求调整配置,而不会影响主体结构。通过这样做,Gateway API 促进了更精细化和上下文相关的调整,在标准化和适应性之间实现了精妙的平衡。这在需要细致配置的复杂云原生环境中尤为宝贵。一个关键的区别在于,Gateway API 具有更广泛的基础功能集和标准的扩展模式,这比 Ingress 的 Annotation 更具表达性。
升级到 Gateway
从 Ingress 迁移到 Gateway API 可能看起来令人畏惧,但幸运的是 Kubernetes 刚刚发布了一个工具来简化这个过程。ingress2gateway 通过将您现有的 Ingress 资源转换为 Gateway API 资源来协助迁移。以下是开始使用 Gateway API 和 ingress2gateway 的方法:
安装 ingress2gateway。
如果您在本地拥有 Go 开发环境,可以使用以下命令安装
ingress2gateway
:go install github.com/kubernetes-sigs/ingress2gateway@v0.1.0
这会将
ingress2gateway
安装到$(go env GOPATH)/bin/ingress2gateway
。或者,请遵循此处的安装指南。
工具安装完成后,您可以使用它将集群中的 Ingress 资源转换为 Gateway API 资源。
ingress2gateway print
上述命令将执行以下操作:
- 加载您当前的 Kubernetes 客户端配置,包括活动的上下文、命名空间和认证详情。
- 在该命名空间中搜索 ingress 和特定于提供商的资源。
- 将它们转换为 Gateway API 资源(目前仅支持 Gateway 和 HTTPRoute)。有关其他选项,你可以运行带
-h
参数的工具,或参考 https://github.com/kubernetes-sigs/ingress2gateway#options。
审查转换后的 Gateway API 资源,对其进行验证,然后将它们应用到你的集群。
向你的 Gateway 发送测试请求以检查其是否正常工作。你可以使用
kubectl get gateway <gateway-name> -n <namespace> -o jsonpath='{.status.addresses}{"\n"}'
获取 Gateway 地址。更新你的 DNS,使其指向新的 Gateway。
一旦你确认不再有流量通过你的 Ingress 配置,你就可以安全地删除它。
总结
实现可靠、可扩展的网络始终是一个富有挑战性的目标。Gateway API 旨在改进当前的 Kubernetes 网络标准,例如 Ingress,并减少对实现特定注解和 CRD 的需求。
它是一个 Kubernetes 标准 API,在不同的平台和实现中保持一致,最重要的是它面向未来。Gateway API 是 Ingress API 的下一代,但其范围比 Ingress 更广,还扩展到处理服务网格和四层路由。Gateway API 和 ingress2gateway 由 SIG Network 下的一个专门团队支持,他们积极投入工作并管理着生态系统。它也很可能收到更多更新和社区支持。
前景展望
ingress2gateway 刚刚起步。我们计划支持更多提供商,引入对更多类型 Gateway API 路由的支持,并确保一切与 Gateway API 的持续开发顺利同步。
令人兴奋的是,Gateway API 也在取得重大进展。虽然 v1.0 即将发布,但前方仍有大量工作要做。此版本包含许多新的实验性功能,其他功能目前处于规划和开发的早期阶段。
如果你有兴趣贡献,我们非常欢迎你的加入!请查看 社区页面,其中包含 Slack 频道和社区会议的链接。我们期待与你相见!!
有用链接
- 参与 Ingress2Gateway 项目,请访问 GitHub
- 开启一个新 Issue - ingress2gateway, Gateway API。
- 加入我们的 讨论。
- Gateway API 入门
- Gateway API 实现