时间回到 2013 年。当一条简单的 docker run postgre 命令就能运行起 Postgre 这样复杂的传统服务时，开发者在震惊之余犹如受到天启；以 Docker 为代表的实用容器技术的横空出世，也预示着一扇通往敏捷基础设施的大门即将打开。此后，一切都在往好的方向迅速发展：
- 越来越多的开发者开始采用容器作为一种标准构建和运行方式。
- 业界也意识到，很容易将这种封装方式引入计算集群，通过 Kubernetes 或 Mesos 这样的编排器来调度计算任务 —— 自此，容器便成为这些调度器最重要的 Workload 类型。
但本文将要说明，容器并非 Kubernetes 最重要、最有价值的地方，Kubernetes 也并非仅仅是一个更广泛意义上的 Workload 调度器 —— 高效地调度不同类型的 Workload 只是 Kubernetes 提供的一种重要价值，但并不是它成功的原因。
API 才是核心
“等等 —— Kubernetes 只是一堆 API？”
“不好意思，一直都是！”
Kubernetes 的成功和价值在于，提供了一种标准的编程接口（API），可以用来编写和使用软件定义的基础设施服务（本文所说的“基础设施”，范围要大于 IaaS）：
- Specification + Implementation 构成一个完整的 API 框架 —— 用于设计、实现和使用各种类型和规模的基础设施服务；
- 这些 API 都基于相同的核心结构和语义：typed resources watched and reconciled by controllers （资源按类型划分，控制器监听相应类型的资源，并将其实际 status 校准到 spec 里期望的状态）。
为了进一步解释这一点，考虑下 Kubernetes 出现之前的场景。
Kubernetes 之前：各自造轮子，封装厂商 API 差异
Kubernetes 之前，基础设施基本上是各种不同 API、格式和语义的“云”服务组成的大杂烩：
- 云厂商只提供了计算实例、块存储、虚拟网络和对象存储等基础构建模块，开发者需要像拼图一样将它们拼出一个相对完整的基础设施方案；
- 对于其他云厂商，重复过程 1，因为各家的 API、结构和语义并不相同，甚至差异很大。
虽然 Terraform 等工具的出现，提供了一种跨厂商的通用格式，但原始的结构和语义仍然是五花八门的，—— 针对 AWS 编写的 Terraform descriptor 是无法用到 Azure 的。
Kubernetes 面世：标准化、跨厂商的 API、结构和语义
现在再来看 Kubernetes 从一开始就提供的东西：描述各种资源需求的标准 API。例如：
- 描述 Pod、Container 等计算需求的 API；
- 描述 Service、Ingress 等虚拟网络功能的 API；
- 描述 Volumes 之类的持久存储的 API；
- 甚至还包括 Service Account 之类的服务身份的 API 等等。
这些 API 是跨公有云/私有云和各家云厂商的，各云厂商会将 Kubernetes 结构和语义对接到它们各自的原生 API。因此我们可以说，Kubernetes 提供了一种管理软件定义基础设施（也就是云）的标准接口。或者说，Kubernetes 是一个针对云服务（Cloud Services）的标准 API 框架。
Kubernetes API 扩展：CRD
提供一套跨厂商的标准结构和语义来声明核心基础设施（Pod/Service/Volume/ServiceAccount/……）， 是 Kubernetes 成功的基础。在此基础上，它又通过 CRD（Custom Resource Definition）， 将这个结构扩展到任何/所有基础设施资源。
CRD 在 1.7 引入，允许云厂商和开发者自己的服务复用 Kubernetes 的 spec/impl 编程框架。
有了 CRD，用户不仅能声明 Kubernetes API 预定义的计算、存储、网络服务，还能声明数据库、task runner、消息总线、数字证书……任何云厂商能想到的东西！
Operator Framework 以及 SIG API Machinery 等项目的出现，提供了方便地创建和管理这些 CRD 的工具，最小化用户工作量，最大程度实现标准化。
例如，Crossplane 之类的项目，将厂商资源 RDS 数据库、SQS queue 资源映射到 Kubernetes API，就像核心 Kubernetes controller 一样用自己的 controller 来管理网卡、磁盘等自定义资源。Google、RedHat 等 Kubernetes 发行商也在它们的基础 Kubernetes 发行版中包含越来越多的自定义资源类型。
小结
我们说 Kubernetes 的核心是其 API 框架，但并不是说这套 API 框架就是完美的。事实上，后一点并不（非常）重要，因为 Kubernetes 模型已经成为一个事实标准：开发者理解它、大量工具主动与它对接、主流厂商也都已经原生支持它。用户认可度、互操作性 经常比其他方面更能决定一个产品能否成功。
随着 Kubernetes 资源模型越来越广泛的传播，现在已经能够 用一组 Kubernetes 资源来描述一整个软件定义计算环境。就像用 docker run 可以启动单个程序一样，用 kubectl apply -f 就能部署和运行一个分布式应用， 而无需关心是在私有云还是公有云以及具体哪家云厂商上，Kubernetes 的 API 框架已经屏蔽了这些细节。
因此，Kubernetes 并不是关于容器的，而是关于 API。
