通过Kubernetes架构来重温一些经典理念

摘要

目前，Kubernetes有着云端操作系统的美誉，可见其在云计算平台上被开发人员的推崇程度。同时，Kubernetes也几乎成为了DevOps的标配。Kubernetes项目源自于Google Borg，可以说是集结了Borg设计思想的精华，并且吸收了Borg系统中的经验和教训。

除了利用kubernetes来高效的管理我们的集群，通过分析和学习Kubernetes的内部架构，也会让我们重温很多架构设计的经典理念并看到他们在实际中的合理运用，为我们的架构设计工作带来启迪。

Kubernetes架构概览

etcd：用于存储所有资源对象相关的数据，如：Node，Pod，Service，RC等。在kubernetes中，它只可以通过API Server來访问。

API Server：提供了資源对象定义，状态等信息的查询和修改的接口（Restful API）， 并且提供了数据变化的监听（watch）的机制。

Scheduler：将Pod分配到适合的node上，但scheduler并不实际执行这一调度，而只是通过API Server修改资源对象的定义。

Controller Manager/Controller：Controller manager通过一系列controller 插件来实现由当前状态向期望状态的转化（这些插件包括：Deployment Controller，StatefulSet Controller，Node Controller，Service Controller，Endpoint Controller，Namespace controller）。Controller通过监听API server的资源对象修改（Deployment，Service等）来进行一系列的对应操作（如：创建，删除对象），这些插件间是没有彼此调用的。另外，controller并不负责实际在Node上的资源创建及更新。

Kubelet：它可以说是真正的最终执行者。负责Node上的资源的管理和持续监控，Kubelet持续监听API server上关于Pod的变更，并且将这些变更同步到Node上，并且将Node上的资源的情况（如：container的运行情况）持续同步给API server。

 

值得重温的一些设计理念

1. 集群管理/任务调度的设计思路

思路：保存期望状态描述，持续监控集群当前状态， 其间不断调整当前状态使之趋近期望状态。

集群管理包括的如下主要任务：

- 实现当前状态向期望状态的变迁。

- 处理事件导致的期望状态的偏离。

完成以上任务可以通过状态机机制来实现。

 

2. 关注点分离（Concern points separation）

在kubernetes中将集群的管理工作分解到了各个不同的组件，甚至进一步地分解到更细粒度的插件上，如Controller Manager中不同的controller插件。

 

3. SRP（Single Responsibility Principle），单一责任原则

从上文中你可以发现，kubernetes中的每个组件都执行较为单一的功能。而且各组件间的耦合都基本是在数据层面的（资源对象的定义及状态），基本没有组件间的调用（除了都通过API Server获取及更新资源对象数据）。

 

4. 扩展点的插件化，保持插件的独立

犹如1）所提及的，通过插件化的方式来扩展功能点，并且插件间保持独立（没有插件之间的用），如：controller manager中不同的controller插件

 

5. 集中数据访问接口

kubernetes中的其他组件都要通过API Server来访问存储在etcd中资源对象数据。这样便于实现数据的访问控制，以及在并发环境下的数据的读写一致性控制。

 

6. 观察者模式解耦合

API Server提供的数据变化监听功能，这样的观察者模式（Observer pattern）实现了数据提供者及数据订阅者的解耦合。  

 

“在云端“是由SpotMax团队创建的技术讨论社区，旨在推动工程师重新思考传统的架构，探索适合于现代云平台的架构设计。

 

欢迎关注我的公众号