F5 NGINX Gateway Fabric 2.4.0 新功能发布

原文作者Sean Moloney - F5 Product Manager原文链接 F5 NGINX Gateway Fabric 2.4.0 新功能发布转载来源NGINX 中文社区NGINX 唯一中文官方社区 尽在nginx.org.cn我们很高兴地宣布 F5 NGINX Gateway Fabric 2.4.0 已经发布。此次发布标志着 Gateway API 发展历程中的一个重要里程碑新增了关键的生产级特性如 TCP/UDP 路由支持、限流、会话保持等功能。这些新功能将帮助运维人员更高效、安全地交付 AI 和现代应用。本次发布的变更摘要2.4.0 版本包含许多新功能和改进概括来说包括•支持限流•支持 NGINX OSS 和 NGINX Plus 的会话保持Sticky Cookie包括更改负载均衡方法的能力•通过新的 ProxySettingsPolicy 支持代理缓冲未来将增加更多 NGINX 指令•TCP 路由和 UDP 路由•强化的 TLS Listener配置密码套件•支持 Multiple Inference Pool backends作为 Gateway API Inference Extension 的一部分附加功能•命名空间过滤只监视特定命名空间而不是整个集群减少大型集群中的资源消耗•自定义日志转义格式在自定义数据平面访问日志时指定转义格式•上游 Keep-Alive 默认启用配置为 16 个连接以减少连接开销可通过 UpstreamSettingsPolicy CRD 进行配置•CRD 发现改善了与运行较旧 Gateway API 版本的集群的兼容性Bug修复•数据平面稳定性修复了当控制平面重启时导致数据平面不必要重启的问题•内存优化代理收集器日志现在写入 stdout 而不是磁盘从而解决了内存消耗问题接下来将深入探讨这些重要功能并解释它们为何对我们的用户至关重要。限流限流对于 API 网关场景至关重要通常是开发者在构建和部署 API 时实施的首个保护措施。通过新的 RateLimitPolicy API您可以将限流以 Kubernetes 策略的形式声明并直接应用到您的路由上。这将 NGINX 强大的限流能力引入 Gateway API 工作流中避免了手动配置 NGINX 或使用自定义 annotation 的麻烦。通过简单的版本控制策略保护您的服务免受流量激增的影响防止滥用并确保资源的公平分配。为什么重要限流对于部署 API 网关的团队至关重要。它确保了在流量激增时服务的稳定性有助于缓解 DDoS 攻击并保护后端系统免于过载。通过控制请求量组织能够保持可预测的性能并为用户提供可靠的体验。此外GPU 配额昂贵且常常稀缺。与可以弹性扩展的 CPU 工作负载不同推理能力受限于硬件的可用性和成本。限流通过防止任何单个客户端独占高性能计算资源并确保最重要的工作负载获得足够的 GPU算力从而保护该投资。适用对象· 需要强制执行使用配额的多租户环境管理的平台团队· 保护服务免受恶意或异常客户端访问的 API 开发人员· 为体量攻击添加防御的安全工程师· 设计需要保证资源交付的高性能推理应用的 MLOps/AI 工程师· 管理 GPU 成本的基础设施团队需要防止来自单个客户端或服务的无限制消耗会话保持 — 通过 UpstreamSettingsPolicy CRD 支持 OSS 与 Plus尽管 NGINX Gateway Fabric 已经支持基本的会话保持功能但您现在可以配置更精细的基于 Cookie 的会话保持。这是此次发布中新增的另一个重要功能。我们再次利用 NGINX 在 Kubernetes 部署中的强大功能以确保不会出现会话丢失问题。此次发布为 NGINX OSS 和 NGINX Plus 用户引入了灵活的会话保持选项•IP HashOSS Plus通过 UpstreamSettingsPolicy 配置 ip_hash将客户端根据其 IP 地址被路由到相同的后端•基于 Cookie 的会话保持仅限 Plus在 HTTPRoute 和 GRPCRoute 规则中启用 sessionPersistence以获得更精确的基于 Cookie 的会话亲和性实验性功能为什么重要会话保持通常称为“粘性会话”确保来自同一客户端的请求始终被路由到相同的后端服务器。这对于那些将会话状态存储在本地的应用程序至关重要例如购物车、身份验证流程或多步骤表单。如果没有会话保持当请求落在不同后端时用户可能会遇到数据丢失或工作流中断。对于 AI 工作负载会话亲和性还可以减少浪费的 GPU 计算周期。当请求分散到不同的后端时每个实例可能需要重建上下文或重新加载模型状态。保持会话的粘性可以避免这种冗余计算更有效地利用昂贵的 GPU 时间。这对于减少“上下文膨胀”或因频繁重新加载工具描述或其他元数据而导致的令牌过度消耗也起着至关重要的作用这些操作通常在新会话开始时发生。适用对象· 确保购物车内容在用户会话期间保持不变的电商团队· 构建依赖本地会话存储的有状态服务的应用开发人员· 将传统有状态应用迁移到 Kubernetes 的平台工程师· 运行对话式 AI 或其他需要在多轮交互中维持上下文的长上下文窗口应用的团队身份验证过滤器Basic Auth版本 2.4.0 标志着 NGINX Gateway Fabric 身份验证功能的开始。新的 AuthenticationFilter 引入了对 HTTP Basic Auth 的支持使您能够使用用户名和密码凭证保护路由无需外部身份提供者。尽管 Basic Auth 是最简单的身份验证方法之一但它在内部工具、开发环境以及需要轻量级保护的场景中仍然具有价值。这仅仅是一个开始未来的版本将扩展 AuthenticationFilter加入 NGINX 提供的其他身份验证方法。为什么重要Basic Auth 提供了一种快速、低摩擦的方式来保护路由当简洁性比高级安全功能更重要时尤其有用。将此功能内置于 Gateway API 意味着少了一个需要部署和管理的工具。适用对象· 保护内部仪表盘和管理端点的 DevOps 团队· 在不使用复杂身份验证设置的情况下保护预发布环境和测试环境的开发人员· 在实施企业单点登录之前需要轻量级方案的平台工程师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 工作流中从而简化运维并减少基础设施分散。适用对象· 通过网关暴露 PostgreSQL、MySQL 或 Redis 的团队· 路由流量到 IoT 设备的平台团队· 路由流量到向量数据库、模型注册表或自定义推理协议的团队Gateway API Inference Extension本次发布新增对多个 Inference Pool 后端的支持作为 Gateway API Inference Extension 的一部分。借助此功能单个 HTTPRoute 现在可以在其 backendRefs 中引用多个 InferencePool从而实现模型变体的流量拆分、新模型版本的分阶段发布以及跨 Pool 的路由以进行容量管理。为什么重要实际推理部署很少只涉及单一同质化 Pool。团队通常需要在不同模型版本之间路由、在微调的 LoRA adapter 之间拆分流量或在不同容量等级之间分配负载。在单条路由支持多个 Pool 不仅消除了繁琐的变通做法也使 NGF 更贴合生产环境的推理模式。由于 GPU 成本在 AI 基础设施预算中占比极高跨推理池的智能路由对于提升利用率和控制开销变得至关重要。适用对象· 在生产环境中管理多个模型版本或 LoRA adapter 的 ML 团队· 为推理服务实施金丝雀或蓝绿发布的平台工程师· 在不同容量等级间优化 GPU 利用率的基础设施团队总结与展望本次发布增强了 F5 NGINX Gateway Fabric 作为生产级 Gateway API 实现的能力增加了对关键用例的支持包括限流、会话保持、代理缓冲器配置、TCP/UDP 路由和 TLS Listener 配置。这些增强功能使运行高吞吐量的生产级应用更加容易同时在负载下保持可靠性。展望下一次发布我们将继续扩展身份验证功能包括额外的安全特性同时保持与 Kubernetes Gateway API 的规范一致。由于 GPU 分配价格昂贵且供应有限而 GPU 分配对突发且可能需要更长上下文能力的 AI 推理工作负载仍然是挑战因此保护、管理和高效路由推理流量的能力已经成为必需能力。我们要对以下贡献表示衷心感谢•通过 SnippetsPolicy 在网关级别支持 Snippets#4461。感谢 fabian4 的实现。•支持 TCPRoute 和 UDPRoute#4518。感谢 Skcey 推动此能力使 NGINX Gateway Fabric 在第 4 层用例上更适合企业级使用。•数据平面访问日志可配置的转义格式#4530。感谢 michasHL 的增强贡献。