“声明式 API”的核心原理
就是当用户向 Kubernetes 提交了一个 API 对象的描述之后，
Kubernetes 会负责为你保证整个集群里各项资源的状态，都与你的 API 对象描述的需求相一致。
更重要的是，这个保证是一项“无条件的”、“没有期限”的承诺：对于每个保存在 etcd 里的 API 对象，
Kubernetes 都通过启动一种叫做“[控制器模式]（Controller Pattern）的无限循环，不断检查，然后调谐，最后确保整个集群的状态与这个 API 对象的描述一致。
简单理解就是对象的声明与对象的创建相解耦，在普通程序中创建对象需要向操作系统申请资源，相似的，在容器云平台上创建对象，需要向k8s申请资源。
但k8s更进一步的是，你只需要提交一个申请单，然后由k8s系统完成对象的创建。
声明式API在istio中的应用
Istio的Pod Envoy代理，如何劫持pod内container流量并上报Mixer，通过Dynamic Admission Control
Dynamic Admission Control，也就是Initilizer，其实也是一个容器起来的Pod。他的功能就是将存在Etcd中的ConfigMap类型的关于Envoy容器的配置，和用户的Pod API对象通过Kubernetes的PATCH API做merge。
Configmap中data部分就是envoy容器的对应配置字段和volumes的配置。而Initializer的工作，就是把这个部分配置，自动添加到用户的POD API对象中。这就用到了Kubernetes的PATCH API，而这种patch操作，正是声明式API的主要能力。
声明式API的独特之处：
- 声明式API，就是说我们来提供一个好的API对象进行声明，我们期望的状态是啥样子的
- 其次，声明式API允许多个API对象写端，并在Kubernetes中支持以Patch的方式，对API对象进行修改以达到最终期望的实际状态，而无需关心最初的YAML文件的内容
- 基于以上两个能力特性（提供API明确的API对象来声明最终的期望状态+支持多个API对象声明并以PATCH的能力使控制器模型拿到的是最终的期望状态），Kubernetes能在无需外部干预的情况下，只要你给我明确的若干个API对象，我就能够给你无感调谐到你最终期望的状态
而在上面我们提到的Initializer的实现时，最核心的，还是Initializer里面那个image，自定义编程的编写过程，这是遵循“Kubernetes范式编程”，即
如何使用控制器模式，同 Kubernetes 里 API 对象的“增、删、改、查”进行协作，进而完成用户业务逻辑的编写过程。
所以，之后要学习的一个核心，就是如何通过“Kuberbetes范式编程”完成使用Kubernetes部署代码的Kubernetes用户，到使用Kubernetes编写代码的Kubernetes玩家的晋级之路。
