kubernetes设计原理

声明式应用管理

　　声明式描述的期望状态。这个描述必须是严格意义上使用者想要的最终状态，如果你在这个描述里面填写的是某个中间状态，或者你希望动态的调整这个期望状态，都会破坏这个声明式语义的准确执行。

　　基于 reconcile 的状态逼近过程。Reconcile 过程的存在，确保了系统状态与终态保持一致的理论正确性。 确切地说，Reconcile 过程不停的执行“检查 -> Diff -> 执行”的循环，才使得系统能够始终对系统本身状态与终态直接的差异并能够采取必要的行动。而相比之下，仅仅拥有声明式的描述是不充分的。这个道理很容易理解，你第一次提交这个描述时系统达成了你想要的期望状态，并不能代表、也不能保证一个小时后的情况也是如此。很多人会搞混“声明式应用管理”和“声明式风格的 API” ，其实就是对 Reconcile 必要性没有正确的认识。

　　Infrastructure as Data，基础设施的管理不应该耦合于某种编程语言或者配置方式，而应该是纯粹的、格式化的、系统可读的数据，并且这些数据能够完整的表征使用者所期望的系统状态。

　　如果想在 Kubernetes 上做任何操作，只需要提交一个 YAML 文件，然后对这个 YAML 文件进行增删改查即可。而不是必须使用 Kubernetes 项目的 Restful API 或者 SDK 。这个 YAML 文件里的内容，其实就是 Kubernetes 这个 IaD 系统对应的 Data（数据）。

　　这种 IaD 设计中的 Data 具体表现出来，其实就是声明式的 Kubernetes API 对象；而 Kubernetes 中的控制循环，则是确保系统本身能够始终跟这些 Data 所描述的状态永远保持一致。从这一点上来说，Kubernetes 本质上其实是一个以数据（Data）来表达系统的设定值、通过控制器（Controller）的动作来让系统维持在设定值的调谐系统。

　　Kubernetes 暴露出来的各种 API 对象，实际上就是一张张预先定义好 Schema 的表（Table）。而编写出的那些 YAML 文件，其实就是对这些表中的数据（Data）进行的增删改查（CURD）。而 YAML 这个工具本身，则好比 SQL 一样是一个帮助你对数据库中的数据进行操作的工具和载体。而唯一跟传统数据库不太一样的是，Kubernetes 在拿到这些数据之后，并不以把这些数据持久化起来为目的，而是希望通过这些数据来驱动 Controller 执行某些操作，从而将整个系统的状态逐步调整为跟数据中声明的终态一致。

　　从一个“数据库”的角度重新审视 Kubernetes 设计：

　　　　数据模型 -  Kubernetes 的各种 API 对象与 CRD 机制

　　　　数据拦截校验和修改机制 - Kubernetes Admission Hook

　　　　数据驱动机制 - Kubernetes Controller/Operator

　　　　数据监听变更与索引机制 - Kubernetes 的 Informer 机制