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

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

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

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

源码为k8s v1.1.1稳定版本

3、Pod管理

前面的7篇文章都是为这篇文章做准备的。终于要进入到正题中，pod的管理

3.1 pod清单

1、参数

代码在k8s.iokubernetescmdkubeletapp中

结构体变量

 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.iokubernetespkgkubeletconfigfile.go

初始化了文件路径，nodename，还有一个updates的chan

然后开起了一个定期执行的run

从上图我们看到，检测文件目录，然后将pod信息通过chan发送出去

2、url方式

代码在k8s.iokubernetespkgkubeletconfighttp.go

初始化了url路径，header，还有定期时间间隔，最后也有一个chan

上图中构建了一个http Client，然后进行了http get请求

上图中，将获取到的信息解码，然后将解析出来的pod信息发送给chan

3、Api server方式

代码在k8s.iokubernetespkgkubeletconfigapiserver.go

这个比较简单，构建了一个listwatcher，然后将获取到的pod信息发送到chan

4、小结

通过三种方式进行pod信息的获取，也就是生产者，通过chan的方式法送给消费者。

3.2 pod管理

上一节中，我们已经知道了生产者，通过chan的方式发送给消费者

1、传递管道

在makePodSourceConfig中初始化了一个cfg

我们来看看cfg是什么

代码在k8s.iokubernetespkgkubeletconfigconfig.go

然后三种方式分别注册了不同的chan

传送给消费者的接口

注：这里的代码其实需要深入的话，需要去分析config.Mux，这个代码比较简单，这里篇幅关系就不做分析了。

2、构建与工作流程

构建

代码在k8s.iokubernetescmdkubeletapp中

podcfg就是上面构建的传送管道，最后启动了kubelet的Run函数

工作流程

代码在k8s.iokubernetespkgkubeletkubelet.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