【原创】k8s源码分析-----kubelet(4)imageManager

本文qq空间链接:http://user.qzone.qq.com/29185807/blog/1460429307

本文csdn博客链接:http://blog.csdn.net/screscent/article/details/51131261

源码为k8s v1.1.1稳定版本

2.3、imageManager

1、参数

代码在k8s.io\kubernetes\cmd\kubelet\app中

结构体变量

type KubeletServer struct {

...

ImageGCHighThresholdPercent    int

ImageGCLowThresholdPercent     int

CAdvisorPort                   uint

...

}

默认参数

func NewKubeletServer() *KubeletServer {

return &KubeletServer{

...

ImageGCHighThresholdPercent: 90,

ImageGCLowThresholdPercent:  80,

CAdvisorPort:                4194,

...

}

}

flag参数

func (s *KubeletServer) AddFlags(fs *pflag.FlagSet) {

...

fs.UintVar(&s.CAdvisorPort, "cadvisor-port", s.CAdvisorPort, "The port of the localhost cAdvisor
endpoint")

fs.IntVar(&s.ImageGCHighThresholdPercent, "image-gc-high-threshold", s.ImageGCHighThresholdPercent, "The percent of disk usage after which image garbage collection is always run. Default: 90%%")

fs.IntVar(&s.ImageGCLowThresholdPercent, "image-gc-low-threshold", s.ImageGCLowThresholdPercent, "The percent of disk usage before which image garbage collection is never run. Lowest disk usage
to garbage collect to. Default: 80%%")

...

}

ImageGCHighThresholdPercent,ImageGCLowThresholdPercent:两个参数分别为镜像占用磁盘空间的比例,当超过最大比例的时候,就开始清理释放磁盘,当低于时停止清理。

CAdvisorPort:本地cAdvisor endpoint端口。

2、传递参数

代码依旧在k8s.io\kubernetes\cmd\kubelet\app 中

在func (s *KubeletServer) KubeletConfig() (*KubeletConfig, error) {

...

imageGCPolicy := kubelet.ImageGCPolicy{

HighThresholdPercent: s.ImageGCHighThresholdPercent,

LowThresholdPercent:  s.ImageGCLowThresholdPercent,

}

...

return &KubeletConfig{

...

CAdvisorInterface:         nil, // launches background
processes, not set here

ImageGCPolicy:             imageGCPolicy,

...

}

}

其中注意一个CAdvisorInterface,这里初始化为nil

func (s *KubeletServer) Run(kcfg *KubeletConfig) error {

...

...

}

CAdvisorInterface是在,Run中配置的

构建了一个KubeletConfig

在func createAndInitKubelet(kc *KubeletConfig) (k KubeletBootstrap, pc *config.PodConfig, err error) {

...

k, err = kubelet.NewMainKubelet(

...

kc.CAdvisorInterface,

kc.ImageGCPolicy,

...

}

if err != nil {

return nil, nil, err

}

k.BirthCry()

k.StartGarbageCollection()

return k, pc, nil

}

小结:传递了三个参数ImageGCHighThresholdPercent,ImageGCLowThresholdPercent被封装在ImageGCPolicy中传递,CAdvisorInterface在Run中设置好了。

3、CAdvisorInterface

我们看看CAdvisorInterface都提供哪些操作

代码在k8s.io\kubernetes\pkg\kubelet\cadvisor

我们以linux平台为例子

我们这里不具体的去分析CAdvisorInterface,知道它是提供什么接口,做什么用的就好了。

4、imageManager工作流程

4.1、构建与服务启动

代码在k8s.io\kubernetes\pkg\kubelet\kubelet.go中

func NewMainKubelet(

以上就是构建imageManager

其中dockerclient在之前的的文章中已经分析过,可以看(【原创】k8s源码分析-----kubelet(2)dockerClient

上图将其传入kubelet中

然后有两个地方运行

1、在StartGarbageCollection中会启动一个定时任务

2、在func (kl *Kubelet) Run中会启动imageManager

4. 2 具体流程

代码在k8s.io\kubernetes\pkg\kubelet\image_manager.go

构建

看下结构体

其中主要的东西为imageRecord,用于保存image信息

4.2.1 start流程

启动了detectImages

上图中,通过dockerclient获取当前所有的images,和containers

将正在使用的images保存在imagesInUse

继续

流程就是,遍历所有的images。

1、放入当前存在的images队列中,currentImages

2、放入到imageRecords中。并判断是否正在使用,如果是,则刷新其最后使用时间

并且刷新其大小

最后遍历imageRecords,判断是否有不在当前images中的记录,有则删除掉

小结:

定时获取所有的images,然后扫描判断是否正在使用,并刷新最后使用时间和其大小。然后将记录中的,老记录删除掉

4.2.2 GarbageCollect流程

首先通过cadvisor获取磁盘信息

然后根据ImageGCPolicy来判断是否回收磁盘

我们这里跟踪磁盘回收

上图中,首先调用detectImages刷新imageRecords。

然后将images根据最后使用时间来进行排序

继续

将当前不在使用的images删除掉

5、总结

imageManager整个流程都很清晰

两个定时执行流程

1、定时刷新images的最后使用时间

2、定时获取磁盘大小,根据ImageGCPolicy来判断是否进行磁盘回收。主要回收最后使用时间before now的images

龚浩华

qq 月牙寂 29185807

2016年4月12日

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

时间: 2024-10-14 05:22:30

【原创】k8s源码分析-----kubelet(4)imageManager的相关文章

【原创】k8s源码分析-----kubelet(5)diskSpaceManager

本文qq空间链接:http://user.qzone.qq.com/29185807/blog/1460448039 本文csdn博客链接:http://blog.csdn.net/screscent/article/details/51134293 源码为k8s v1.1.1稳定版本 2.4.diskSpaceManager 1.参数 代码在k8s.io\kubernetes\cmd\kubelet\app中 结构体变量 type KubeletServer struct { ... LowD

【原创】k8s源码分析-----kubelet(3)ContainerGC

本人空间链接:http://user.qzone.qq.com/29185807/blog/1460080827 源码为k8s v1.1.1稳定版本 2.2 ContainerGC 1.参数 代码在k8s.io\kubernetes\cmd\kubelet\app中 结构体变量 type KubeletServer struct { ... MinimumGCAge                   time.Duration MaxContainerCount              in

【原创】k8s源码分析-----kubectl(2)Factory

本文QQ空间的链接:http://user.qzone.qq.com/29185807/blog/1461036130 本文csdn博文的链接:http://blog.csdn.net/screscent/article/details/51188790 源码为k8s v1.1.1 1.原因 首先讲讲为啥,我们要讲解Factory 代码在k8s.io\kubernetes\cmd\kubectl 先从main函数入口来说 main函数很简单,进来就直接构建了一个cmd,然后调用了Execute

【原创】k8s源码分析-----kubectl(3)主要框架

本文QQ空间的链接:http://user.qzone.qq.com/29185807/blog/1461123088 本文csdn博文的链接:http://blog.csdn.net/screscent/article/details/51199351 源码为k8s v1.1.1 1.整体流程 我们先整体的流程走一遍,不用太过于关心看不看的懂,先有个整体的流程概念,后续再一步一步分析 1.1 main 先从main开始 代码在k8s.io\kubernetes\cmd\kubectl\kube

【原创】k8s源码分析-----kube-proxy(2)ProxyServer

本文QQ空间链接:http://user.qzone.qq.com/29185807/blog/1460685179 本文csdn博客链接:http://blog.csdn.net/screscent/article/details/51159168 k8s源码为v1.1.1稳定版本 1.ProxyServer的构建与主流程 源码在k8s.io\kubernetes\cmd\kube-proxy main函数入口 这个就不再多说了,这种结构已经见多了 继续进入源码k8s.io\kubernete

《k8s 源码分析》- Custom Controller 之 Informer

Custom Controller 之 Informer 概述 架构概览 reflector - List & Watch API Server Reflector 对象 ListAndWatch watchHandler - add obj to delta fifo Informer (controller) - pop obj from delta fifo Controller processLoop Add obj to Indexer (Thread safe store) shar

【原创】k8s源码分析-----kubectl(1)api.RESTMapper

本文QQ空间链接:http://user.qzone.qq.com/29185807/blog/1460961715 本文csdn博文链接:http://blog.csdn.net/screscent/article/details/51179485 源码为k8s v1.1.1稳定版本 api. RESTMapper是kube-apiserver和kubectl的基础,在讲解kube-apiserver的时候,我们就有简单的讲解api. RESTMapper,但并没有系统的讲解.那么这一章,我们

【原创】k8s源码分析-----kube-scheduler

本文转自本人空间:http://user.qzone.qq.com/29185807/blog/1459831332 源码为k8s v1.1.1稳定版本 一.主要流程 1.main入口 源码在k8s.io/kubernetes/plugin/cmd/kube-scheduler 这种封装是k8s里面一贯的封装风格,就不再多说了 源码在k8s.io/kubernetes/plugin/cmd/kube-scheduler/app 继续往下 真正的入口 下面有个ratelimiter 在factor

【原创】k8s源码分析----apiserver之APIGroupVersion

本文中转载自本人空间:http://user.qzone.qq.com/29185807/blog/1458892866 前面3篇文章,主要是根据程序处理流程进行跳转分析.经过这些流程的跳转分析,拨开乌云终见日. 我们剥掉那些不重要的部分,直接进入主要框架. APIGroupVersion 在master中,api v1的初始化 生成了一个default的apigroupversion 下面进入到整个框架中最重要的数据结构 一.主要数据结构 1.mapper,其最重要的东西是里面的RESTMap