Ingress-NGINX 用户欢迎指南

原文：https://gateway-api.sigs.k8s.io/guides/getting-started/migrating-from-ingress-nginx/

欢迎！如果你正在使用 Ingress-NGINX，那么你来对地方了。本页面是那些正在考虑或正在进行 Gateway API 迁移工作的用户的资源中枢。我们会持续把本页面建设得更加完善。如果你想要的是从 Ingress 迁移到 Gateway API 的一份总览，请参考我们的 从 Ingress 迁移指南。

我们知道迁移可能相当复杂，我们的目标就是为你提供顺利完成过渡所需要的信息与工具。

常见问题

Gateway API 与 Ingress 相比如何？

Gateway API 提供的是一种面向角色（role-oriented）、更具表达力的 API，相较于 Ingress 更胜一筹。Ingress 把"负载均衡器"和"路由规则"两个概念塞进了同一个资源，而 Gateway API 把它们拆开了：

• Gateway：定义流量如何进入集群，集群运维人员关注的事情。
• HTTPRoute：定义流量如何被路由到服务，应用开发者关注的事情。

这种拆分让多租户基础设施变得更安全。想深入了解，请阅读 Ingress 迁移指南。

我怎么把 Ingress-NGINX 的特性映射到 Gateway API？

Ingress-NGINX 中许多以注解（annotation）形式提供的特性，在 Gateway API 中都有对应的字段。举例来说：流量切分、请求头改写、TLS 配置等都是 Gateway API 中原生支持的特性。如需详细的映射关系，推荐阅读 Gateway API HTTPRoute 文档 以及你所选用的控制器实现 的文档。

能不能在保留 Ingress-NGINX 的同时先试试 Gateway API？

可以，而且强烈推荐这种做法。你可以在保留现有 Ingress-NGINX 控制器的同时，再部署一个 Gateway API 控制器。它们各自会拿到不同的外部 IP，便于你隔离地测试和验证新配置，而不会影响生产流量。

迁移资源

一次成功的迁移离不开周密的规划。以下资源能帮到你。

ingress2gateway

手工翻译复杂的 Ingress 规则和注解非常容易出错。ingress2gateway 这个工具正是为自动化这个过程而设计的。它会读取你现有的 Ingress 资源，并把它们转换成对应的 Gateway 与 HTTPRoute 资源。

该工具仍在积极开发中，目前正在持续增加对那些最常用的 Ingress-NGINX 注解的支持。强烈建议你以它作为迁移的起点。

选用哪种实现（Implementation）

第一步是先挑选一个满足你需求的 Gateway API 实现。需要考虑的关键因素包括：

• 一致性（Conformance）：阅读一致性报告，确认该实现支持你所需要的 Gateway API 特性。
• 底层技术：你的团队是否熟悉 Envoy、NGINX 等代理，会影响最终选型。
• 集成性：你的云服务商或 CNI 也许已经自带一个集成好的 Gateway API 实现。

还有大量工作在推进中

我们有许多正在进行中的工作，希望能帮助你将来更顺畅地迁移到 Gateway API。除了持续完善 ingress2gateway、并推进 v1.0 发布之外，我们也在规划下一版 Gateway API（目标发布月份是 2 月）。在该版本中，我们希望把以下特性晋升为 GA：

• TLSRoute
• ListenerSet
• HTTPRoute 的 CORS 过滤器

如果你认为还有别的特性值得我们投入精力，欢迎告诉我们。

我们随时愿意帮忙

Gateway API 社区致力于让迁移体验尽可能顺畅。ingress2gateway 工具是这件事的关键一环，我们也在持续提升它的注解覆盖率。

如果你有任何问题、遇到了 bug、或发现功能缺失，欢迎联系我们：

• 在 Gateway API 代码仓库里 提交 issue。
• 加入一次社区会议来讨论你的使用场景。
• 在 ingress2gateway 仓库 里通过 issue 给出反馈。

你的反馈对改进 API 与迁移工具至关重要。