【原创】k8s源码分析-----kubelet(8)pod管理
本文QQ空间链接:http://user.qzone.qq.com/29185807/blog/1460540474本文csdn博客链接:http://blog.csdn.net/screscent/article/details/51145382源码为k8s v1.1.1稳定版本 3、Pod管理前面的7篇文章都是为这篇文章做准备的。终于要进入到正题中,pod的管理 3.1...
本文QQ空间链接:http://user.qzone.qq.com/29185807/blog/1460540474
本文csdn博客链接:http://blog.csdn.net/screscent/article/details/51145382
源码为k8s v1.1.1稳定版本
3、Pod管理
前面的7篇文章都是为这篇文章做准备的。终于要进入到正题中,pod的管理
3.1 pod清单
1、参数
代码在k8s.io\kubernetes\cmd\kubelet\app中
结构体变量
type KubeletServer struct {
...
Config string
FileCheckFrequency time.Duration
ManifestURL string
ManifestURLHeader string
HTTPCheckFrequency time.Duration
...
}
默认参数
func NewKubeletServer() *KubeletServer {
return &KubeletServer{
...
FileCheckFrequency: 20 * time.Second,
HTTPCheckFrequency: 20 * time.Second,
...
}
}
flag参数
func (s *KubeletServer) AddFlags(fs *pflag.FlagSet) {
...
fs.StringVar(&s.Config, "config", s.Config, "Path to the config file or directory of files")
fs.DurationVar(&s.FileCheckFrequency, "file-check-frequency", s.FileCheckFrequency, "Duration between checking config files for new data")
fs.StringVar(&s.ManifestURL, "manifest-url", s.ManifestURL, "URL for accessing the container manifest")
fs.StringVar(&s.ManifestURLHeader, "manifest-url-header", s.ManifestURLHeader, "HTTP header to use when accessing the manifest URL, with the key separated from the value with a ':', as in 'key:value'")
fs.DurationVar(&s.HTTPCheckFrequency, "http-check-frequency", s.HTTPCheckFrequency, "Duration between checking http for new data")
...
}
Config:配置的文件路径或目录
FileCheckFrequency:文件定期检查文变化间隔
ManifestURL:获取pod定义的url地址
ManifestURLHeader:头部定义
HTTPCheckFrequency:url定期获取时间间隔
2、构建
我们看看生产者的构建
入口是在createAndInitKubelet中
继续makePodSourceConfig
这里构建了一个chan,并作为返回值返回给了上一级调用者。
然后生产方式一共有三种
1、文件方式
代码在k8s.io\kubernetes\pkg\kubelet\config\file.go
初始化了文件路径,nodename,还有一个updates的chan
然后开起了一个定期执行的run
从上图我们看到,检测文件目录,然后将pod信息通过chan发送出去
2、url方式
代码在k8s.io\kubernetes\pkg\kubelet\config\http.go
初始化了url路径,header,还有定期时间间隔,最后也有一个chan
上图中构建了一个http Client,然后进行了http get请求
上图中,将获取到的信息解码,然后将解析出来的pod信息发送给chan
3、Api server方式
代码在k8s.io\kubernetes\pkg\kubelet\config\apiserver.go
这个比较简单,构建了一个listwatcher,然后将获取到的pod信息发送到chan
4、小结
通过三种方式进行pod信息的获取,也就是生产者,通过chan的方式法送给消费者。
3.2 pod管理
上一节中,我们已经知道了生产者,通过chan的方式发送给消费者
1、传递管道
在makePodSourceConfig中初始化了一个cfg
我们来看看cfg是什么
代码在k8s.io\kubernetes\pkg\kubelet\config\config.go
然后三种方式分别注册了不同的chan
传送给消费者的接口
注:这里的代码其实需要深入的话,需要去分析config.Mux,这个代码比较简单,这里篇幅关系就不做分析了。
2、构建与工作流程
构建
代码在k8s.io\kubernetes\cmd\kubelet\app中
podcfg就是上面构建的传送管道,最后启动了kubelet的Run函数
工作流程
代码在k8s.io\kubernetes\pkg\kubelet\kubelet.go
run中的manager我们在之前的文章中基本都有介绍。最后进行syncLoop,其参数updates就是传送的管道
我们继续跟踪
其中的update被传递下来了,handler其实就是kubelet自身
再继续跟踪
终于到了处理地方。
从传送管道中,获取到pod信息,然后根据pod的类型,分别调用了不同的处理接口。
我们也说了handler其实就是kubelet自身
1、add
调用了func (kl *Kubelet) HandlePodAdditions(pods []*api.Pod) {
2、update
调用了func (kl *Kubelet) HandlePodUpdates(pods []*api.Pod) {
3、remove
调用了func (kl *Kubelet) HandlePodDeletions(pods []*api.Pod) {
调用了deletepod
通过chan把pod传送给了podkillingch
从上面可以看到,接收到需要kill的pod然后最终调用了killpod。而从下图,我们看到其实最终调用了containerrumtime的killpod,这个我们在上一篇文章中已经讲解过了。
4、set
暂时不支持
5、定时sync
调用了func (kl *Kubelet) HandlePodSyncs(pods []*api.Pod) {
我们看到add update sync都最后调用了dispatchWork。下一篇我们就来分析podwork
龚浩华
QQ 月牙寂 道长 29185807
2016年4月13日
(版权声明:本文为作者原创,如需转载请通知本人,并标明出处和作者。擅自转载的,保留追究其侵权的权利。)
如果你觉得本文对你有帮助,可以转到你的朋友圈,让更多人一起学习。
第一时间获取文章,可以关注本人公众号:月牙寂道长,也可以扫码关注
更多推荐
所有评论(0)