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

2019独角兽企业重金招聘Python工程师标准>>>

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服务恢复正常。

 

转载于:https://my.oschina.net/u/2306127/blog/3014906