oracle监听程序当前无法识别连接描述符_一次节点NotReady背后的Docker连接泄露分析...

屈骏，梯度科技核心研发工程师，负责日常集群节点和运行时相关的工作，以及containerd、docker、runc等运行时组件的定制开发和问题排查。

某一天客户反馈他们Kubernetes集群中的一个节点显示为NotReady状态，运行在该节点的应用实例也发生了漂移。节点NotReady在Kubernetes中是比较常见的一个场景，也是CKA(Certified Kubernetes Administrator)考试中的必考题，对于这个问题的排查需要我们对Kuberntes的节点管理有一定的了解。

如下图所示Kubernetes是一个Master-Slave架构，从节点通过自身的Kublet服务向Master节点的kube-apiserver定时发送心跳，来更新kube-apiserver中node lease或者node status数据，然后Master节点的kube-controller-manager会监听这些数据的变化，如果一个节点的心跳数据长时间没有更新，那么该节点就会被设置为NotReady，并且触发Pod的驱逐。

Kubelet的PLEG

由上可知节点的状态更新涉及多个组件，其中节点的异常、网络异常、ETCD数据库异常、控制组件kube-apiserver与kube-controller-manager异常都可能导致节点NotReady发生。首先，我们从心跳发送的源头，从节点的kubelet服务来开始排查，登录到对应节点，执行top命令查看主机负载，发现CPU负载并不高，内存空余也较多，因此可以判断并不是因为主机的负载高而导致消息发送失败。然后，查看kubelet的日志，发现kubelet服务虽然处于Running状态，但是日志中有PLEG相关的报错。

PLEG is not healthy: pleg was last seen active 4h3m5.30015447s ago;

kubelet报PLEG的状态为"not healthy"，看上去与我们节点的NotReady有很强的相关性，实际也确实如此，PLEG全称是"Pod Lifecycle Event Generator”，如下图kubelet设计图所示，此模块用于从容器运行时(CRI)接口获取运行中的容器信息，记录调度在本机上POD所运行的状态，并生成事件发送给kubelet的SyncLoop，Kubelet利用这些信息与Apiserver中POD的期望状态相对比，来控制节点上的容器创建与删除，是kubelet的一个核心模块。

kubelet会定时执行PLEG，一旦执行失败并且超过了PLEG执行超时时间后，kubelet则会认为PLEG not healthy，从而节点也变成NotReady状态。

Kubelet的容器运行时

由上可知节点的问题是出在PLEG的执行上，PLEG的执行是调用的容器运行时接口(CRI)，因此问题的分析需要继续深入到容器运行时，kubelet支持多种容器运行时，如Docker、Containerd、CRI-O、coreOS Rkt，由于客户的这套环境上线较早已经持续运行多年，kubelet配置的容器运行时是默认的Docker17版本，对于以Docker为CRI的PLEG异常场景，我们以往也处理过多次，通常可能是docker服务卡住或者系统负载太高docker服务响应慢导致PLEG不能及时完成，我们可以用一条命令模拟PLEG的调用来快速判断docker服务是否出现了异常。

time docker ps -a  | grep -v CONTAINER |  awk '{print $1}' | xargs docker inspect

当然也可以先查看docker的日志，通过jounalctl -u docker -f,我们看到了日志正在刷大量的"too many open files"的报错。