kubernetes-controller分析(四)-garbagecollector-v1.5.2
garbagecollector的功能主要有以下三点:
- 执行联级删除时(资源删除由apiserver完成),回收子资源;
- 执行非联级删除时,删除子资源的联级关系,再回收资源;
- 维护有资源之间的联级关系表。
为了更好地说明garbagecollector的机制,将以replicationController和Pods为例,在Kubernetes v1.5.2中,可以使用curl -XDELETE http://kubernetes:8080/api/v1/namespaces/default/replicationcontrollers/ubuntu?orphanDependents=false
执行联级删除,即删除replicationController时,后台会自动回收Pods。
具体见”finalizer机制”的分析。
garbagecollector
先来看下garbagecollector的定义,在/pkg/controller/garbagecollector/garbagecollector.go中:
|
|
其中,主要字段的含义为:
- dirtyQueue: 如果某object的owner不存在,则把该object加入到dirtyQueue进行检查,如果该object所有的owner都不存在,则把object删除;
- orphanQueue: 如果某object被标记为”orphan”,则把object的子资源的联级关系删除,然后再把object删除;
- monitors: 对某种资源变化的监控;
- propagator: 联级关系维护者。
NewGarbageCollector()
NewGarbageCollector()可以生成一个新的GarbageCollector。在GarbageCollector中,会对某类资源生成一个monitor对其变化进行监控。
|
|
Run()
Run()可以启动GarbageCollector。主要流程是:
- 启动monitors中的各monitor;
- 启动propagator.processEvent();
- 启动i个worker及i个orphanFinalizer;
|
|
monitorFor()
monitorFor()可以生成一个monitor:
monitor的定义如下:
|
|
monitorFor()方法如下:
|
|
可以看到,monitor中的store和controller就是对应informer返回的store和controller。controller的handler就是把事件加入到gc.propagator.eventQueue。现在,我们找到了eventQueue的生产者,即monitor。
worker()
worker()的作用就是消费dirtyQueue中的object,然后调用processItem()对object进行处理。
processItem()会检查object的owner,如果所有owner都不存在,则把object删除,以完成联级删除。
现在我们有了dirtyQueue的消费者,即worker。
|
|
orphanFinalizer()
orphanFinalizer()会消费orphanQueue中的object,然后调用ophanDependents()删除对应dependents的联级关系,最后调用removeOrphanFinalizer()移除该object的”orphan” finalizer,并使用Update()删除该object。关于Update()删除功能,可以看/registry/generic包中的相关代码。
orphanDependents()会把dependent中的ownerReference中对应的owner清除。orphanDependents()是如何用patch实现删除list中的一个值的,还有待详细研究。
|
|
removeOrphanFinalizer()
removeOrphanFinalizer()可以删除”orphan” finalizer,然后更新该object,注意更新操作在某些条件是删除。
|
|
接下来,我们来看下联级关系维护者-Propagator。
Propagator
Propagator维护结构体值间的联级关系,定义在/pkg/controller/garbagecollector/garbagecollector.go中:
|
|
结构体间的联级关系是通过node的概念来维护的,node定义如下:
|
|
可以看出,node的dependents字段表示该node的dependents;owners字段表示该node的owners。
insertNode()
insertNode()可以更新node及其联级关系。
insertNode()会调用addDependentToOwners()。addDependentToOwners()会检查该node的owner是否存在,如有不存在的情况,则把该node加入到dirtyQueue中供worker消费。所以dirtyQueue的生产者是insertNode(),消费者是worker()。insertNode()在
|
|
processEvent()
processEvent()从eventQueue中取得item并进行处理。处理的过程主要是维护联级关系及在适当的时候调用了insertNode和把object加入到orphanQueue中。所以,processEvent()是orphanQueue的生产者。
|
|
其他函数
最后来看下shouldOrphanDependents()。
shouldOrphanDependents()
shouldOrphanDependents()检查object是否有”orphan” finalizer,如果存在,则返回true。
|
|
总结
整个garbagecollector可以看成是三个channel的交互:
eventQueue:用于存放资源的事件。
生产者:monitor
消费者:Progator的processEvent()
orphanQueue:用于存放需要需要”orphan”操作(即解除联级关系)的object。
生产者:Progator的processEvent()
消费者:GarbageCollector的orphanFinalizer()
dirtyQueue: 用于存放需要owner检查(所有owner都不存在,则删除,即联级删除)的object。
生产者:Progator的insertNode(),在processEvent()中有调用
消费者:GarbageCollector的worker
那么,Pod是如何和ReplicationController关联起来的呢,在replication_controller上会把ReplicationController的信息作为ownerReference加入到Pod中。而整个GarbageCollector也就是通过object的ownerReference来维护整个联级关系表的。