排查 kube-proxy导致 pod状态没有ready的问题

前言

承接上文,k8s测试环境部署coredns,通过kubectl get pod 可以看到coredns调度到了node节点,然后Pod也处于running状态,可是没有ready,排错并记录。

排查过程

1.通过kubectl get pod xx -o wide 查看有故障的Pod所在的node节点。

2.查看该node的kubelet日志,报错如下。

Failed to list *v1.Endpoints: Get https://10.0.0.1:443/api/v1/endpoints?limit=500&resourceVersion=0: dial tcp 10.0.0.1:443: connect: connection timed out

10.0.0.1 是我们集群的cluster_ip按道理讲node节点本机以及上面的pod都是可以通过cluster ip通信的,而原理就是基于kube-proxy代理工作的。但是现在显示无法通信,所以优先查看kube-proxy是否正常工作。结果发现该节点kube-proxy服务挂了,重启之后pod状态恢复正常。
总结
本篇文章依旧没什么营养和水准,唯一重要的一个知识点就是:cluster_ip 是由 service 服务创建出来的,隶属于service,而service服务的底层原理就是靠kube-proxy,报错就是显示无法与cluster_ip 进行通信,所以优先排查kube-proxy的问题。

点赞

发表评论

电子邮件地址不会被公开。 必填项已用*标注

Loading...