说明:此文章为腾讯云机器自动从本人csdn博客搬迁过来。是本人授权操作。
申明:无本人授权,不可转载本文。如有转载,本人保留追究其法律责任的权利。
龚浩华,QQ 29185807,月牙寂 道长
第一时间获取文章,可以关注本人公众号 月牙寂道长 yueyajidaozhang
源码为k8s v1.1.1稳定版本
在3.2(也就是在k8s源码分析-----kubelet(8)pod管理)末尾,我们看到了,最终的处理都进入了podworkers中。
现在我们就来分析下podworkers
1、构建
代码在k8s.io\kubernetes\pkg\kubelet\kubelet.go中
// New creates a new Kubelet for use in main
func NewMainKubelet(
我们先看看其中的参数runtimeCache
代码在k8s.io\kubernetes\pkg\kubelet\container\runtime_cache.go中
从上图可以看出主要提供了两个接口函数GetPods和ForceUpdateIfOlder。在NewRuntimeCache的时候,提供的getter则是containerRuntime(这个之前的文章已经分析过)
结构体很简单
下面我们看看Getpods
从函数的注释就能够看的出来,其实runtimecache保存的就是当前pod的一个缓存,如果换成没有过期的话,则返回,如果过期了则重新更新
我们再看看
从上面的三个函数中我们就看到了getter.GetPods(其实这个就是containerRuntime)
现在看看podworkers
上面有很多的成员,其中最重要的就是podupdates,这个是针对不同的uid pod开启了一个通信管道。
2、工作
我们先看看kubelet的dispatchWork
其中就调用了podworks的Updatepod
我们继续跟踪
这一部分代码,其实就是对新的uid pod开启来一个chan 管道,真正的运行是在managePodLoop,稍后我们对其分析
isworking防止同一个pod重入。然后新的pod则将信息发送到管道。真的运行是在managePodLoop
我们再看下managePodLoop
这是一个死循环的,消费者,前面的updatepod是生产者,负责将pod通过管道发送到这个消费者。先从runtimecache中获取到pods,然后将调用syncpodFn(这个参数是在构建podworkers传入的,其实就是kubelet的syncPod),稍后在分析syncpod
这个消费者什么时候死亡呢?
我们看下面,下面的ForgetWorker和ForgetNonExistingPodWorkers。调用了removeworker,在这个函数中,关闭了管道,那么消费者也将随之消失
那么我们即将进入最后的步骤func (kl *Kubelet) syncPod
上面的是一个函数返回时的操作
上面中,开始真正的动作。killpod,当pod无法运行的时候
然后开始解析,挂载volume
等等一系列的操作完之后,调用了containerRuntime.synpod
这个就是我们之前分析的对docker封装的一个containerRuntime。
关于kubelet的所有分析都完成了。这一系列的文章只是对kubelet做了一个简单的分析,其中还有很多部分并没有完全的分析,不过我相信经过这些分析之后,对kubelet的主要工作应该已经有了一个大致的了解。
再说手kubelet的设计,这里面用的最多的是生产者和消费者模型,都是通过chan来进行通信,这个也是golang官方极力推荐的模式。再有就是,模块独立化,各个模块自我管理,这个与我在15年上海golang大会上所提到的AOP(Agent Oriented Programmig 面向智能体编程)的理念是一样的。