docker和k8s常见报错

docker容器不断重启:
问题经过:
docker容器突然不断自动重启,查看日志发现提示io空间不足,但查看相关docker根目录空间充足,网上找了很多资料依旧不解,于是决定重启docker服务,重启后不再报错。

  1. docker无法删除容器:无法进入容器(容器不可操作了)
    报错显示grpc连接不可用:
    解决办法:
    由于是k8snode节点报的错:在该节点上
    执行如下命令:
    容器是es,es是比较吃内存的,当时问题出现的时候查了相关资料,先把docker服务重启了,当时没有问题了,结果第二天又是相同的问题,还是es集群抱错连接不可用,这让我很纳闷,我认真查了相关的资料,在docker官网找到了一篇有意义的文档,该文档说报此信息可能是因为内存不足导致oomkiller掉了占用内存最大的进程,我查看了本机的内存果然,128G的内存几乎都用光了,其中有五个java进程,占用了相对50G的内存,平均一个java占10G。。。es一个进程占了30G所以系统把es进程杀掉了但是docker并不知道,所以用docker ps看容器还在,但是不可操作了。我看了下java的配置信息,每个实例最大内存10G,怪不得这么耗内存,调整了每个java的最大内存,时候重启docker服务不再报错。

3.k8s报错:集群部署好之后用了一段时间coredns无法工作了,
查看coredns相关日志提示
列表失败,没有路由到主机。
解决方案:
首先试试手动删除coredns无效,
但是本地dns是ok的,
这问题很有可能是防火墙(iptables)规则错乱或者缓存导致的,可以依次执行以下命令进行解决:
systemctl stop kubelet
systemctl stop docker
iptables --flush
iptables -tnat --flush
systemctl start kubelet
systemctl start docker

重新添加供货方做节点提示token过期,token默认有效时间是24小时,如果集群创建完成后没有及时添加工作节点要重新生成token:

生成token
kubeadm token generate
#根据token输出添加命令
kubeadm token create --print-join-command --ttl=0

4.k8s集群节点时间偏差导致的集群部分pods状态为unkown问题:
新线上稳定运行了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使用的资源释放引起的,重启即恢复。

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

Logo

K8S/Kubernetes社区为您提供最前沿的新闻资讯和知识内容

更多推荐