k8s源码分析-----kubelet（9）podWorkers

说明：此文章为腾讯云机器自动从本人csdn博客搬迁过来。是本人授权操作。

申明：无本人授权，不可转载本文。如有转载，本人保留追究其法律责任的权利。

龚浩华，QQ 29185807，月牙寂 道长

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

源码为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 面向智能体编程）的理念是一样的。