为什么多数企业的Kubernetes应用尚未成熟

Buu Lam社区推广总监

10多年前，作为一名解决方案工程师，我看到一些组织开始将部署Kubernetes作为一项探索性项目。这是一种小团队自主开展的实验性尝试，通常与其他容器调度器的测试同步进行。实际业务工作负载仍运行在vSphere的虚拟机上，该环境围绕服务级别目标和恢复时间目标构建。不仅是服务器管理员，每个人都参与其中。可以说，这才是企业级的实践。

随后，情况发生了变化。公有云迅速发展，应用逐步实现现代化，Kubernetes成为企业运行容器化应用的默认选择。背后的驱动力一如既往：商业发展需要快速扩展规模。企业希望加快步伐，我也与许多早期客户携手，尝试将Kubernetes打造成企业级平台。

对这些客户而言，业务期望决定了目标。内部探索性项目充其量只能做到尽力而为，甚至连这一点都未必能做到。企业平台必须跟上业务发展的步伐，理想情况下，还应成为企业参与竞争的关键支撑。如今，企业对Kubernetes也有了这样的期望，但仅靠Kubernetes本身，还无法像vSphere那样构成完整的平台。它的开源基础很出色，但这仅仅是起点。

F5委托SlashData开展的新研究揭示了距离企业级要求还有多大差距。在生产环境中运行Kubernetes的企业中，61%对Kubernetes的要求不低于对其余IT环境的要求，但只有38%达到了企业级成熟度。

在生产环境中运行Kubernetes的企业中，仅38%达到企业级成熟度。

在这份报告中，企业级不仅意味着高分，还要求具备自动化准入控制、强制执行的租户隔离、集中式可观测性、书面记录的恢复目标，以及在过去12个月内经过测试的故障转移能力。调查依据团队的实际做法评分，而非团队自认为的成熟度，所用数据为2026年8月收集的445份答复，受访者均为员工人数超过500人的组织中具有实操经验的从业人员。

大多数环境已成型，但尚未成熟

在我看来，报告中的定义就像路标，标示着所有组织共同经历的发展历程。我不认为任何组织能真正走到终点，而且在确定优先事项时，总是需要权衡取舍。报告呈现了企业当前所处的阶段。半数企业（51%）处于已建立阶段，已定义标准并基本落实，但仍存在明显差距。另有11%的企业仍在推进标准化。近九成企业（88%）在至少一个领域达到最高档位，但仅有22%的企业在全部四个领域都达到这一档位。即使在总体得分达到80分及以上的51%企业中，也有约四分之一（24%）因缺少一项先决条件而未能进入最高档位。

可观测性是最常缺失的一环。在这些与最高梯队失之交臂的企业中，36%缺乏集中式可观测性，31%缺乏自动化准入控制。这两点都与我在实际工作中的观察一致。我的大多数客户，无论是否使用Kubernetes，都存在可观测性方面的不足。故障排查困难，需要参与的人数远超合理范围，而且常常演变成相互指责。

规模越大，准入控制就越重要。一位客户的环境规模庞大，因此高度依赖准入控制来治理vSphere。Kubernetes环境的规模扩展迅速，报告中被提及最多的挑战是集群和环境管理的复杂性（39%）。在大规模环境中发挥重要作用的控制措施，其实比大多数团队预期的更早就需要重视。然而，只有28%的受访者计划在未来12个月内投资可观测性，而计划投资安全和策略执行的比例为42%。

成熟度的提升需要团队协作

多年来，我发现各团队的角色比我预想的更为重要。我接触到平台和DevOps团队，是因为他们了解并信任NGINX，也希望使用它。我还接触到网络和安全团队，他们希望确认Kubernetes能够融入企业现有的NetOps和SecOps实践，而不是另建一套完全独立的工作流。

有位客户做了一件在当时不同寻常的事：为自己的DevOps工程师配备了一台专属的F5 BIG-IP。他深入掌握了它的各项功能和使用方法，并用它实现了一些我很少见到传统BIG-IP管理员亲自完成的操作（在此向Steven致意！）。这就是将信任付诸实践。成功始终源于协作与信任，因为要达到企业级要求，需要团队彼此依靠，而不是相互绕开。

研究也得出了相同的结论。在由专门的平台工程团队运维Kubernetes、独立的中央安全团队制定策略的企业中，66%达到了企业级成熟度，这一比例约为采用其他分工方式的企业的两倍。但只有19%的企业采用这种方式。应用范围同样重要：将Kubernetes作为整个组织的标准平台运行的企业中，53%达到了较高成熟度层级；而仅由单个团队使用Kubernetes的企业中，这一比例为25%。

这体现的是相关性，并不能证明因果关系。规模更大、投入更多的组织，可能只是更倾向于采用这种分工方式。不过，这与我的经验一致：能够分担工作，并信任彼此做好各自职责范围内工作的团队，才能达到企业级水平。

AI的发展正超前于治理

我也曾见过这种情况的早期迹象。一家公司当时正在快速部署机器学习工作负载，这些工作负载对业务日益重要。对于这家在其他方面较为传统的公司而言，这部分业务正是创新的核心。这样的速度可能让治理跟不上步伐。

在生产环境中运行Kubernetes的企业中，45%部署模型或提供模型服务，其中86%已将现有的Web应用防火墙（WAF）或API保护扩展至此类流量。针对AI的专用控制措施仍显滞后。仅43%的企业检查智能体工具和模型上下文协议（MCP）流量，不过49%计划在12个月内开展此类检查。成熟的IT环境在速率限制和令牌配额方面的采用率更高（80%，相比之下其他环境为50%），但在提示词检查和MCP流量检查方面，这一优势不复存在。为传统工作负载建立的治理惯例有所帮助，但尚未覆盖所有方面。

研究结果对您的技术栈有何启示

这项研究并未指向某一款产品，而是揭示了差距，这些差距对应着不同角色的职责。可观测性始于边缘遥测，属于平台和网络团队的职责范围。Web application and API protection（WAAP）是不同层级之间技术应用差距较大的领域之一，69%的企业级环境采用了这项技术，而其他环境的采用率为50%。相关策略由安全团队负责，每个集群都必须继承。故障转移必须跨集群进行测试，这需要网络和平台团队协作。

F5的方法贴合这些团队的实际工作方式。Kubernetes团队通常从开源入手，因为Kubernetes这类软件栈使开源成为默认选择。团队可以从NGINX Ingress Controller等项目起步，这是一款提供长期支持的Ingress解决方案，尽管社区ingress-nginx项目已退役；也可以选择NGINX Gateway Fabric，该项目完全符合Gateway API规范。

最终，当团队希望获得商业解决方案带来的保障时，便会转向 F5 NGINX Enterprise，以获得经过安全加固的镜像、边缘身份、针对各个应用的安全策略、支持服务级别协议（SLA），或满足大规模集群管理需求。

网络和安全团队希望Kubernetes能够适应现有工作方式，因此，配备Container Ingress Services (CIS)的F5 BIG-IP让这些团队能够通过BIG-IP应用集中式流量和安全策略，并实现跨集群故障转移，同时平台团队仍可继续在Kubernetes中工作。

对于以新型云或AI工厂规模运行的AI工作负载，F5 BIG-IP Next for Kubernetes在这一方法的基础上，提供专为Kubernetes中的AI设计的流量管理和安全功能。各团队可继续使用各自熟悉的工具，并通过共享控制点保持协同。

配套白皮书将这一过程划分为四个阶段，每个阶段均设有完成标准。时间安排仅供参考，请从符合当前成熟度的阶段开始，并根据实际情况调整进度。

1. 标准化（第0至3个月）：在每个集群中采用一种受支持的入口模式，部署边缘遥测，并明确平台和安全角色。
2. 建立（第3至9个月）：Gateway API标准、用于继承安全防护的WAF，以及集中式遥测。
3. 企业级（第9至18个月）：自动化准入控制、统一的流量与策略控制点，以及经过测试的故障转移。
4. 优化（第18个月起）：AI护栏、策略即代码，以及每季度重新评估成熟度。

第4阶段，AI再次成为重点，例如前面提到的机器学习工作负载。团队基于此前使用F5 NGINX Enterprise和搭配CIS的BIG-IP构建的基础，进入这一阶段。要满足新型云和AI工厂的规模需求，这一基础可以扩展至BIG-IP Next for Kubernetes。无论规模如何，技术能发挥多大作用，都取决于支撑它的合作关系。

找到适合的起点。下载路线图，通过自我评估和循序渐进的计划，迈向企业级Kubernetes成熟度。然后阅读《2026年企业Kubernetes战略现状》，了解完整研究内容。

此外，别忘了阅读我们的博客文章“面向各类团队的Kubernetes云原生流量控制与安全”。

关于作者

Buu Lam社区推广总监

Buu Lam 的更多博客文章