kubelet版本升级引起的容器重启机制与参考解决方案_操作系统_weixin

背景

k8s能够帮助我们的服务实现服务高可用，其提供的副本机制能够有效的保证运行实例的副本数，从而当某个实例异常后服务可以重新被自动唤起，但在我们的生产环境中，某些特殊的服务（如广告资金服务或计费服务）因服务重启期间而导致的业务中断，对业务请求的延时响应也是不可忽略的问题；而在kubelet的部分版本升级中，也可能会因版本的升级进而导致已经运行的容器服务发生重启；而在特殊的生产环境中类似的操作直接引起的服务重启是需要我们尽可能去规避的；

此篇内容即是对kubelet版本升级与container自动重启这一关联过程原因分析以及供参考方案的简单介绍。

环境基本信息：

操作系统： CentOS 7

kubelet当前版本：1.7.4

目标kubelet版本：1.9.1

现象

当前kubelet版本1.7.4中已持续运行一些容器服务，在对kubelet版本升级1.9.1后，所升级机器上已持续运行多天的container服务出现自动重启，重启之后继续提供服务

原因

因为container的自动重启发生在kubelet版本升级后，所以需要沿kubelet启动后的接口函数调用链进行定位，以确认container重启的根本原因.

总体调用链关系图：（右下角computePodActions() 函数中containerChanged（）函数即为决定container服务是否重启的判断逻辑）

高清无码图下载（https://pan.baidu.com/s/1dtMmbO）

链路跟踪过程：（整体kubelet调用关系比较复杂，后面仅针对问题的场景关键链路进行分析）

@kubernetes-1.9.1/cmd/kubelet/kubelet.go （@表示所处的源码文件，后面意义相同）

启动kubelet 的main()入口，风格上保持主入口代码最小化的设计风格

功能上仅是读取config初始化配置结构后调用真正的server中的Run()

@kubernetes-1.9.1/cmd/kubelet/app/server.go

判断启动模式，同时初始化证书相关和心跳等，以及进行健康度的检查

在RunKubelet中启动协程，进入真正的更新处理流程kubelet中的Run主体

@kubernetes-1.9.1/pkg/kubelet/kubelet.go

与场景现象相关的逻辑处理主入口，依次进行非依赖模块初始化initializeModules（“internal modules that do not require the container runtime to be up”），以及使用kubeClient与APIserver 同步node状态信息和本地网络状态及容器网络状态的检查

status、probe、pleg作用如下图示，可参照如上整体的调用链路简图

@kubernetes-1.9.1/pkg/kubelet/kubelet.go

syncLoop()，处理变化的主循环逻辑，监听3种来源的管道：file, apiserver, http；

只要有消息就会进行处理（监听的也是updates消息队列）

在syncLoopIteration迭代过程中，会根据不同的类型（config\pleg\sync…）进行相应的处理，处理是通过调用对应的Handle*（）函数实现的

在各自的处理函数中，针对所有的类别，本质都是调用dispatchWork，只是传入的参数分别为不同的类别而已；如果pod已是终止状态了，则需要同时调用statusManager.TerminatePod(pod) 来通知apiserver状态的更新；

在dispatchWork函数中，会调用具体执行单元worker中UpdatePod函数，此时已将变化封装的信息交由执行单元worker。

@kubernetes-1.9.1/pkg/kubelet/pod_workers.go

在UpdatePod中，主要是启动持续处理逻辑managePodLoop()，此函数只运行一次，执行后会启动一个循环来处理syncPodFn指向函数。如果希望退出循环则如下2个函数被调用时会中止这个循环：ForgetWorker（）与 ForgetNonExistingPodWorkers（）；控制这2个函数是否被调用则依赖于housekeepingCh 消息队列的处理。