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