一、云原生为什么会成为主流¶

云原生有利于各组织在公有云、私有云和混合云等新型动态环境中构建和运行可弹性扩展的应用。

从工程视角看，云原生的关键不只是“把应用放到云上”，而是尽可能利用云提供的弹性、自动化、标准化和服务化能力去设计、交付与运行系统。可以把它概括为一句话：利用云的一切能力去设计应用和平台。

二、云原生的定义到底强调什么¶

理解云原生时，可以重点抓住下面几个判断标准：

• 应用要能适应动态环境，而不是依赖固定机器和固定部署方式。
• 应用要支持弹性扩缩容，能够随着业务流量变化快速伸缩。
• 应用要具备自动化交付和自动化运维能力，减少人工干预。
• 应用要易于拆分、治理和观测，从而支撑持续演进。

这也是为什么云原生通常会与容器、微服务、持续交付、DevOps 和 Kubernetes 一起出现，因为这些技术共同服务于同一个目标：让软件交付更快、运行更稳、扩展更轻。

三、云原生的发展历程¶

云原生并不是突然出现的，它经历了一个逐步成形和不断扩展的过程。

3.1 概念诞生¶

• 2010 年，WSO2 创始人 Paul Fremantle 首次提出 Cloud Native。

3.2 早期实践¶

• 2013 年，Pivotal 的 Matt Stine 演示了基于 AWS 的云原生实现。
• 2015 年，通过《迁移到云原生应用架构》进一步重新定义了云原生架构的实践方式。

3.3 CNCF 推动标准化¶

• 2015 年，云原生计算基金会 CNCF 成立。
• 在早期定义中，CNCF 将云原生聚焦为三点：容器化、微服务、容器编排。

3.4 技术体系持续扩展¶

• 2017 年，Pivotal 将云原生进一步概括为 DevOps、持续交付、微服务和容器。
• 2018 年，CNCF 重新定义云原生，把容器、微服务、服务网格、不可变基础设施和声明式 API 纳入核心语境。

3.5 进入加速落地阶段¶

• 2020 年开始，云原生进入爆发式增长阶段，逐渐成为企业数字化转型的重要基础能力。
• 到今天，云原生已经发展成一个成熟、稳定、功能强大且标准化程度很高的技术体系，企业平台架构几乎都能看到它的影子。

四、如何看懂 CNCF 云原生全景图¶

CNCF 维护了一张非常有代表性的云原生全景图，用来展示生态中的项目与产品分类：

参考链接：https://landscape.cncf.io/?group=projects-and-products

这张图的价值不在于一次性记住所有项目，而在于帮助我们形成“生态地图”：

• 它能告诉你云原生并不等于 Kubernetes，而是覆盖运行时、调度、观测、安全、交付、数据库、网络等多个层次。
• 它能帮助你判断某个工具位于生态中的什么位置，解决的是哪一类问题。
• 它也能帮助团队做技术选型，避免在没有全局视角时被局部热点牵着走。

五、CNCF 项目为什么要分级¶

CNCF 将生态项目划分为 Sandbox、Incubating 和 Graduated 三个阶段，本质上是在表达项目的成熟度和生态状态。

5.1 Sandbox¶

Sandbox 可以理解为沙盒项目，特点是：

• 更偏早期实验性质。
• 主要用于验证某个创新想法、技术方向或新概念。
• 对成熟度要求不高，但通常需要至少 2 个 CNCF 成员支持。

这类项目适合观察趋势，但在生产环境落地时需要谨慎评估。

5.2 Incubating¶

Incubating 是孵化阶段，意味着项目已经完成了从“想法验证”到“初步可用”的跨越：

• 技术路线基本可行。
• 社区生态开始形成。
• 需要证明真实应用价值。
• 需要具备较清晰的治理模式、文档和社区贡献能力。

这类项目通常已经值得技术团队重点跟踪。

5.3 Graduated¶

Graduated 可以理解为毕业项目，代表项目已经通过更严格的审核，达到较高成熟度、广泛采用和可持续发展标准。

像 Kubernetes、Prometheus 这类项目，之所以成为行业基座，正是因为它们不仅技术成熟，而且治理、社区和生态协作都足够稳定。

六、学习云原生时应该先建立什么认知¶

在真正动手学习 Kubernetes 之前，先建立这三层认知会更有效：

• 第一，云原生是一种面向云环境的软件设计与交付方式，而不是某一个产品。
• 第二，CNCF 全景图提供的是生态全貌，帮助我们理解“工具之间如何配合”。
• 第三，项目分级体现的是成熟度，不同阶段的项目适合不同的试用和落地策略。

先把这些基础认知打牢，后面再进入云原生技术体系、声明式 API、Serverless、十二要素和 Kubernetes 平台实践时，就更容易形成完整闭环。