Pod这个看似复杂的API对象,实际上就是对容器的进一步抽象和封装而已。“容器”镜像虽然好用,但是容器这样一个“沙盒”的概念,对于描述应用来说,还是太过简单了。所以,Pod对象,其实就是容器的升级版。它对容器进行了组合,添加了更多的属性和字段。使得Kubernetes可以更轻松地操作它。
Kubernetes操作这些Pod的逻辑,就是由控制器(Controller)完成的。
回顾nginx-deployment:
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
spec:
selector:
matchLabels:
app: nginx
replicas: 2
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.7.9
ports:
- containerPort: 80
这个Deployment定义的编排动作非常简单,即:确保携带了app=nginx标签的Pod的个数,永远等于spec.replicas指定的个数,即2个。这就意味着,如果在这个集群中,携带app=nginx标签的Pod的个数大于2的时候,就会有旧的Pod被删除;反之,就会有新的Pod被创建。
kube-controller-manager的组件,提供了k8s中一系列控制器的集合。可以查看一下Kubernetes项目的pkg/controller目录:
$ cd kubernetes/pkg/controller/
$ ls -d */
deployment/ job/ podautoscaler/
cloud/ disruption/ namespace/
replicaset/ serviceaccount/ volume/
cronjob/ garbagecollector/ nodelifecycle/
replication/ statefulset/ daemon/
...
这个目录下面的每一个控制器,都以独有的方式负责某种编排功能。Deployment是这些控制器中的一种。
这些控制器之所以被统一放在pkg/controller目录下,就是因为它们都遵循Kubernetes项目中的一个通用编排模式,即:控制循环(control loop)。
举例说明,有一种待编排的对象X,它有一个对应的控制器。那么就可以用一段Go语言风格的伪代码,描述这个控制循环:
for {
实际状态 := 获取集群中对象X的实际状态(Actual State)
期望状态 := 获取集群中对象X的期望状态(Desired State)
if 实际状态 == 期望状态{
什么都不做
} else {
执行编排动作,将实际状态调整为期望状态
}
}
这里,实际状态往往来自于Kubernetes集群本身。比如,kubelet通过心跳汇报的容器状态和节点状态,或者监控系统中保存的应用监控数据,或者控制器主动收集的它自己感兴趣的信息,这些都是常见的实际状态的来源。期望状态,一般来自于用户提交的YAML文件。比如,Deployment对象中Replicas字段的值,这些信息往往都保存在Etcd中。
以Deployment为例,简单描述一下它对控制器模型的实现:
可以看到,一个Kubernetes对象的主要编排逻辑,实际上是在第三步的“对比”阶段完成的。这个操作,通常被叫作调谐(Reconcile)。这个调谐的过程,则被称作“Reconcile Loop”(调谐循环)或者“Sync Loop”(同步循环)。调谐的最终结果,往往都是对被控制对象的某种写操作:增加Pod,删除已有的Pod,或者更新Pod的某个字段。这也是Kubernetes项目“面向API对象编程”的一个直观体现。
Deployment这种控制器的设计原理,体现在“用一种对象管理另一种对象”的“艺术”:
像Deployment定义的template字段,在Kubernetes项目中有一个专有的名字,叫作PodTemplate(Pod模板)。这个概念非常重要,因为大多数控制器,都会使用PodTemplate来统一定义它所要管理的Pod。更有意思的是,我们还会看到其他类型的对象模板,比如Volume的模板。
类似Deployment这样的一个控制器,实际上都是由上半部分的控制器定义(包括期望状态),加上下半部分的被控制对象的模板组成的。(仅从代码书写角度上看,区分并不明显)
因此,在所有API对象的Metadata里,都有一个字段叫作ownerReference,用于保存当前这个API对象的拥有者(Owner)的信息。
Kubernetes项目正是通过一个称作“控制器模式”(controller pattern)的设计方法,来统一地实现对各种不同的对象或者资源进行的编排操作。比如StatefulSet、DaemonSet等等,跟Deployment相似,这些控制循环最后的执行结果,要么就是创建、更新一些Pod(或者其他的API对象、资源),要么就是删除一些已经存在的Pod(或者其他的API对象、资源)。
但正是在这个统一的编排框架下,不同的控制器可以在具体执行过程中,设计不同的业务逻辑,从而达到不同的编排效果。这个实现思路,正是Kubernetes项目进行容器编排的核心原理。
此文章为3月Day16学习笔记,内容来源于极客时间《深入剖析Kubernetes》