F5 NGINX Gateway Fabric 2.4.0 新功能发布
当前位置:点晴教程→知识管理交流
→『 技术文档交流 』
![]() 我们很高兴地宣布 F5 NGINX Gateway Fabric 2.4.0 已经发布。此次发布标志着 Gateway API 发展历程中的一个重要里程碑,新增了关键的生产级特性,如 TCP/UDP 路由支持、限流、会话保持等功能。这些新功能将帮助运维人员更高效、安全地交付 AI 和现代应用。 本次发布的变更摘要 2.4.0 版本包含许多新功能和改进,概括来说包括:
附加功能
Bug修复
接下来,将深入探讨这些重要功能并解释它们为何对我们的用户至关重要。 限流 限流对于 API 网关场景至关重要,通常是开发者在构建和部署 API 时实施的首个保护措施。通过新的 RateLimitPolicy API,您可以将限流以 Kubernetes 策略的形式声明,并直接应用到您的路由上。这将 NGINX 强大的限流能力引入 Gateway API 工作流中,避免了手动配置 NGINX 或使用自定义 annotation 的麻烦。通过简单的版本控制策略,保护您的服务免受流量激增的影响,防止滥用,并确保资源的公平分配。 为什么重要: 限流对于部署 API 网关的团队至关重要。它确保了在流量激增时服务的稳定性,有助于缓解 DDoS 攻击,并保护后端系统免于过载。通过控制请求量,组织能够保持可预测的性能,并为用户提供可靠的体验。 此外,GPU 配额昂贵且常常稀缺。与可以弹性扩展的 CPU 工作负载不同,推理能力受限于硬件的可用性和成本。限流通过防止任何单个客户端独占高性能计算资源,并确保最重要的工作负载获得足够的 GPU算力,从而保护该投资。 适用对象:
会话保持 — 通过 UpstreamSettingsPolicy CRD 支持 OSS 与 Plus 尽管 NGINX Gateway Fabric 已经支持基本的会话保持功能,但您现在可以配置更精细的基于 Cookie 的会话保持。这是此次发布中新增的另一个重要功能。我们再次利用 NGINX 在 Kubernetes 部署中的强大功能,以确保不会出现会话丢失问题。 此次发布为 NGINX OSS 和 NGINX Plus 用户引入了灵活的会话保持选项:
为什么重要: 会话保持,通常称为“粘性会话”,确保来自同一客户端的请求始终被路由到相同的后端服务器。这对于那些将会话状态存储在本地的应用程序至关重要,例如购物车、身份验证流程或多步骤表单。如果没有会话保持,当请求落在不同后端时,用户可能会遇到数据丢失或工作流中断。 对于 AI 工作负载,会话亲和性还可以减少浪费的 GPU 计算周期。当请求分散到不同的后端时,每个实例可能需要重建上下文或重新加载模型状态。保持会话的粘性可以避免这种冗余计算,更有效地利用昂贵的 GPU 时间。这对于减少“上下文膨胀”或因频繁重新加载工具描述或其他元数据而导致的令牌过度消耗也起着至关重要的作用,这些操作通常在新会话开始时发生。 适用对象:
身份验证过滤器:Basic Auth 版本 2.4.0 标志着 NGINX Gateway Fabric 身份验证功能的开始。新的 AuthenticationFilter 引入了对 HTTP Basic Auth 的支持,使您能够使用用户名和密码凭证保护路由,无需外部身份提供者。 尽管 Basic Auth 是最简单的身份验证方法之一,但它在内部工具、开发环境以及需要轻量级保护的场景中仍然具有价值。这仅仅是一个开始,未来的版本将扩展 AuthenticationFilter,加入 NGINX 提供的其他身份验证方法。 为什么重要: Basic Auth 提供了一种快速、低摩擦的方式来保护路由,当简洁性比高级安全功能更重要时尤其有用。将此功能内置于 Gateway API 意味着少了一个需要部署和管理的工具。 适用对象:
TCP 路由和 UDP 路由 NGINX Gateway Fabric 现在支持 TCPRoute 和 UDPRoute resource,将 Gateway API 的能力从 HTTP/HTTPS 扩展到第 4 层流量。这使您可以通过同一个网关代理非 HTTP 工作负载,例如数据库(PostgreSQL、MySQL、Redis)、DNS 服务器、消息队列以及 IoT 协议。 为什么重要: 现代平台通常同时运行 HTTP API 和非 HTTP 服务。如果没有第 4 层支持,团队就必须为 TCP/UDP 工作负载部署独立的负载均衡器或 Ingress 解决方案。有了 TCPRoute 和 UDPRoute,您可以将流量管理整合到统一的 Gateway API 工作流中,从而简化运维并减少基础设施分散。 适用对象:
Gateway API Inference Extension 本次发布新增对多个 Inference Pool 后端的支持,作为 Gateway API Inference Extension 的一部分。借助此功能,单个 HTTPRoute 现在可以在其 backendRefs 中引用多个 InferencePool,从而实现模型变体的流量拆分、新模型版本的分阶段发布,以及跨 Pool 的路由以进行容量管理。 为什么重要: 实际推理部署很少只涉及单一同质化 Pool。团队通常需要在不同模型版本之间路由、在微调的 LoRA adapter 之间拆分流量,或在不同容量等级之间分配负载。在单条路由支持多个 Pool 不仅消除了繁琐的变通做法,也使 NGF 更贴合生产环境的推理模式。由于 GPU 成本在 AI 基础设施预算中占比极高,跨推理池的智能路由对于提升利用率和控制开销变得至关重要。 适用对象:
总结与展望 本次发布增强了 F5 NGINX Gateway Fabric 作为生产级 Gateway API 实现的能力,增加了对关键用例的支持,包括限流、会话保持、代理缓冲器配置、TCP/UDP 路由和 TLS Listener 配置。这些增强功能使运行高吞吐量的生产级应用更加容易,同时在负载下保持可靠性。展望下一次发布,我们将继续扩展身份验证功能,包括额外的安全特性,同时保持与 Kubernetes Gateway API 的规范一致。由于 GPU 分配价格昂贵且供应有限,而 GPU 分配对突发且可能需要更长上下文能力的 AI 推理工作负载仍然是挑战,因此保护、管理和高效路由推理流量的能力已经成为必需能力。 我们要对以下贡献表示衷心感谢:
阅读原文:原文链接 该文章在 2026/3/25 9:31:02 编辑过 |
关键字查询
相关文章
正在查询... |