Kubernetes-设计理念（三）

Kubernetes设计理念与分布式系统

分析和理解Kubernetes的设计理念可以使我们更深入的了解Kubernetes系统，更好的利用它管理分布式部署的云原生应用，另一方面也可以让我们借鉴其在分布式系统设计方面的经验。

API设计原则

对于云计算系统，系统API实际上处于系统设计的统领地位，正如本文前面所说，k8s集群系统每支持一项新功能，引入一项新技术，一定会引入对应的API对象，支持对该功能的管理操作，理解掌握的API，就好比抓住了k8s系统的关键。k8s系统API的设计有以下几条原则：

• 所有API应该是声明式的。声明式的操作，相对命令式操作，对于重复操作的效果是稳定的，这对于容易出现数据丢失或重复的分布式环境来说是很重要的。另外，声明式操作更容易被用户使用，可以使系统向用户隐藏实现细节，隐藏实现细节的同时也就保留了 系统未来持续优化的可能性。此外，声明式API同时隐含了所有的API对象都是名词性质的，例如Service、Volume这些API名词描述了用户所期望得到的一个目标分布式对象。
• API对象是彼此互补而且可组合的。这里面实际是鼓励API对象尽量实现面向对象设计时的要求，即“高内聚，松耦合”，对业务相关的概念有一个合适的分解，提高分解出来的对象的可重用性。事实上，k8s这种分布式系统管理平台也是一种业务系统，只不过它的业务就是调度和管理容器服务。
• 高层API以操作意图为基础设计。如何能够设计好API，跟如何能用面向对象的方法设计好应用系统有想通的地方，高层设计一定从业务出发，而不是过早的从技术实现出发。因此，针对k8s的高层API设计，一定是以k8s的业务为基础出发，也就是提供调度管理容器的操作意图为设计基础的。
• 底层API根据高层API的控制需求设计。设计实现底层API的目的是为了被高层API使用，考虑减少冗余、提高重用性的目的，底层API的设计也要以需求为基础，要尽量抵抗受技术实现影响的诱惑。
• 尽量避免简单封装、不要在外部API无法显示知道的内部隐藏的机制。简单的封装，实际没有提供新功能，反而增加了对所封装的API的依赖性。内部隐藏的机制也是非常不利于系统维护的设计方式，例如PetSet和ReplicaSet，本来就是两种Pod集合，那么K8s就用不同的API对象来定义他们，而不会说只用一个ReplicaSet，内部通过特殊的算法再来区分这个ReplicaSet是有状态还是无状态的。
• API操作复杂度与对象数量成正比。这一条主要是从系统的性能角度考虑，要保证整个系统随着系统规模的扩大，性能不会迅速变慢到无法使用，那么最低的限定就是API的操作复杂度不能超过O(N),N是对象数量，否则系统就不具备水平伸缩性了。
• API对象状态不能依赖于网络连接状态。由于众所周知，在分布式环境下，网络连接断开是经常发生的事情，因此要保证API对象状态能应对网络的不稳定，PAI对象的状态就不能依赖于网络连接状态。
• 尽量避免让操作机制依赖于全局状态，因为分布式系统中药保证全局状态的同步是非常困难的。

控制机制设计原则

Kubernetes的核心技术概念和API对象

Pod

复制控制器（Replication Controller，RC）

副本集（ReplicaSet，RS）

部署（Deployment）

服务（Service）

任务（Job）

后台支撑服务集（DaemonSet）

有状态服务集（PetSet）

集群联邦（Federation）

存储卷（Volume）

持久存储卷（Persistent Volume，PV）和持久存储卷声明（Persistent Volume Claim，PVC）

节点（Node）

秘钥对象（Secret）

用户账户（User Account）和服务账户（Service Account）

命名空间（Namespace）

RBAC访问授权