本文共 1722 字，大约阅读时间需要 5 分钟。

 

本文QQ空间链接：

本文csdn博客链接：

源码为k8s v1.1.1稳定版本 

3.3 podworkers

       在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。

 

4、总结

       关于kubelet的所有分析都完成了。这一系列的文章只是对kubelet做了一个简单的分析，其中还有很多部分并没有完全的分析，不过我相信经过这些分析之后，对kubelet的主要工作应该已经有了一个大致的了解。

       再说手kubelet的设计，这里面用的最多的是生产者和消费者模型，都是通过chan来进行通信，这个也是golang官方极力推荐的模式。再有就是，模块独立化，各个模块自我管理，这个与我在15年上海golang大会上所提到的AOP（Agent Oriented Programmig 面向智能体编程）的理念是一样的。

      

 

龚浩华

QQ 月牙寂 道长 29185807

2016年4月14日

（版权声明：本文为作者原创，如需转载请通知本人，并标明出处和作者。擅自转载的，保留追究其侵权的权利。）

 

如果你觉得本文对你有帮助，可以转到你的朋友圈，让更多人一起学习。

第一时间获取文章，可以关注本人公众号：月牙寂道长，也可以扫码关注