本文介绍: 与 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 API 出了什么问题?
明显的好处
官方扩展
它会扩散吗?
迁移指南
可行的替代方案
声明:本站所有文章,如无特殊说明或标注,均为本站原创发布。任何个人或组织,在未征得本站同意时,禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益,可联系我们进行处理。