容器编排 -- 控制器模型

控制器

kube-controller-manager是一系列控制器的集合,每一种控制器都以独有的方式负责某种编排功能

1
2
3
4
5
6
7
# cd kubernetes/pkg/controller

# ls -d */
apis/ cronjob/ endpoint/ history/ nodelifecycle/ replication/ storageversiongc/ util/
bootstrap/ daemon/ endpointslice/ job/ podautoscaler/ resourcequota/ testutil/ volume/
certificates/ deployment/ endpointslicemirroring/ namespace/ podgc/ serviceaccount/ ttl/
clusterroleaggregation/ disruption/ garbagecollector/ nodeipam/ replicaset/ statefulset/ ttlafterfinished/

控制循环

  1. X为待编排的对象,实际状态来源于Kubernetes集群,而期望状态一般来自于用户提交的YAML文件
  2. 别名:Reconcile、Reconcile Loop、Sync Loop、Control Loop
  3. 控制器对象本身,负责定义被管理对象的期望状态!!
    • 被控制对象的定义,来源于模板,如Deployment.template与标准的Pod对象的API定义一致,称为PodTemplate
1
2
3
4
5
6
7
8
9
for {
实际状态 := 获取集群中对象 X 的实际状态(Actual State)
期望状态 := 获取集群中对象 X 的期望状态(Desired State)
if 实际状态 == 期望状态{
什么都不做
} else {
执行编排动作,将实际状态调整为期望状态
}
}

Deployment

  1. Deployment控制器从Etcd中获取到所有携带app: nginx标签的Pod,统计它们的数量 – 实际状态
  2. Deployment对象的Replicas字段为期望状态
  3. Deployment控制器比较实际状态和期望状态,确定创建Pod还是删除已有的Pod
nginx-deployment.yaml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
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

所有的API Object的Metadata都有ownerReference字段,用于保存该API Object的拥有者(Owner)

参考资料

  1. 深入剖析Kubernetes
0%