声明式API vs 命令时API
计算机系统是分层的，也就是下层做一些支持的工作，暴露接口给上层用。注意：语言的本质是一种接口。
计算机的最下层是CPU指令，其本质就是用“变量定义+顺序执行+分支判断+循环”所表达的逻辑过程。计算机应用的最上层是实现人类社会的某种功能。所以所有计算机编码的过程，就是用逻辑表达现实的过程。层与层之间定义的借口，越接近现实的表达就叫越“声明式”（declarative），越接近计算机的执行过程就叫越“命令式”（imperative）。注意这不是绝对的概念，而是相对的概念。
当接口越是在表达“要什么”，就是越声明式；越是在表达“要怎样”，就是越命令式。SQL就是在表达要什么（数据），而不是表达怎么弄出我要的数据，所以它就很“声明式”。C++就比C更声明式，因为面向对象本身就是一种声明式的体现。HTML也很声明式，它只描述我要一张什么样的表，并不表达怎么弄出一张表。
越是声明式，意味着下层要做更多的东西，或者说能力越强。也意味着效率的损失。越是命令式，意味着上层对下层有更多的操作空间，可以按照自己特定的需求要求下层按照某种方式来处理。
Kubernetes声明式API想要使用Kubernetes 的 API 对象，需要编写一个对应的 YAML 文件交给 Kubernetes，而声明式API，则为kubectl apply 命令。而先 kubectl create，再 replace 的操作，称为命令式配置文件操作，并不是声明式API。
kube-apiserver 在响应命令式请求（如kubectl replace）的时候， 一次只能处理一个写请求，否则会有产生冲突的可能；而对于声明式请求（如kubectl apply），一次能处理多个写操作，并且具备 Merge 能力。
声明式 API是 Kubernetes 项目编排能力“赖以生存”的核心所在：
首先，“声明式”就是提交一个定义好的API对象来声明所期望的状态是什么
其次，声明式API允许有多个API写端，以PATCH的方式对API对象进行修改，而无需关心本地原始YAML文件的内容
RESTful 使用POST来创建一个资源，使用PUT或者PATCH来更新一个资源 区别是： – PUT用来整体更新一个资源，所以请求中必须包含完整的资源信息。如果缺少部分信息，会导致这部分数据被更新为NULL。 – PATCH则是部分更新。仅更新提供的字段，请求中缺少的字段仍保持不变
最后，也是最重要的，有了上述两个能力，Kubernetees项目才可以基于对API对象的增、删、改、查在完全无需外界干预的情况下，完成对“实际状态”和“期望状态”的调谐(Reconcile)过程。
工作原理首先知道一下一个 API 对象在 Etcd 里的完整资源路径，是由：Group（API 组）、 Version（API 版本）和 Resource（API 资源类型）三个部分组成的，可以用如下图的树形结构表示出来：
API对象的组织方式是层层递进的，Kubernetes会对Group、Version和Resource进行解析，也就是层层匹配，得到相应的对象定义，如Cronjob（Pod、Node 等核心API对象不需要Group，直接匹配Version）。
把YAML 文件提交给 Kubernetes 之后，创建出 API 对象的流程：以创建 CronJob为例
发起创建CronJob的POST请求后，编写的YAML的信息就被提交给api-server
Api-server过滤这个请求，完成一些前置性的工作，比如授权、超时处理、审计等
请求进入mux和routes流程，mux和routees是api-server完成url和handler绑定的场所，api-server的Handler要做的事情就是按照层层匹配的过程，找到对应的CronJob类型定义
Api-server根据crontJob类型定义，使用用户提交的YAML文件里的字段，创建一个CrontJob对象
Api-server会进行一个convert工作，即把用户提交的YAML文件转换成一个叫做Super Version的对象，它正是该API资源类型所有版本的字段全集，这样用户提交的不同版本的YAML就都可以用这个Super Version对象来进行处理了
先后进行admission()和validation()操作
Admission Controller和Initializer都属于Admission的内容，Validation负责验证这个对象里的各个字段是否合法，这个被验证过的API对象，都保存在来api-server里一个叫做Registry的数据结构中，也就是说只要一个API对象的定义能在Registry里查到，他就是一个有效的Kubernetes API对象
把验证过的API对象转换成用户最初提交的版本，进行序列化操作，并调用Etcd的API把它保存起来
自定义API对象如果想要添加自定义API资源类型，建议使用CRD（ Custom Resource Definition），它允许用户在 Kubernetes 中添加一个跟 Pod、Node 类似的、新的 API 资源类型，即：自定义 API 资源。