kubernetes之故障排查和节点维护(二)

系列目录html

案例现场:node

测试环境集群原本正常,忽然间歇性地出现服务不能正常访问,过一下子刷新页面又能够正常访问了.进入到服务所在的pod查看输出日志并无发现异常.使用kubectl get node命令正好发现一个节点是NotReady状态git

为了方便观察,使用kubectl get node --watch来观测一段时间,发现k8s-node1节点不断的在Ready和NotReady状态之间切换(使用kubectl get node -o wide能够查看节点的ip信息).github

进入到出现问题的节点,使用命令journalctl -f -u kubelet来查看kubelet的日志信息,把错误日志截出来一段搜索一下,发现问题和这个问题基本上是同样的,发现这个问题的时间和github上issue提出的时间是在同一天,也没有看到解决办法.可是基本能肯定是由于集群中k8s-node1上的kubernetes版本不一致形成的(从上面截图上能够看到,这个节点的版本是1.14.1其它的都是1.13.1,是怎么升上来的不清楚,多是其它同事误操做升级致使的)docker

搜索kubernetes NotReady查看了一些解决经验,不少都是重启docker,重启kubectl等,而后都解决不了问题.因而尝试重置这个节点.bash

从集群中删除Node

因为这个节点上运行着服务,直接删除掉节点会致使服务不可用.咱们首先使用kubectl drain命令来驱逐这个节点上的全部podide

kubectl drain k8s-node1 --delete-local-data --force --ignore-daemonsets

以上命令中--ignore-daemonsets每每须要指定的,这是由于deamonset会忽略unschedulable标签(使用kubectl drain时会自动给节点打上不可调度标签),所以deamonset控制器控制的pod被删除后可能立刻又在此节点上启动起来,这样就会成为死循环.所以这里忽略daemonset.测试

实际在使用kubectl drain时候,命令行一直被阻塞,等了好久还在被阻塞.使用kubectl get pod命令查看pod状态时.其中一个叫做busybox的pod一直处于Terminating状态. 使用kubectl delete pod busybox一样没法删除它.这时候可使用命令kubectl delete pods busybox --grace-period=0 --force来强制立刻删除pod.命令行

这时候控制台阻塞状态结束.下面执行命令kubectl delete node k8s-node1来删除这个节点.而后咱们从新安装kubelet,kubeadm和kubectl日志

卸载旧版本

若是是经过yum方式安装的,能够经过yum list installed|grep xxx形式来找到已安装的组件,而后删除它们.删除之后从新安装.

这里之因此要从新安装是由于版本升级成了较为新的版本,若是版本是同样的,其它的不肯定因素致使节点不稳定,又找不到具体缘由,则能够经过kubeadm reset来重置安装.

重置命令并不会重置设置的iptables规则和IPVS若是想要重置iptables,则须要执行如下命令:

iptables -F && iptables -t nat -F && iptables -t mangle -F && iptables -X

若是想要重置IPVS,则须要执行如下命令:

ipvsadm -C

这里我可以基本肯定是因为版本不一致致使的,所以我并不重置iptables和IPVS,仅仅是重装组件.

从新加入集群

重置完成之后,咱们把删除掉的k8s-node1节点使用kubeadm join从新加入到集群中

若是忘记了主节点初始化时候生成的加入token,能够在主节点上执行kubeadm token create --print-join-command从新生成加入token,而后把生成的命令复制到要加入集群的节点上执行.

从新加入集群后,观察了一段时间,一直是Ready状态,感受终于稳定了,可是同事又反馈部署服务时出现如下错误

Failed create pod sandbox: rpc error: code = Unknown desc = failed to set up sandbox container "5159f7918d520aee74c5a08c8707f34b61bcf1c340bfc444125331034e1f57f6" network for pod "test-58f4789cb7-7nlk8": NetworkPlugin cni failed to set up pod "test-58f4789cb7-7nlk8_default" network: failed to set bridge addr: "cni0" already has an IP address different from 10.244.4.1/24

幸亏有伟大的互联网,经过搜索,找到如下解决方案

因为此次启动之后初次部署pod就失败了,所以此节点上尚未运行的服务,咱们不须要执行kubectl drain,能够直接把这个节点删除.而后执行如下命令

kubeadm reset
systemctl stop kubelet
systemctl stop docker
rm -rf /var/lib/cni/
rm -rf /var/lib/kubelet/*
rm -rf /etc/cni/
ifconfig cni0 down
ifconfig flannel.1 down
ifconfig docker0 down
ip link delete cni0
ip link delete flannel.1
systemctl start docker

完了之后从新加入集群.此次能够正常工做了.

相关文章
相关标签/搜索