DEV Community: mahuijie0512

一起读报告：CNCF年度云原生调查之人工智能基础架构的未来

mahuijie0512 — Mon, 26 Jan 2026 05:45:35 +0000

简介

2026年1月，CNCF发布了年度云原生调查之人工智能基础架构的未来。文中对kubernetes在未来AI基础架构中成为事实上的标准，做了技术分析和高度赞赏。
原文下载链接：
https://www.cncf.io/reports/the-cncf-annual-cloud-native-survey/

观点

66%的组织，使用kubernetes来运行他们的生成式AI工作负载
82%的容器用户在生产环境中部署Kubernetes，较2023年的66%有所上升。
受访组织中，云原生技术的采用率已达到98%。
开发团队的文化变革成为容器部署的首要挑战（47%），其排名已超过技术复杂性。
生产应用程序中的容器使用率从2023年的41%上升至2025年的56%。
47%的组织偶尔部署AI模型，仅有7%的组织进行每日部署。
52%组织并非构建或训练自有AI模型，而是作为模型使用者。
GitOps的采用率在云原生探索者中为0%，而在云原生创新者中跃升至58%。
在成熟组织中，CI/CD的采用率达到91%，成为最基础的实践。
74%云原生创新者每日多次检查代码部署的频率远高于探索者（35%）。
59%的组织将云原生技术用于大部分或几乎全部开发工作（高于2023年的54%）。
随着机器驱动的自动化使用增加，基础设施可持续性已成为关键关注点。

执行摘要

2025年CNCF年度报告显示，云原生生态系统已抵达关键转折点。这一最初作为实验性架构出现的技术，现已固化为企业基础设施标准——目前98%的组织均采用云原生技术。然而，如今的故事已不再是技术采纳本身，而是关乎成熟度、可持续性，以及在AI炒作周期之下悄然发生的深刻变革。

2025年的发展由三大关键主题定义：

首先，Kubernetes已从容器编排平台演进为AI基础设施平台，目前有66%的企业在其上运行生成式AI负载。主要挑战已从技术复杂性转向组织转型，其中文化阻力以47%的占比成为当前首要难题。同时，开源基础设施的可持续性正演变为一项关键问题——机器驱动的自动化使用正持续冲击着那些支撑软件构建、测试、部署与分发的核心系统。

其次，数据表明云原生成熟度遵循可预测的演进模型。组织普遍经历四个递进阶段：探索者、采纳者、实践者与创新者，每个阶段均呈现出特定的技术采纳模式和开发速度特征。GitOps的采用情况可作为一项关键衡量指标：探索者中尚未有组织落地该实践，而在创新者中，已有58%实现了符合GitOps标准的部署。

第三，报告揭示了AI愿景与基础设施现实之间的深刻鸿沟。尽管公众视线聚焦于模型突破，但现实是47%的组织仅偶尔部署AI模型，52%的组织完全不进行模型训练。真正的竞争优势并不在于算法本身，而在于那些不易引人注目却至关重要的基础设施能力：稳健的CI/CD流水线与高效的资源优化体系。

Kubernetes：悄然崛起的AI基础设施平台

当行业焦点仍集中于AI模型突破时，一场静默的变革正在基础设施层悄然发生。CNCF调研数据显示，66%的企业正选择Kubernetes作为其生成式AI工作负载的运行平台。然而，成功的关键在于能否攻克资源管理与部署流水线这些看似平凡却至关重要的挑战。

Kubernetes作为实际标准AI平台的崛起，标志着企业机器学习运营模式的根本性转变。传统ML基础设施通常依赖专业化的单体平台，导致数据科学团队与生产工程团队之间形成壁垒。而Kubernetes通过提供统一编排层弥合了这一鸿沟，既能处理传统应用负载，也能支撑计算密集型的AI任务。Kubeflow等项目提供端到端ML工作流，KServe则专攻规模化模型服务。随着GPU调度能力、节点亲和性规则及精细化资源配额管理等功能的引入，企业得以跨团队、跨工作负载高效共享昂贵的硬件资源。

Kubernetes的AI采用浪潮

如图1所示，Kubernetes已成为生产环境AI任务实际采用的编排层，但其中全面采用（23%）与部分采用（43%）的比例差异，反映出企业正采取审慎的、基础设施优先的推进策略。

在推理工作负载上实现Kubernetes全面采用的23%企业，代表了已达成真正机器学习运维（MLOps）成熟度的组织。这些团队通常已实现模型部署的GitOps工作流，通过Prometheus与Grafana建立针对模型性能指标的健全监控体系，并将AI工作负载集成至现有CI/CD流水线中。

占43%的部分采用群体，通常从特定应用场景开始使用Kubernetes——常见于批量推理任务或开发与预发环境，同时仍在生产服务环节沿用原有系统。而计划采用Kubernetes的18%企业，可能正面临多重阻碍：既有对专有ML平台的现有投入、对运维复杂性的顾虑，也存在团队技能重塑的现实需求。

将AI工作负载迁移至Kubernetes并非简单的容器化改造。企业必须应对一系列特有需求：通过容器镜像仓库或对象存储管理大型模型文件；确保模型能调度至具有GPU亲和性的适量资源节点；为训练流水线与低延迟推理服务设计不同的架构模式；并实施专为机器学习模型设计的金丝雀部署与回滚策略。

多数企业实为AI模型使用者

图2中推理服务与模型训练的对比数据揭示了一个关键趋势：大多数企业实为AI模型的使用者而非创造者。52%的受调研组织既不构建也不训练AI模型，而那些开展相关工作的企业也很少从零开始构建，而多基于自身数据进行微调。这一现实对基础设施需求产生了直接影响——推理工作负载需要完全不同的可扩展性与成本优化策略。

采用预训练模型的企业面临着一系列独特的基础设施挑战。其关注重点转向通过模型量化、ONNX运行时优化及批处理策略等技术实现推理优化。与训练任务需要昂贵GPU持续数小时乃至数天不同，推理服务需要持续运行，这使得成本管理尤为关键。企业需要实施精细化的弹性伸缩策略：对计算需求较低的工作负载采用CPU推理，同时为延迟敏感型应用保留GPU资源。

37%的企业选择托管API服务，这反映出部分组织将上市速度置于基础设施控制权之上。即便如此，这些团队仍可受益于基于Kubernetes的编排层——该架构能实现跨多服务商的重试与降级策略，通过缓存常用响应降低API成本，以统一接口封装各服务商特定API，并监控不同服务的使用量与成本。而25%选择自主托管模型的企业，则是基于经济性考量认为自有基础设施的投资回报具有合理性。这种选择通常适用于月推理请求量超百万次、数据隐私法规限制云端API使用，或延迟要求必须本地部署的场景。

在更贴近终端的层面，边缘部署（13%）作为一种新兴模式，正催生对专业化编排能力的需求。

部署成熟度现状

部署频率数据揭示了现实与理想的差距（图3）。47%的企业仅偶尔部署AI模型，每日部署的企业仅占7%。这反映出当前的AI革命正以系统性推进的形态展开——生产级部署需要健全的CI/CD、监控与治理基础设施作为支撑。

与传统代码可通过单元测试和集成测试建立信心不同，AI模型需要通过留存数据集性能测试等复杂验证流程进行统计验证。这些验证环节虽会降低部署速度，却是生产环境可靠性的根本保障。

仅占7%的极少数实现每日AI部署的企业，很可能已建成能持续吸纳新数据的自动化再训练流水线。这些组织将模型视为需要持续更新的有机生命体，而非静态资产。而其余93%的企业距离这一状态仍遥不可及。

AI工作负载的多样性

在基于Kubernetes运行AI/ML工作负载的企业中，实际应用场景呈现出显著多样性，远超越市场炒作范畴（图4）。真正的AI/ML采用关乎实际的基础设施挑战，而非仅仅是热门术语的堆砌。

基础设施优先的路径

在AI领域取得成功的企业，往往并非拥有最优模型者，而是具备成熟基础设施能力来可靠部署与扩展工作负载的组织。Kubernetes正成为其基础平台，但成功的关键在于将AI/ML视为一流的基础设施挑战，而不仅仅是算法问题。

当各组织竞相部署AI工作负载之际，2025年9月开源基础设施维护者联名发布的公开信发出了严峻警示：关键系统运行在"极度脆弱的前提"之下，依赖善意而非与实际使用量匹配的可持续资金模式。该信明确指出AI/ML工作负载正推动"机器驱动的、往往存在浪费的自动化使用"，使得可持续性挑战尤为尖锐。

公开信作者指出："商业规模的工作负载常在无缓存、无限流、甚至未意识到其造成压力的状态下运行。"这正精准描述了AI工作负载的现状。偶尔部署模型的企业（占受访者的47%）可能以为对基础设施影响甚微，但其产生的压力仍远超预期。

AI的未来发展必须遵循基础设施优先的路径。这意味着要实施缓存策略、采用资源配额、监控消耗情况，并为支撑AI工作负载的开源项目贡献力量。CNCF生态系统虽提供了可持续编排工具，但其效能完全取决于企业是否有意识地运用它们。

云原生基础设施的成熟之路

CNCF多年调研数据显示，云原生技术采纳已从实验阶段迈向标准化——Kubernetes成为基础设施标配，而当前最大的瓶颈可能并非技术本身，而是组织变革与日益复杂的合规环境。

2023年至2025年间，云原生领域格局发生了深刻转变。曾经的前沿架构选择，如今已成为企业必备基础：98%的组织至少在某些场景中应用云原生技术，而处于早期探索阶段的比例已降至仅8%。生产应用程序中的容器使用率从41%提升至56%，同时Kubernetes进一步巩固了其作为实际标准编排平台的地位，已在82%的容器化环境中运行。

云原生技术采用率保持高位稳定

数据显示，深度采用云原生技术（即将其用于"大部分"或"几乎全部"开发和部署工作）的企业比例，从2023年的54%增至2024年的60%，2025年稳定在59%（图5）。与此同时，仅处于起步阶段或尚未使用云原生技术的企业比例，则从2023年的13%下降至2025年的10%。这表明该技术已完全跨越早期采纳阶段，进入广泛应用的成熟期。

容器使用率持续增长

在生产应用中大部分或全部使用容器的企业比例，从2023年的41%上升至2025年的56%（图6）。仍处于容器试点阶段的企业则从11%下降到仅6%。这一两年间的显著增长体现了容器技术的成熟——Docker与containerd提供可靠的运行时，镜像仓库保障安全存储，安全扫描工具能有效识别漏洞。

企业已做出明确选择：要么容器符合其需求并进入生产阶段，要么不适合而放弃试点。长期处于试验状态的情况已越来越少。

如图7所示，2025年的首要挑战是"开发团队的文化变革"（47%），其次为培训缺失（36%）与安全问题（36%）。这标志着与2023年的重要转变——当时安全与复杂性等技术挑战占据主导。随着《网络韧性法案》等新规出台，安全问题在未来数年仍将至关重要。

文化阻力在不同组织中呈现多元形态：开发者可能质疑容器是否为简单应用带来不必要的复杂性，或担忧Kubernetes的生产就绪程度；运维团队可能抵制被视为"开发者玩具"的技术，并对容器化系统的故障排查表示忧虑；管理层则担心这会分散功能交付的专注度，并形成对专业知识的过度依赖。

“Kubernetes变得‘无聊’”实为最高赞誉

2025年，容器用户中已有82%在生产环境中使用Kubernetes，较2023年的66%显著提升（图8）。这意味着它在容器生态内已接近全面普及。将Kubernetes描述为“无聊”，实则是对其最高程度的褒奖——在技术领域，“无聊”意味着可靠无误、行为可预测且文档完备、成熟到能处理各类边界情况，以及API稳定不随版本频繁变动。

这两年采用率的跃升，正反映了该技术的成熟进程：Kubernetes逐步移除已弃用功能并稳定API，主流云服务商实现功能对齐，Helm图表与Operator简化了应用部署，CRD（自定义资源定义）生态也日趋成熟。Kubernetes的胜出，源于它已达到标准阶段，并通过其生态系统、知识体系和工具链形成了其他方案难以匹敌的网络效应。

WebAssembly仍在等待转折点

约65%的企业连续三年均表示没有WebAssembly相关经验，2025年仅有5%的企业具备完整部署经验（图9）。这表明WebAssembly在云原生环境中尚未迎来其转折点。尽管WebAssembly具备显著优势：包括语言无关性、接近原生的性能、沙箱化安全机制、强可移植性以及轻量化资源占用。理论上，Wasm有望替代容器承载多种工作负载，实现更快的冷启动速度、更高的部署密度和更强的安全性能。

云原生成熟度模型

为更清晰地理解企业在云原生旅程中所处的位置，我们依据其云原生采用程度将其划分为四个成熟的等级：

云原生探索者（占企业总数的8%）：正开始尝试使用云原生技术。这类组织主要进行容器和基础部署的试验性探索。

云原生采纳者（32%）：已将云原生技术应用于部分开发与部署工作中。这类组织通常在特定项目或团队中进行选择性应用。

云原生实践者（34%）：在大部分开发与部署中采用云原生技术。这类组织已在大多数项目中实现主流化应用。

云原生创新者（25%）：几乎将所有开发与部署工作构建于云原生技术之上。这类组织已完成全面、覆盖整个企业的转型。

本次调研揭示了云原生采用过程中的成熟度递进模型。数据显示，随着企业从"探索者"向"创新者"进阶（依据其云原生技术应用的广度与深度），它们会系统性地采纳更先进的实践与工具。这充分说明：云原生成熟度不仅关乎容器技术的运行，更意味着对整套现代开发生态体系的全方位拥抱。

云原生探索者

云原生探索者如今已成为少数群体，仅占全部组织的8%（图10）。如图11所示，大型企业（员工数超过5000人的企业占45%）在该群体中占比较高，这表明企业规模本身会带来复杂性阻碍。这种向大型企业倾斜的现象揭示出：多样化的技术栈中运行着数千个应用、数十年积累的技术债务、需要进行全面评估的风险规避文化以及分散的决策流程，共同拖慢了这些组织的技术采用速度。

这类组织尚处于学习阶段，其收入与云原生技术关联度极低，平均仅占10%。这表明云原生技术对他们而言仍处于实验性质，尚未成为业务核心——创造营收的主力仍是传统系统。

云原生采纳者

采纳者正处于早期扩张阶段。他们从云原生技术中获得的平均收入仅占26%（图12），这表明这些组织仍在构建内部能力，尚未将相关专业知识全面转化为商业收益。

地域分布数据显示，欧洲处于领先地位（58%），美洲次之（29%），亚太地区占13%。这一较低的收入占比反映出：云原生工作负载仍主要集中于开发与预发环境而非生产环境；内部平台正在建设中但尚未实现创收；迁移工作仍在进行，传统系统依旧占据主导地位。

云原生实践者

达到此成熟度的组织通常将云原生技术作为新开发的默认选择，设有平台工程团队提供自助服务能力，并在各团队间标准化使用GitOps工作流程。如图13所示，这类企业从云原生技术获得的平均营收占比为35%，这表明深度技术采用与商业模式演进已形成关联。

这一营收拐点意味着：生产环境的核心工作负载已主要在云原生基础设施上运行；新产品已全面采用云原生优先架构；关键应用的传统迁移工作基本完成。这些组织通常还具备以下特征：通过指标、日志与链路构建全面监控体系；借助准入控制器实现安全策略自动化；运行跨环境的多集群部署；并定期进行灾难恢复流程测试。

云原生创新者

在创新者类别中，小型企业（1-499名员工）占据主导地位，比例为55%，这凸显了其敏捷性优势（图14）。这些企业超过一半的营收来源于云原生技术。这体现了初创企业的优势：通常无需迁移遗留基础设施、拥有工程师驱动且融合DevOps基因的技术文化、小团队比大型企业转型更快，以及参与竞争所必需的经济性要求驱动其追求基础设施高效。云原生技术占其大部分营收这一事实表明：云原生已成为其核心基础设施而非实验性尝试，其商业模式依赖于云原生能力，且竞争优势既源于基础设施的成熟度，也来自云原生技术的持续创新。

技术路线图与发布实践

先进技术的应用需要以基础成熟度为前提。创新者在生产环境中运行服务网格的可能性是探索者的近3倍，而有状态容器和无服务器架构在成熟组织中采用率更高。开发速度是区分不同成熟度水平的显著标志：创新者以根本不同的节奏运作——他们更频繁地提交代码，并实现了探索者与采纳者尚未企及的自动化部署水平。

数据显示，随着组织从探索者进阶至创新者，它们会系统性地采用更先进的实践与工具（图15）。技术采用与成熟度紧密相关：更成熟的组织已普遍采用核心技术，如创新者中有状态容器采用率达79%，无服务器架构达64%，服务网格达39%。开发速度随成熟度同步提升：创新者中74%每日多次提交代码，41%实现每日发布，59%自动化大多数部署——这些实践在探索者中几乎尚未开展（图16）。

GitOps与CI/CD

如图17所示，GitOps代表着云原生成熟度的高级阶段。探索者中尚无组织采用该实践，而创新者中已有58%实现了符合GitOps标准的部署。GitOps是一项顶峰实践，需要深厚的基础建设支撑。

CI/CD则是云原生成熟度的入门实践（图18）。即使是刚刚起步的组织，其采用率也已达到42%；而在创新者中，这一比例接近普及（91%），使其可能成为云原生技术栈中最根本的实践。

结论

随着云原生技术达到98%的企业采用率，行业讨论焦点已从“是否采用”转向“如何最大化其价值”。2025年最显著的趋势是AI工作负载与云原生基础设施的融合——66%的企业已在Kubernetes上运行生成式AI应用。然而，AI愿景与部署现实之间仍存在巨大鸿沟：尽管企业竞相尝试AI模型，但仅7%实现每日部署，且多数企业仅作为模型使用者而非训练者。

从探索者到创新者的演进遵循可预测的模式，其中GitOps采用率是衡量组织成熟度的可靠标尺：采用率为0%的组织仍处早期阶段，而达58%的组织已完成全面转型。这种规律性为希望推进云原生进程的企业提供了清晰路线图。

开源基础设施的可持续性已成为重要议题。随着AI工作负载通过机器驱动的自动化使用持续冲击系统，支撑该基础设施的开源项目面临空前压力。受益于云原生技术的企业必须超越被动使用，通过资金支持、技术贡献和负责任的资源使用，转向主动维护。否则，可能出现“公地悲剧”——关键基础设施在负载下逐渐衰退。

展望未来，云原生已不再是目标，而是基石。在2025年及以后取得成功的企业，将是那些将基础设施视为核心竞争力、在技术采纳同时投资组织转型，并认识到可持续基础设施需要可持续支持模式的组织。本调研数据不仅呈现了技术采用的现状，更揭示了在这个日益依赖基础设施的世界中，领先者与跟随者的根本区别。

当云原生成为“平凡”的基础设施，竞争优势将转向那些能够在此基石上构建可靠、可扩展且可持续系统的组织。

一篇文章讲清楚TLS

mahuijie0512 — Thu, 22 Jan 2026 09:39:15 +0000

为什么需要TLS？

在学习kubernetes的过程中，网络，安全，存储，是很多人的拦路虎，因为里面涉及的概念和名词很多，很容易把人搞晕。
因此很多人也就对这几块内容选择性忽略，殊不知这些内容才是kubernetes的核心。
一个关于学习的统计数据表明，62%的人在学习安全知识的过程中，都会感到困难或者不舒服，我自己也是如此。
因此花了一些时间，整理了一篇文章，帮助自己学习的同时，也希望帮助大家理解TLS。

首先为什么需要TLS？TLS的全称是Transport Layer Security，传输层安全协议。前身是SSL，Secure Sockets Layer，安全套接字层协议。
在网络传输过程中，无论是互联网访问，还是内网数据传输，你都不希望使用明文传输吧，使用明文就像在网上裸奔，访问信息很容易被中间人窃取，篡改，伪造等。
因此TLS应运而生，TLS通过加密技术，确保数据由明文变成了随机的字符（密文），保证在传输过程中不被窃取和篡改。

TLS如何实现安全目标呢？

首先它定义了CIA三要素：

机密性Confidentiality：数据加密，数据只能被客户端和服务器所理解。
完整性Integrity：使用哈希算法，确保数据未被篡改。
身份认证Authenticity：防冒充，确认你在和预期的实体对话。

TLS最基本的概念，在后边的文章中会反复提到：

秘钥Key：加密和解密数据所使用的参数。

对称加密Symmetric Encryption：加密和解密使用相同的秘钥，速度快，适合大数据量传输。
非对称加密Asymmetric Encryption：加密和解密使用一对秘钥，公钥和私钥，速度慢，适合小数据量传输，一般用于秘钥交换。

哈希算法Hash Algorithm：对数据进行摘要计算，生成固定长度的哈希值，用于数据完整性校验。

数字证书Digital Certificate：由“权威机构”颁发的电子文档，用于证明公钥的合法性，包含公钥，持有者信息，有效期等。证书通过提交CSR（证书签名请求）给CA机构申请获得。

CA Certificate Authority：证书授权机构，负责颁发和管理数字证书的机构。

让我们来看看这些基本概念都是干什么用的：

对称加密的目的：加密，对应的三要素：机密性
非对称加密的目的：加密，对应的三要素：机密性
还可以用于更多的事情：

交换“预主密钥pre-master secret”: 用于生成对称加密的会话密钥session key，这样浏览器和服务器都拥有了会话密钥
通过私钥和公钥配对来提供真实性，这就是签名的概念。对应的三要素：真实性哈希算法提供完整性。似乎这一切就很完美了，但确实是这样吗？

但仍然可能存在一个问题，假如攻击者伪装成服务器，向浏览器发送数据，浏览器如何确认对方是“正牌货”呢？
因此必须引入PKI(public key infrustructure)证书颁发机构的概念，相当于一个第三方来告诉浏览器和服务器，对方是合法可信任的实体。保证了真实性Authenticity。

所以这不光是复杂的技术，更是人类的智慧!

为了满足以上的需求，因此需要使用秘钥套件。
比如HTTPS：ECDHE-RSA-AWS128-GCM-SHA256
解释：
ECDHE: premaster secret exchange algorithm
RSA: client and server authentication algorithm
AES128-GCM: symmetric encryption algorithm
SHA256: hashing algorithm

HTTPS使用的加密算法特点：
RSA：非对称加密算法，一般2048位，使用一对密钥，公钥和私钥，公钥和私钥有数学关系。一般公钥用来加密数据，私钥用来解密数据。RSA算法的安全性基于大数分解的困难性，即两个大质数相乘的结果很难被分解。
ECC：椭圆曲线加密算法，非对称加密算法的一种，使用椭圆曲线数学结构来生成公钥和私钥。相比RSA，ECC在相同的安全级别下，密钥长度更短，计算效率更高。
AES：对称加密算法，使用相同的密钥进行加密和解密。AES算法依赖于明文，它将明文切成128位的块，然后对这些块进行加密。
HTTPS使用对称加密和非对称加密的混合算法，如果使用RSA进行密钥交换，AES进行数据加密和传输。还有很多算法组合方式。

TLS session key 大致生成过程

initial connection初始化连接：浏览器发送握手信号给服务器，告诉服务器想要一个安全连接
asymmetric encryption for key exchange对秘钥交换使用非对称加密：握手期间，服务器发送公钥给浏览器，接着浏览器生成一个随机对称session key，然后用服务器公钥加密，然后发回给服务器
decryption by server服务器解密：服务器用私钥解密收到的信息，获取session key
symmetric encryption for data transfer使用对称加密进行数据传输：现在双方都有session key，在他们沟通过程中切换为对称加密，这样效率比非对称加密高很多
session key的特点：每个session key都是临时的，对每个session来说都是唯一的，及时这个session key被攻破也只影响当前的session。新的session会产生新的session key

TLS连接过程，用来交换的各种东西，以及他们都是怎么来的

首先服务器有3个东西，CA签发的证书，一套公钥和私钥
客户端初始化一个TLS握手：发送"Client Hello"，支持的TLS版本信息，一个包含时间戳的客户端随机数，session id [明文]
服务器回应：发送“Server Hello”，使用客户端支持的加密算法，支持的TLS版本，服务器随机数，session id和扩展信息 [明文]
服务器发送CA签发的证书
客户端使用CA的公钥解密证书并验证证书确实发自服务器端
客户端生成预主密钥，并通过服务器的公钥（证书中包含）发送给服务器
服务器通过自己的私钥，解密并获得预主密钥
双方通过客户端随机数，服务器随机数和预主密钥，生成主秘钥
通过主秘钥生成session key
客户端和服务器各自通过session key加密“finished”信息给对方，确认双方都有正确的session key
后续同一个session内数据传递使用session key加密