使用F5 NGINX Gateway Fabric实现AI交付标准化

Karthik Krishnaswamy产品营销总监 | F5

企业正迅速从AI实验转向AI运营。这一转变使组织对应用交付基础设施有了新的需求。

多年来，Kubernetes流量管理通常被视为技术实施细节。平台团队选择入口控制器，应用团队配置路由，安全团队则尽可能添加控制措施。当主要挑战是为Web应用和API提供服务时，这种模式行之有效。但如今，同一平台还必须支持现代应用、分布式API、安全策略，以及消耗稀缺且昂贵计算资源的AI推理工作负载，这种模式已难以满足需求。

《2026 年 F5 应用策略现状报告》说明了这一点为何在当下至关重要：78%的组织正在自行运行AI推理，52%的组织正在使用多模型编排来调整和扩展其AI模型。具体而言，企业不再只是通过单一服务调用单一模型，而是跨环境运行推理、协调多个模型，并将AI纳入生产应用架构。

AI让一项长期存在的企业挑战变得更加紧迫：如何在保持治理、安全性和运营一致性的同时，为团队提供所需的速度。

F5 NGINX Gateway Fabric汇集了三项重要功能，有助于解决这一问题：符合Gateway API 1.5规范、集成F5 WAF for NGINX，并支持Gateway API Inference Extension。这些功能共同推动Kubernetes流量管理采用更加标准化、安全且为AI做好准备的方法。

标准为何重要

Gateway API正逐渐成为Kubernetes流量管理领域的一项重要标准，因为它解决了企业常见的一项挑战：过多团队以不同方式解决同一问题。

传统的入口流量管理方法通常高度依赖特定于实现的注解和自定义配置。这种方式可能适用于单个团队，但在企业规模下会更难治理。策略难以审计，迁移路径也会变得更加复杂。平台团队可能难以在不放弃控制权的情况下提供自助服务。应用团队或许能快速推进工作，但运营模式会变得碎片化。

Gateway API引入了一种更注重角色分工的Kubernetes原生模型。平台团队可以管理共享网关基础设施，应用团队可以为自己的服务定义路由，安全和运维团队则可以通过更清晰的结构应用策略。其价值不仅在于技术设计更加精巧，更在于打造更清晰的运营模式。

在此背景下，NGINX Gateway Fabric 对 Gateway API 1.5 的符合性十分重要。符合性并不意味着所有实现都完全相同，也不意味着无需做出架构决策。但它确实能让企业更有信心，相信其构建所依据的标准正日趋成熟，并在整个 Kubernetes 生态系统中接受测试。

其意义显而易见。标准可以减少本可避免的复杂性，使平台决策更易于跨团队和集群扩展，并降低每个工作流都受制于专有模式的风险。标准还为长期现代化奠定基础，使团队能够采用更新的流量管理模式，而无需强制所有应用同时迁移。

这一点很重要，因为在大型企业中，Kubernetes很少只涉及单个集群。组织通常会跨业务部门、地区、开发阶段和云环境运行多个集群。如果缺乏统一的方法，每个集群都可能成为特例。通过NGINX Gateway Fabric实现的Gateway API，为平台团队提供了一条既能保持一致性，又不会减缓应用交付的路径。

在应用运行位置保障安全

将安全能力嵌入平台，而不是在部署后再附加，通常能提供更强的安全保障。这一点在Kubernetes中尤为明显，因为应用团队期望实现自助服务和快速发布周期。

NGINX Gateway Fabric与F5 WAF for NGINX的集成让企业应用安全更贴近Kubernetes网关层。借助此集成，安全团队可以定义和管理应用保护策略，平台团队则可通过Kubernetes原生工作流提供这些保护。

其业务价值并不在于要求每位IT负责人都了解策略关联方式的技术机制，而在于安全团队可以继续掌控防护策略，同时平台和应用团队仍能快速推进工作。

这种职责分离至关重要。如果安全防护依赖每个应用团队正确实施控制措施，企业的防护就会不一致。如果安全流程拖慢每次发布，团队就会寻求变通方法。更好的模式是共同治理：安全团队定义和管理策略，平台团队提供策略执行点，应用团队则持续交付软件。

随着越来越多面向客户的应用、API和AI赋能服务迁移到Kubernetes，这一点尤为重要。随着该平台的战略地位日益提升，风险范围也随之扩大。Web应用攻击、配置错误、未受管理的路由以及不一致的安全态势不仅是技术问题，还会影响业务连续性、合规性和声誉。

网关级WAF模式无法取代安全开发实践或更广泛的应用安全计划，但可以在靠近应用交付的位置为组织提供实用的策略执行层。这意味着，安全可以融入平台架构，而不再作为一个独立流程，需要逐一跟进每次部署。

为AI推理做好准备

AI推理改变了流量管理方式，因为AI工作负载的行为不同于传统Web请求。

传统Web请求通常持续时间较短，也相对可预测。推理请求在持续时间、有效负载大小、成本和资源影响方面可能存在显著差异。单个请求就可能长时间占用成本高昂的GPU容量。不同任务可能会使用多个模型。有些模型可能针对成本进行优化，有些针对性能，还有些针对准确性。路由决策可能会影响用户体验、基础设施利用率和运营成本。

这正是Gateway API Inference Extension的重要意义所在。它支持模型感知路由，可根据模型版本、模型类型和成本性能特征来转发请求。借助NGINX Gateway Fabric支持，组织可以改善用户体验和基础设施利用率，同时将价值较低或可容忍延迟的请求路由到更具成本效益的模型。

关键不在于底层调度机制，而在于AI交付需要具备成熟的运营能力。当78%的组织自行运行AI推理时，推理就不再只是数据科学领域需要关注的问题，而是企业应用交付技术栈的一部分。当52%的组织采用多模型编排时，流量管理还必须适应更加动态的AI环境。

NGINX Gateway Fabric对Inference Extension的支持，有助于平台和机器学习团队将AI工作负载纳入熟悉的Kubernetes运维模式。组织无需为AI创建单独的交付架构，而是可以采用符合标准的网关方法，开始统一管理AI服务、应用和API。

这并不意味着所有企业AI挑战都能在网关层面得到解决。模型治理、数据治理、安全测试、成本管理和合规仍需要更广泛的管控。但路由是AI生产环境的基础组成部分。如果请求无法得到高效转发、基础设施信号被忽略，或者每个团队都自行构建推理访问路径，复杂性就会迅速增加。

最重要的转变在于架构：AI成为另一类生产工作负载，需要以安全、可观测且由策略驱动的方式交付。

面向AI时代的现代应用交付

不应仅将NGINX Gateway Fabric作为Kubernetes网络组件进行评估，而应将其视为现代应用交付整体平台战略的一部分。

Gateway API 1.5一致性、F5 WAF for NGINX集成和Inference Extension支持相结合至关重要，因为这将三项优先事项联系起来：

• 标准化：通过使Kubernetes流量管理与日趋成熟的社区标准保持一致，减少碎片化。
• 安全性：在更靠近Kubernetes应用暴露位置的地方实施企业级应用保护。
• AI就绪能力：为交付层做好准备，以支持比传统服务更具动态性、更耗费资源且对业务更为关键的推理工作负载。

实际优势在于能够采用更一致的运营模式。平台工程团队可以提供共享基础设施和自助服务模式。应用团队无需自行设计流量模型，便可加快推进速度。安全团队可以通过既有控制措施应用策略。机器学习团队可以将推理工作负载引入Kubernetes，而无需将AI交付视为一次性的架构。

这一点至关重要，因为衡量下一阶段AI应用成效的标准，不仅是组织启动了多少试点项目，还包括AI赋能的应用在生产环境中运行的可靠性、安全性和效率。

许多企业已经具备所需的各项要素：Kubernetes平台、应用交付基础设施、安全计划、AI计划，以及分别负责这些领域的团队。挑战在于如何以可扩展的方式整合这些要素。NGINX Gateway Fabric可提供符合标准的网关层，支持传统应用、API、安全策略和新兴的AI推理模式，帮助企业应对这一挑战。

这体现了切实的价值。组织无需推倒重来，也不必从头重建应用交付架构，而是可以逐步改进Kubernetes流量管理，使其更加一致、更加安全，并为AI工作负载做好更充分的准备。这为组织提供了一条演进路径，推动Kubernetes流量管理向更加一致、更加安全且更适合AI工作负载的模式发展。

随着AI进一步融入企业应用，基础设施也必须随之演进。网关的作用不再只是将流量引入集群，而是逐渐成为一个控制点，用于管理现代应用、API和AI服务的大规模交付、保护与运营。

如需了解详情，请访问F5 NGINX Gateway Fabric网页。

此外，欢迎参加F5 AI Summit。这场时长3小时的线上活动将于6月23日（星期二）举行。届时，我们将在“使用F5 NGINX在Kubernetes上交付AI”专题环节中，深入探讨如何在Kubernetes上交付AI工作负载。

关于作者

Karthik Krishnaswamy产品营销总监 | F5

Karthik Krishnaswamy 的更多博客文章