新线上稳定运行了113天的k8s集群，突然大部分pod状态为Unkown,此时一首“凉凉”正在耳边回荡。

于是在次界面开始展开了地毯式的排查，首先是使用describe 命令去看这些pod的运行情况（虽然已经知道是unkown状态，但通过这个命令可以看到一些详情）。未果，并没有得到我想要的为什么会unkown，但这些unkown的服务有一个共同特点都是运行在一台node上，于是通过get node发现果然这个节点状态为Notready.

  所以在大量pod出现问题时，如果参数记得不是特别清楚的朋友，一定要养成习惯，多敲个get node 这类的常规命令，不会吃亏。当然如果我在一开始就加上了-o wide的话，可以清楚看到pod落在哪个节点上的话，第一时间应该就没清晰的定位到是节点出了问题。

  那么节点为什么突然出问题了呢？（oh,更可怕的是这个节点正巧是kubenetes控制管理节点- -）。继续通过日志开始定位问题

发现并没有这个节点（172.16.4.65）状态的上报。紧接着查这台服务器上的k8s node相关服务。发现kubelet、kubeproxy等各类应用都处于运行状态。但在kubelet日志里看到“timeout”字眼，于是通过date查看服务器的运行时间较其他节点快了2个小时。so,最终根源找到了，也就是由于系统时间不同步造成的节点不正常。

  改完系统时间后，迅速重启了kubelet、kubeproxy等相关服务。get node 看了看，很满意的点了点头（ready了），紧接着get pod 看了看服务

哟吼~服务也起来了，验证下服务就可以收工了；但乍一眼看去好像少了点什么。发现DNS服务没有起来，那好起呗

可最终给我的回显示“ErrImagePull”，老套路describe pod 。一眼就能看出来错误，提示镜像拉不下来。没道理啊，我的dns镜像是本地私有库的，怎么可能拉不下来。特意用docker images确认了下镜像的存在与否及yaml内image的定义。完全ok.但咋报这个不讲道理的错呢？只好登陆到harbor再去确认下，结果harbor有问题登不上去了，再一看果然服务有部分异常。

但为什么其他的pod都是正常running的呢，那是因为我这些yaml里唯独dns里没有设置镜像的拉取机制（本地没有时才拉），在不定义imagePullPolicy: IfNotPresent   #或者使用Nevers  时，默认是每次都会拽一次私有库里的镜像。于是乎，增加参数后apply这些yaml文件，先恢复线上服务。

最后解决一下harbor私有库的问题。这块儿，根据个人理解应该就是在重启node相关服务时，导致原本harbor使用的资源释放引起的，重启即恢复。

  所以整个过程其实挺吃鸡的，一个简单的时间不同步问题引发出这么多问题，是之前没有想到的，特此记录一下。