Kubernetes节点失效删除Route记录后恢复

原创
2019/02/26 11:51
阅读数 341

kubernetes集群在调整网络后,其中一个 node 节点出现NotReady状态。可以ssh登录到该节点,kubectl get node无法访问集群的master节点,ping一下主服务器的地址也出现异常,如下:

supermap@podc04:/etc/keepalived$ ping 10.1.1.199
connect: 无效的参数

路由问题

检查一下路由表,如下:

supermap@podc04:/etc/keepalived$ route
内核 IP 路由表
目标            网关            子网掩码        标志  跃点   引用  使用 接口
default         router.asus.com 0.0.0.0         UG    300    0        0 bond0
10.1.1.0        0.0.0.0         255.255.255.0   U     300    0        0 bond0
10.1.1.199      0.0.0.0         255.255.255.255 UH    300    0        0 bond0
link-local      0.0.0.0         255.255.0.0     U     1000   0        0 bond0
172.17.0.0      0.0.0.0         255.255.0.0     U     0      0        0 docker0

发现一个奇怪的路由记录,集群的apiserver地址10.1.1.199路由记录。其它节点都是没有的。

删除该路由记录,如下:

sudo route del -net 10.1.1.199 netmask 255.255.255.255

再次检查路由表,如下:

supermap@podc04:/etc/keepalived$ route
内核 IP 路由表
目标            网关            子网掩码        标志  跃点   引用  使用 接口
default         router.asus.com 0.0.0.0         UG    300    0        0 bond0
10.1.1.0        0.0.0.0         255.255.255.0   U     300    0        0 bond0
link-local      0.0.0.0         255.255.0.0     U     1000   0        0 bond0
172.17.0.0      0.0.0.0         255.255.0.0     U     0      0        0 docker0
supermap@podc04:/etc/keepalived$ ping 10.1.1.199
PING 10.1.1.199 (10.1.1.199) 56(84) bytes of data.
64 bytes from 10.1.1.199: icmp_seq=1 ttl=64 time=0.232 ms
64 bytes from 10.1.1.199: icmp_seq=2 ttl=64 time=0.210 ms
64 bytes from 10.1.1.199: icmp_seq=3 ttl=64 time=0.187 ms
^Z

获取节点信息,通讯已经恢复,如下:

supermap@podc04:/etc/keepalived$ kubectl get node
NAME     STATUS   ROLES    AGE    VERSION
podc01   Ready    master   69d    v1.13.3
podc02   Ready    <none>   63d    v1.13.3
podc03   Ready    <none>   69d    v1.13.3
podc04   Ready    <none>   69d    v1.13.3
pods01   Ready    <none>   67d    v1.13.3
pods02   Ready    <none>   64d    v1.13.3
pods03   Ready    <none>   64d    v1.13.3
pods04   Ready    <none>   64d    v1.13.3
pods05   Ready    <none>   7d1h   v1.13.3

再次使用ping 10.1.1.199,完全正常。

只是不知道这个路由记录是怎么被加上的,因为运行正常,暂时不去管了。

CNI问题

其中一个节点的Nvidia镜像启动失败,提示“CNI故障”,检查flannel服务失败。

重新运行flannel安装程序后,恢复正常运行状态。如下:

kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml

Kube-proxy问题

其中一个节点的kube-proxy服务镜像运行失败,为后来新加的节点。

检查该节点的kube-proxy的images为1.13.1版本,该机不存在该版本的镜像。

  • 估计是添加时自动获取的版本为1.13.1,但在后来升级为1.13.4了(已经拉取到该机)。
  • 运行状态显示仍然使用的是1.13.1版本。

到Dashboard将kube-system中的服务集kube-proxy的images版本改为 1.13.4,该节点的kube-proxy服务恢复正常。

 

展开阅读全文
打赏
0
0 收藏
分享
加载中
更多评论
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部