Kubernetes已不再是早期采用者的实验沙箱，而是现代企业的操作系统。全球有近2,000万名云原生开发者基于Kubernetes进行开发。预计到2027年，全球将有超过90%的组织在生产环境中运行容器化应用。此外，三分之二的生成式AI采用者已经在Kubernetes上运行推理工作负载。容器编排如今已成为关键业务不可或缺的一环。
但有一个不容回避的事实：在生产环境中运行Kubernetes的组织中，只有38%的组织达到了企业级成熟度。这一数据来自《2026年企业Kubernetes战略现状》，该报告基于F5赞助的SlashData研究。约半数（51%）的组织已处于“已建立”阶段，但在治理、可观测性、韧性或软件供应链方面仍存在关键缺口。其余11%的组织仍在推进标准化。
为帮助企业达到所需的企业级Kubernetes成熟度，F5 Application Delivery and Security Platform (ADSP)提供统一架构，消除外部负载均衡器与集群内Ingress之间的运维隔阂，以协调一致的企业级架构取代脆弱的多供应商工具链。
凝聚团队的共同基础
Kubernetes出色地完成了自身职责：调度工作负载、弹性扩缩计算资源、自动修复故障Pod，并对混合云和多云环境中的底层硬件进行抽象。但容器编排只是其中一半，另一半是控制流量并保障流量安全。
Kubernetes的设计初衷并非管控分布式企业环境中的应用和AI流量行为。它不会根据全局网络状况做出实时路由决策，不会在入站和出站路径上一致地执行企业安全策略，也无法保证在大规模环境下实现严格的多租户流量隔离。
更棘手的是，Kubernetes流量和安全并非由单一角色负责。通过GitOps对外提供微服务的平台工程师、管理多集群边界网关协议（BGP）对等互联和DPU卸载的网络架构师，以及防御AI驱动的零日漏洞利用攻击的CISO，各自的运维需求都有根本差异。
强制所有利益相关方使用同一款通用工具往往行不通：它要么对开发者而言过于繁重，要么无法满足企业基础设施团队的深层需求。F5 ADSP采用不同的方法，根据各类角色实际控制流量和保障流量安全的方式，提供专门设计的云原生解决方案。这些解决方案均以共同的基础为支撑，促进团队协作，而无需任何一方妥协。
不同团队，各有侧重的流量与安全优先事项
随着Kubernetes规模扩大，尤其是在组织从无状态Web应用转向有状态、高吞吐量的AI工作负载时，逐渐形成了四类不同的角色，各自面临的痛点也截然不同。
- 平台和DevOps负责人优先考虑速度、自助服务和Kubernetes原生YAML工作流。他们往往从免费的社区控制器入手，例如最近已停止维护的社区项目ingress-nginx，结果却发现自己不得不在数十个生产集群中维护不再受支持的软件，将工程人力耗费在繁琐的日常运维上。
- NetOps和基础设施负责人要求具备高效路由、高容量TLS卸载、严格的多租户隔离以及端到端可见性。流量进入集群后，网络团队往往无法掌握其中的情况，不得不召开长达4小时的应急排障会议，试图查明故障究竟出在网络还是Pod。
- AI基础设施负责人已投入数百万资金建设GPU集群，但这些集群往往未得到充分利用。这并非因为算力不足，而是因为瓶颈在于如何高效输入和输出词元、在不同模型之间智能路由请求，以及隔离多租户GPU流量。
- CISO和SecOps负责人担忧的是临时集群中难以量化的风险暴露、Web应用防火墙（WAF）和API安全策略不一致，以及当今漏洞被利用的速度。
F5为每个团队提供适合其需求的云原生数据平面和控制平面，而不是要求DevOps像NetOps一样思考，或让NetOps管理应用的YAML。
“F5采用不同的方法，根据各类角色实际控制流量和保障流量安全的方式，提供专门打造的云原生解决方案。这些解决方案均以共同基础为支撑，促进团队协作，而无需任何一方妥协。”
面向DevOps和平台团队：轻量级、Kubernetes原生的敏捷性
平台工程师和开发人员需要一种轻量级、可快速交付的解决方案，能够原生运行于Kubernetes中，并无缝集成到CI/CD和GitOps流水线中。这正是F5 Ingress Controller for NGINX和F5 Gateway Fabric for NGINX的作用，两者均为F5 ADSP的组成部分。
凭借在数百万次云原生部署中赢得的信赖，F5 NGINX自然成为集群内应用和API流量管理标准化的理想选择。无论团队使用Kubernetes Ingress资源，还是现代Kubernetes Gateway API标准（包括面向AI工作负载的Gateway API Inference Extension），F5的NGINX解决方案都能以轻量化部署提供高速性能和开发者友好的体验。
在资源效率方面，其他竞争代理在处理长上下文AI提示或流式载荷时，内存占用会大幅增加。相比之下，F5 Gateway Fabric for NGINX的内存占用始终保持稳定、可预测，不受载荷大小影响。
对于正在从已停止维护的社区ingress-nginx项目迁出的组织，F5提供具备企业级支持和SLA保障的迁移路径，并通过自动配置转换，让迁移不必困难重重。
安全也并非事后附加。团队可以将F5 WAF产品、API安全、身份验证（OIDC、JWT）、速率限制以及实时AI提示词与响应护栏直接嵌入Kubernetes清单，以代码交付的速度保护应用和LLM流量。
面向基础设施和AI架构师：多集群隔离与出站流量
轻量级集群内代理非常适合应用团队，但大规模企业环境、电信运营商和AI工厂需要电信级规模、严格的租户隔离和双向流量控制。这正是F5 BIG-IP Next for Kubernetes发挥作用的场景。
BIG-IP Next for Kubernetes基于F5的容器原生Traffic Management Microkernel（TMM）构建，可在标准工作节点上运行，也可卸载到NVIDIA BlueField-3 DPU上运行，将基础设施级的流量控制和安全防护直接引入Kubernetes。
大多数Kubernetes工具仅关注入站流量。BIG-IP Next for Kubernetes既管理入站流量，也管理出站流量，并保护两者的安全。当微服务和AI智能体访问外部API、上游数据库、模型上下文协议（MCP）服务器和跨集群服务时，未受管理的出站流量就成为数据外泄的主要盲点。BIG-IP Next for Kubernetes强制实施确定性出站路由、SNAT、基于命名空间的防火墙防护和零信任微分段。
在多集群和多租户环境中，BIG-IP Next for Kubernetes通过BGP直接与核心网络建立对等连接，并在DPU上加速L4至L7流量管理、mTLS加密运算卸载和前缀感知令牌路由，从而严格隔离租户、释放主机CPU资源，并尽可能提高GPU利用率。
促进NetOps与平台团队协作
那么，当NetOps在网络边界管理F5 BIG-IP，负责硬件级DDoS缓解、全局流量管理和合规工作，而平台团队在集群内部运行F5 Gateway Fabric for NGINX或F5 Ingress Controller for NGINX时，会发生什么？
F5 BIG-IP Container Ingress Services (CIS)自动衔接两个团队的工作流。
BIG-IP CIS作为自动化的Kubernetes原生连接器，监视Kubernetes和OpenShift API，包括Ingress、Gateway API、Routes和F5 IngressLink/GatewayLink资源，并实时动态配置外部BIG-IP系统。
开发人员继续在Kubernetes中工作，使用标准YAML定义集群内的流量路由、TLS和L7策略。NetOps保留边界治理权，CIS自动检测集群变更，并更新外部BIG-IP上的虚拟服务器、池成员和多集群DNS/GTM，无需手动提交工单。两个团队各自负责其管理领域，同时共享从边界VIP到Pod的端到端遥测数据，并可随着需求变化升级到BIG-IP Next for Kubernetes。
面向SecOps和CISO：开源版和企业版的安全加固版本
为每类角色提供合适的流量架构至关重要，但数据平面软件也必须能够应对AI加速演变的威胁环境。
不妨看看这些数字。2018年，从CVE披露到漏洞利用被武器化，防御方平均有771天的应对时间。如今，攻击型AI智能体可以在几分钟内将漏洞转化为攻击手段，而一般企业仍需要数周时间才能部署补丁。在公开的开源代码仓库中，每次安全相关的代码提交实际上都为攻击者提供了路线图；AI工具可以比较代码差异，在下游发行版重新构建软件包的数周前就生成漏洞利用代码。
F5提供经过安全加固的版本，让您能够放心交付，同时保护商业客户和开源社区。F5持续在BIG-IP、BIG_IP Next for Kubernetes和NGINX代码库中运行内部AI安全测试框架，主动发现并修复漏洞。
经过安全加固的保密版本以精准、仅限安全更新的形式提供给NGINX Enterprise、BIG-IP和BIG-IP Next for Kubernetes的商业客户，不涉及任何功能变更或API弃用。约六周后，F5会发布安全通告，同时向NGINX Open Source发布CVE详情和补丁。这段时间让企业能够提前为基础设施安全地部署补丁。
整合各项能力：扩展多租户GPU即服务平台
要了解这些组件如何在实践中协同发挥作用，可以看看亚太地区一家领先的电商及物流巨头近期的部署案例。
在运行大规模内部AI工作负载多年后，该公司着手推出商业化GPU即服务（GPUaaS）云，以基于NVIDIA DGX系统构建的大规模本地Kubernetes集群为基础。将内部集群转变为多租户云，随即带来了三项挑战。
首先，外部企业租户需要同时访问共享集群，且不能出现跨租户流量泄漏。其次，平台团队需要在100多个节点上实现云原生L7路由、TLS终止和命名空间隔离，而无需手动提交网络工单。第三，社区开源控制器缺乏支撑商业SLA所需的强大流量管理能力和全天候支持。
该公司在100个Kubernetes节点上部署了双层Kubernetes流量架构，结合使用F5 BIG-IP rSeries LTM、BIG-IP CIS和F5 Ingress Controller for NGINX。在边缘，BIG-IP rSeries设备提供高吞吐量的L4负载均衡，并通过专用vCPU、内存和路由分区实现严格的虚拟负载均衡器隔离，将每个租户域一对一映射到独立的虚拟IP。
借助F5 IngressLink，BIG-IP CIS监视Kubernetes API，自动将外部BIG-IP虚拟服务器与集群内的NGINX Pod关联，无需人工提交工单。在集群内部，租户专用的NGINX Ingress Controller Pod终止TLS连接、执行解密，并实施L7路由和身份验证，将流量引导至各租户的隔离命名空间和GPU资源。
该公司在边缘为NetOps提供BIG-IP硬件隔离能力，在集群内为平台工程师提供NGINX的云原生敏捷性，并通过BIG-IP CIS连接两者，从而按计划推出了GPUaaS平台，同时为其AI工厂扩展规模时转向BIG-IP Next for Kubernetes奠定了基础。
契合团队工作方式的流量控制与安全防护
根据《2026年企业Kubernetes战略现状》，24%的企业因单一短板而无法达到Kubernetes成熟阶段，其中最常见的短板是可观测性或准入控制。从“已建立”到“企业级”的差距，不在于平台，而在于流量控制、安全和团队协同。
F5帮助各类角色弥合这一差距。通过企业级支持的迁移路径，从已停止维护的社区版ingress-nginx迁出。借助BIG-IP CIS，自动衔接NetOps与平台工作流。使用BIG-IP Next for Kubernetes，治理多租户AI集群的入站和出站流量。通过在CVE公开披露前数周发布的纯安全更新，全面加固安全防护。F5 ADSP采用满足不同团队需求的统一架构，提供企业所需的Kubernetes运营成熟度，支持安全、高效地大规模运行Kubernetes。
想深入了解？欢迎于11月9日至12日前往盐湖城KubeCon大会的F5展位（100号），与我们的工程师直接交流，探讨如何解决Kubernetes网络瓶颈，体验交互式演示，获取实用简报，并共同解决Kubernetes瓶颈。
阅读我们的博客《为什么多数企业尚未达到企业级安全水平》。
此外，别忘了报名参加我们的网络研讨会“企业级Kubernetes策略有何不同”。
关于作者
相关博客文章
三家企业如何借助AI驱动的WAF改进虚拟补丁和运行时安全
了解三家F5客户如何利用AI驱动的WAF加快虚拟补丁部署、将误报减少50%以上，并更有信心地启用阻断模式。
F5 BIG-IP v21.0增强S3工作流的AI数据交付与摄取能力
使用F5 BIG-IP 21.0版优化S3工作流：通过低接触式配置，为AI数据交付、对象存储和RAG管道提供可扩展的安全解决方案。
Everest Group报告：生成式AI行业应用的当前趋势与未来前景
我们很高兴能为全球知名研究机构Everest Group发布的一份重要新报告作出积极贡献。该报告题为《生成式AI应用：审视横向职能中的实际应用与未来展望》，深入分析了各行业对生成式AI（GenAI）的应用情况。报告指出，IT［……］