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 Hash（OSS & 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 推理工作负载仍然是挑战，因此保护、管理和高效路由推理流量的能力已经成为必需能力。
