Gateway API 与 Ingress：Kubernetes 网络的未来

欢迎联系我们的中国合作伙伴咨询详情 consultant@gingxing.com。

随着 Kubernetes 成为部署云原生应用程序的实际编排平台，网络和流量管理在管理对服务和基础设施的访问方面已成为关键挑战。Kubernetes 的核心 Ingress 资源解决了基本的第 7 层（L7）路由需求，但在灵活性、功能和标准化方面存在局限性。作为 Ingress 的后继者，Gateway API 项目引入了一套新的可移植网络管理资源，这是对传统 Ingress 功能的超越。

本文将解释 Kubernetes Ingress 和新兴的 Gateway API 标准之间的关键差异，包括 Ingress 的局限性以及 Gateway API 如何解决这些问题。对于那些正在使用 Ingress 或寻求更高级的流量管理控制的人来说，了解这些对比以及 Gateway API 背后的动机对于了解 Kubernetes 网络的未来至关重要。

Ingress 在 Kubernetes 中是什么？

Ingress 为在 Kubernetes 集群内部运行的服务提供了集中管理外部访问的方式，通常处理 L7 层的 HTTP/HTTPS 流量。Ingress 不是为每个服务配置单独的负载均衡器，而是提供了一个集中机制来管理所有到后端应用程序的入站请求。

Ingress 资源定义了路由规则，这些规则决定了外部请求如何被导向 Kubernetes 服务。规则可以包括用于映射流量的主机名、路径和 TLS 配置。Ingress 控制器负责最终将 Ingress 资源中描述的路由配置应用于某个数据平面（例如反向代理、负载均衡器等）以处理流量。

许多具备开发传统 L7 代理软件能力的组织会提供他们自己的 Ingress 控制器实现，利用他们的专业知识将 Ingress 资源翻译成针对 Kubernetes 生态系统量身定制的代理服务器配置。

Ingress 抽象了服务网络的关键组件，使 Kubernetes 团队能够简化外部访问管理。在 Ingress 级别指定所需的路由可以使各个服务与外部依赖项解耦。Ingress 集中控制，使服务专注于应用程序交付而不是网络细节。

Ingress 的局限性

尽管 Ingress 控制器解决了 Kubernetes 集群中的重要网络和流量管理需求，但 Ingress 资源本身由于不同控制器实现之间缺乏标准化而存在一些局限性。

Ingress 的主要局限性在于它仅适用于 L7 层，特别是针对 HTTP 和 HTTPS 流量进行优化。其他 L7 协议（如 gRPC）和非 L7 协议（如 TCP 和 UDP）必须使用自定义控制器扩展而不是原生 Ingress 功能来处理。这导致了碎片化，因为启用诸如身份验证、速率限制策略和高级流量管理等功能依赖于供应商或平台特定的自定义注解。例如，NGINX Ingress 控制器与 HAProxy Ingress 实现相比，使用不同的语法和扩展集。

此外，核心的 Ingress 规范缺乏对生产场景中所需许多高级流量管理功能的内置支持。因此，诸如 A/B 测试、金丝雀部署、分布式跟踪等用例的解决方案最终变得与供应商绑定，而不是可移植的。Ingress 资源本身专注于暴露 HTTP 路由，而关键的网络功能则依赖于底层的 Ingress 控制器。这要求单独配置控制器以实现生产级别的功能。

介绍 Kubernetes 中的 Gateway API

为了解决 Kubernetes Ingress 的局限性，创建了 Gateway API 项目，作为一个不断发展的标准，用于统一不同 Ingress 控制器的功能。

Gateway API 定义了一组 Kubernetes 资源对象和使用模式，所有符合标准的网关都必须支持。这引入了可移植性，使用户能够在本地和云之间切换商业或开源实现，并降低迁移成本。

Gateway API 支持 L4 和 L7 协议，包括 TCP、UDP、HTTP、gRPC 等，其范围已扩展到不仅仅是 HTTP 流量。Gateway API 还引入了新的控制器对象，如 GatewayClass 用于定义控制器功能，Gateway 用于实例化具有这些功能的网络网关，以及 HTTPRoute 用于声明 HTTP 路由（Ingress 资源的直接替代品）。未来，将出现更多指定的对象，以覆盖更新的协议。

这些新对象启用了 Ingress 资源无法单独实现的功能。例如，网关路由支持对任意头部和路径进行高级模式匹配和过滤，以精确控制流量，这有助于实现金丝雀部署等用例。网关还为关键功能（如请求镜像、直接响应注入和细粒度流量指标）提供了内置支持。供应商无需再创建自定义扩展和注解来实现这些扩展功能。

总的来说，网关定义了一种全新的方式来声明和管理针对 Kubernetes 服务的流量，避免了团队仅使用 Ingress 资源时所遇到的局限性。Gateway API 创建了一个标准化的模型，可便携地在所有符合标准的网关控制器上启用 L4 支持、高级 HTTP 路由和内置流量管理等功能。这将防止供应商锁定，并为开发人员提供扩展的声明式管理，而无需触及低级别的控制器配置。

截至目前，只有 GatewayClass、Gateway 和 HTTPRoute 是 GA（一般可用性）状态。L4 支持仍被视为 alpha 版本，可能会根据社区需求和项目支持情况升级为 GA 或弃用。

关键差异

Ingress 主要关注 HTTP 流量，而 Gateway API 引入了一个新模型来管理集群内部的所有流量。这两种在 Kubernetes 网络方法之间存在显著差异：

• 协议支持：Ingress 仅适用于 Layer 7 协议，如 HTTP 和 HTTPS。对于非 L7 协议的支持，需要自定义控制器扩展。Gateway API 原生支持 L4 协议（如 TCP 和 UDP）以及 L7 协议（如 HTTP）。

• 流量管理：Ingress 在高级流量管理（如 A/B 测试或请求镜像）方面的内置功能有限，这些功能需要供应商扩展和定制。Gateway API 为流量拆分、镜像、注入和细粒度指标提供了内置支持。

• 可移植性：Ingress 定义依赖于供应商特定的实现，每个实现都有自己的扩展语法和功能。Gateway API 建立了一个通用标准，在所有符合标准的控制器实现中都能一致地工作。

• 资源对象定义：Ingress 规范中没有引入新的资源对象。Gateway API 引入了用于功能定义的 GatewayClass、用于实例化的 Gateway、用于 HTTP 流量规则的 HTTPRoute，以及其他协议的更多对象。

• 路由定制：Ingress 仅支持基于路径或主机的路由规则。Gateway API 允许根据任意头部字段以及路径和主机进行路由定制。

• 扩展功能：向 Ingress 添加身份验证策略或速率限制等功能需要供应商特定的自定义注解和扩展。这些功能作为 Gateway API 整体规范的一部分而内置提供。

值得注意的是，Ingress 现在已经停止开发，所有新功能都将添加到 Gateway API 中。

Gateway API 的未来

Gateway API 规范旨在通过 Kubernetes Ingress 提供的基准流量管理功能进行标准化和扩展。它引入了一套通用的对象和定义，以一致地支持 L4 和 L7 协议、高级流量控制功能、基于头部的扩展规则定制等。这为在不同 Ingress 控制器平台（无论是云环境还是本地环境）上的服务网格等用例提供了更大的可移植性。

Gateway API 将补充现有的 Ingress 控制器，而不是取代它们。传统上实现 Ingress 的 Ingress 控制器现在也可以实现 Gateway API。随着时间的推移，Gateway API 将逐渐取代供应商特定的 Ingress 实现。团队现在可以选择基本的但分散的 Ingress 功能，或者采用 Gateway API 来满足多协议支持、可移植的高级流量管理和跨公共和私有环境的下一代基础设施的生产规模需求。

想看到 Ingress 和 Gateway API 之间的区别吗？欢迎联系我们的中国合作伙伴咨询详情 consultant@gingxing.com。