上一回,我们了解了pod的用法,知道了pod这个API对象的各个字段。接下来,看看编排这
个k8s中最核心的功能。
pod这个看似复杂的API对象,实际上就是对容器的进一步抽象和封装而已。换句话说,容器
镜像虽然好用,但是容器对于描述应用来说,还是太过简单了。所以,pod对象,其实就是
容器的升级版。它对容器进行了组合,添加了更多的属性和字段,使得k8s可以更轻松的操
作它。
现在,我们一起来回顾一下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指定的个数。 也就是说,如果携带app=nginx标签的pod大于2个,旧的pod
就会被删除;反之,就会有新的pod被创建。在k8s架构中,由kube-controller-manager组
件对各类控制器进行控制。
k8s项目的controller目录:
$ ls
deployment/ job/ podautoscaler/
cloud/ disruption/ namespace/
replicaset/ serviceaccount/ volume/
cronjob/ garbagecollector/ nodelifecycle/
replication/ statefulset/ daemon/
这个目录下面的每一个控制器,都以独有的方式负责某种编排功能。它们都遵循k8s项目中
的一个通用编排模式,即:控制循环(control loop)。这里可以使用go伪代码,看一看这
个控制循环:
for {
实际状态 := 获取集群中对象 X 的实际状态(Actual State)
期望状态 := 获取集群中对象 X 的期望状态(Desired State)
if 实际状态 == 期望状态{
什么都不做
} else {
执行编排动作,将实际状态调整为期望状态
}
}
实际状态来自于k8s集群本身:比如,kubelet通过心跳汇报的容器状态和节点状态,或者监
控系统中保存的应用监控数据,或者控制器主动收集的它自己感兴趣的信息,这些都是常见
的实际状态的来源。
期望状态,来自于用户提交的YAML文件:比如,Deployment对象中Replicas字段的值,很明
显,这些信息往往都保存在Etcd中。
deployment对控制器模型的实现:
1.Deployment控制器从头Etcd中获取到所有携带了app:nginx标签的pod,然后统计它们的数量,这就是实际状态;
2.Deployment对象的Replicas字段的值就是期望状态;
3.Deployment控制器将两个状态作比较,来确定删还是创建pod。
可以看出,一个k8s对象的主要编排逻辑,实际上是在第三步的对比阶段完成的。
像Deployment这种控制器的设计原理,就是用一种对象管理另一种对象的艺术。其中,控制
器对象本身,负责定义被管理对象的期望状态。比如,Deployment里的replicas=2这个字段
。而被控制对象的定义,则来自一个“模板”。比如Deployment里的template字段。
Deployment这个template字段里的内容,就是一个标准pod对象API的定义。而所有被这个
Deployment管理的pod实例,其实都是根据这个template字段的内容创建出来的。这个
template字段,被称作PodTemplate(Pod模板)。
像Deployment这样的一个控制器,实际上都是由上半部分的控制器定义(包括期望状态)和
下半部分的被控制对象的模板组成的。
这就是为什么,在所有API对象的Metadata里,都有一个字段叫做ownerReference,用于保
存当前这个API对象的拥有者(Owner)的信息。
上面那个YAML文件,它创建出来的pod的ownerReference就是nginx-deployment。
总结:
跟Deployment相似,这些控制循环最后的执行结果,那么创建、更新pod(或其他API对象、
资源),要么就是删除一些已经存在的pod(或者其他的API对象、资源)。这个实现思路,
正是k8s项目进行容器编排的核心原理。