Kubernetes 为什么是一个“数据库”？难道 etcd 不是 Kubernetes 的数据库吗？
这里统一回复一下 :-)
大家可能都听说过，Kubernetes 的核心特征是“声明式 API”。在 Kubernetes 社区中，我们一般把这个特征称作“声明式应用管理体系”。
而实际上，这个体系背后的理论基础，正是一种叫做 Infrastructure as Data （ IaD ）的思想。这种思想认为，基础设施的管理不应该耦合于某种编程语言或者配置方式，而应该是纯粹的、格式化的、系统可读的数据，并且这些数据能够完整的表征使用者所期望的系统状态。
而这样做的好处就在于，任何时候我想对基础设施做操作，最终都等价于对这些数据的“增、删、改、查”。而更重要的是，我对这些数据进行“增、删、改、查”的方式，与这个基础设施本身是没有任何关系的。所以说，我跟一个基础设施交互的过程，不会被绑定在某种编程语言、某种远程调用协议、或者某种 SDK 上。只要我能够生成对应格式的“数据”，我就能够天马行空的使用任何我喜欢的方式来完成对基础设施的操作。
这种好处具体体现在 Kubernetes 上，就是如果我想在 Kubernetes 上做任何操作，我只需要提交一个 YAML 文件，然后对这个 YAML 文件进行增删改查即可。而不是必须使用 Kubernetes 项目的 Restful API 或者 SDK 。这个 YAML 文件，其实就是 Kubernetes 这个 IaD 系统对应的 Data （数据）。
所以说，Kubernetes 从出生起就把它的所有功能都定义成了所谓的 “API 对象”，其实就是一份一份的 Data 。这样，使用者就可以通过对这些 Data 进行增删改查来达成自己想要的目标，而不是被绑定在某种具体的语言或者 SDK 上。这不仅让 Kubernetes 的使用者获得了极高的自由度，更重要的是，这让使用者基于 Kubernetes 构建上层系统或者跟其他系统集成变得非常容易：不管这个系统是什么语言编写的，它只需要通过它自己的方式生成和操作一个个 Kubernetes API 对象，就可以跟 Kubernetes 进行交互。
而正是因为使用者能够以非常低的代价基于 Kubernetes 构建或者集成其他系统，才使得 Kubernetes 能够成功的把自己"塞进"基础设施与传统 PaaS 之间，向下集成各种云和基础设施的能力，对上支持使用者构建各种应用管理系统。所以说，IaD 正是 Kubernetes 能够达成 “The Platform for Platform” 这个目标的核心战斗力所在。
说到这里，大家估计也就明白了：这种 IaD 设计中的 Data 具体表现出来，其实就是声明式的 Kubernetes API 对象；而 Kubernetes 中的控制循环，则是确保系统本身能够始终跟这些 Data 所描述的状态永远保持一致。
所以说，我们在使用 Kubernetes 的时候之所以要写那么多 YAML 文件，只是因为我们需要通过一种方式把 Data 提交给 Kubernetes 而已。在这个过程中，YAML 只是一种为了让人类格式化的编写 Data 的一种载体。如果做一个类比，YAML 只是我们小时候作业本里的“田字格”，“田字格”里写的那些文字，才是真正 Kubernetes 需要处理的 Data 。
一句话：Kubernetes 的 IaD 的本质，决定了它的工作方式其实更类似一个“数据库”，而不像传统认知上的分布式系统。Kubernetes 拥有完善的数据模型（ API types/CRD ）、视图层（ Open Application Model ）、索引层（ Informer ）和驱动层（ Controller ），它的整套体系都紧密围绕着“数据”这个一等公民设计和运转，由“数据”来驱动整个系统向用户声明的终态逐渐逼近。而至于 etcd ？它其实是这个系统所依赖的 CMDB 。是的，你大可以用自己喜欢的 CMDB 来替代，它不会影响 Kubernetes 自己的工作方式。但这可能并不是抖机灵 :-)
而如果你对 IaD 以及整个 Kubernetes 背后数据模型、视图层、驱动层等核心机制感兴趣；或者，你可能已经发现这个“数据库”系统好像还缺点什么。
没错，这些正是我们团队的重点工作内容，欢迎你投递简历或者进一步交流：
https://www.v2ex.com/t/666137