继续上文未完的内容
3、控制器模式
在说Kubernetes的控制器模式之前,我们先看看软件架构中十分常见的MVC模式,即Model(模型)、View(视图)、Controller(控制器)。
* 模型(Model)
用于封装与应用程序的业务逻辑相关的数据以及对数据的处理方法。“ Model ”有对数据直接访问的权力,例如对数据库的访问。“Model”不依赖“View”和“Controller”,也就是说, Model 不关心它会被如何显示或是如何被操作。但是 Model 中数据的变化一般会通过一种刷新机制被公布。为了实现这种机制,那些用于监视此 Model 的 View 必须事先在此 Model 上注册,从而,View 可以了解在数据 Model 上发生的改变。(比如:观察者模式(软件设计模式))
* 视图(View)
能够实现数据有目的的显示(理论上,这不是必需的)。在 View 中一般没有程序上的逻辑。为了实现 View 上的刷新功能,View 需要访问它监视的数据模型(Model),因此应该事先在被它监视的数据那里注册。
* 控制器(Controller)
起到不同层面间的组织作用,用于控制应用程序的流程。它处理事件并作出响应。“事件”包括用户的行为和数据 Model 上的改变。
MVC 模式强调职责分离,即视图和数据模型的分离,并利用控制器来作为这两者的逻辑控制的中介,使之具有逻辑复用、松散耦合等优点。
数据模型(Model),它描述了“应用程序是什么”,用于封装和保存应用程序的数据,同时定义操控和处理该数据的逻辑和运算。而且,Model通常是可以复用的。
一个良好的MVC应用程序应该将所有重要的数据都封装到Model中,而应用程序在将持久化的数据(文件、数据库)加载到内存中时,也应该保存在Model中。
因为Model本身就代表着业务的特定数据对象,而在k8s里面,最典型的Model就是Pod。
视图(View),它是展现给用户的界面,这个不用多说。这个在k8s的应用不多,例如kubectl的信息输出或者Dashbord等,都可以算是一种View的应用。
控制器(Controller),它充当View和Model的媒介,将模型和视图绑定在一起,包括处理用户的配置输入,以此修改Model。反过来,View需要知道Model中数据的变化,也是通过Controller来完成。除此之外,Controller还可以为应用程序协调任务,管理其它对象的生命周期。在k8s里面,最典型的Controller就是Deployment。
在上文中我们提到了k8s拥有很多API对象,而其中一部分是属于控制器类型的特殊对象,我们可以进入k8s的代码目录:kubernetes/pkg/controller/*,查看所有控制机类型的API对象,包含:deployment\job\namespace\replicaset\cronjob\serviceaccount\volume 等等。
由于k8s的架构体系中,View不算是其核心的功能模块,我们这里重点关注Controller和Model的关系,代入k8s对象的话,我们以最典型的Deployment和Pod的关系,作为主要的研究对象。
我们回头看看文章连载前面的 Deployment 的yaml配置文件样例,可以划分为两大部分进行分析,买二手游戏平台配置文件的上半部分是属于控制器,下半部分是数据模型:
其实要深究起来,Deployment不是直接控制Pod,而是通过一个叫ReplicaSet的对象对Pod进行编排控制,所在在Pod的matadata里面会显示其 owerReference是ReplicaSet。
也就是说在控制器对象的范围内,也会进行功能的分层,因为不同的控制机之间,存在着可以复用的功能逻辑,比如对Pod的副本数控制。
那么这时候可以抽象出一层例如像ReplicaSet的对象,进行对Pod的副本控制,除了Deployment以外,也存在其他的控制器对象可以利用ReplicaSet进行对Model的控制。
基于这样的分层思想,我们在生产环境场景的所遇到的需求,可以将其控制逻辑都在控制器这一层进行实现。
比如无状态的Deployment和有状态的StatefuleSet,或者每个Node只有一个DeamonSet,尽管各自实现的功能各不相同,但是它们都是可以共用同一套Pod对象的逻辑,而差异的部分都封装在控制器层。