docker和k8s常见报错

docker和k8s常见报错

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

2. 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使用的资源释放引起的，重启即恢复。

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