新线上稳定运行了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使用的资源释放引起的,重启即恢复。
所以整个过程其实挺吃鸡的,一个简单的时间不同步问题引发出这么多问题,是之前没有想到的,特此记录一下。