标签：

对付云计算系统，系统API实际上处于系统设计的统领职位地方，正如本文前面所说，Kubernetes集群系统每撑持一项新成果，引入一项新技术，必然会新引入对应的API东西，撑持对该成果的打点操纵，理解掌握的API，就比如抓住了Kubernetes系统的牛鼻子。Kubernetes系统API的设计有以下几条原则：

所有API应该是声明式的。正如前文所说，声明式的操纵，相对付命令式操纵，对付反复操纵的效果是不变的，这对付容易呈现数据丢掉或反复的漫衍式环境来说是很重要的。此外，声明式操纵更容易被用户使用，可以使系统向用户隐藏实现的细节，隐藏实现的细节的同时，也就保存了系统未来连续优化的可能性。别的，声明式的API，同时隐含了所有的API东西都是名词性质的，例如Service、Volume这些API都是名词，这些名词描述了用户所期望得到的一个方针漫衍式东西。

API东西是相互互补而且可组合的。这里面实际是鼓励API东西尽量实现面向东西设计时的要求，即“高内聚，松耦合”，对业务相关的观点有一个合适的分化，提高分化出来的东西的可重用性。事实上，Kubernetes这种漫衍式系统打点平台，也是一种业务系统，只不过它的业务就是调理和打点容器处事。

高层API以操纵意图为根本设计。如何能够设计好API，跟如何能用面向东西的要领设计好应用系统有相通的处所，高层设计必然是从业务出发，而不是过早的从技术实现出发。因此，针对Kubernetes的高层API设计，必然是以Kubernetes的业务为根本出发，也就是以系统调理打点容器的操纵意图为根本设计。

低层API按照高层API的控制需要设计。设计实现低层API的目的，是为了被高层API使用，考虑减少冗余、提高重用性的目的，低层API的设计也要以需求为根本，要尽量抵当受技术实现影响的诱惑。

尽量制止简单封装，不要有在外部API无法显式知道的内部隐藏的机制。简单的封装，实际没有供给新的成果，反而增加了对所封装API的依赖性。内部隐藏的机制也长短常倒霉于系统维护的设计方法，例如StatefulSet和ReplicaSet，原来就是两种Pod调集，那么Kubernetes就用差别API东西来界说它们，而不会说只用同一个ReplicaSet，内部通过特殊的算法再来区分这个ReplicaSet是有状态的还是无状态。

API操纵庞大度与东西数量成正比。这一条主要是从系统性能角度考虑，要保证整个系统跟着系统规模的扩大，性能不会迅速变慢到无法使用，那么最低的限定就是API的操纵庞大度不能赶过O(N)，N是东西的数量，否则系统就不具备程度伸缩性了。

API东西状态不能依赖于网络连接状态。由于众所周知，在漫衍式环境下，网络连接断开是经常产生的工作，因此要保证API东西状态能应对网络的不不变，API东西的状态就不能依赖于网络连接状态。

尽量制止让操纵机制依赖于全局状态，因为在漫衍式系统中要保证全局状态的同步长短常困难的。

控制逻辑应该只依赖于当前状态。这是为了保证漫衍式系统的不变可靠，对付经常呈现局部错误的漫衍式系统，如果控制逻辑只依赖当前状态，那么就非常容易将一个暂时呈现故障的系统恢复到正常状态，因为你只要将该系统重置到某个不变状态，就可以自信的知道系统的所有控制逻辑会开始凭据正常方法运行。

假设任何错误的可能，并做容错措置惩罚惩罚。在一个漫衍式系统中呈现局部和姑且错误是概略率事件。错误可能来自于物理系统故障，外部系统故障也可能来自于系统自身的代码错误，依靠本身实现的代码不会堕落来保证系统不变其实也是难以实现的，因此要设计对任何可能错误的容错措置惩罚惩罚。

尽量制止庞大状态机，控制逻辑不要依赖无法监控的内部状态。因为漫衍式系统各个子系统都是不能严格通过措施内部连结同步的，所以如果两个子系统的控制逻辑如果互相有影响，那么子系统就必然要能互相访谒到影响控制逻辑的状态，否则，就等同于系统里存在不确定的控制逻辑。

假设任何操纵都可能被任何操纵东西拒绝，甚至被错误解析。由于漫衍式系统的庞大性以及各子系统的相对独立性，差别子系统经常来自差此外开发团队，所以不能奢望任何操纵被另一个子系统以正确的方法措置惩罚惩罚，要保证呈现错误的时候，操纵级另外错误不会影响到系统不变性。

每个模块都可以在堕掉队自动恢复。由于漫衍式系统中无法保证系统各个模块是始终连接的，因此每个模块要有自我修复的能力，保证不会因为连接不到其他模块而自我瓦解。