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

发布于 2019-05-15  11 次阅读


前言

承接上文,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的问题。


一个幽默,喜欢动漫,音乐,爱小动物,逐渐成为二次元肥宅的LINUX运维工程师,我会用心写博客,刚开始写的不太好。但是我会不断进步的!。就像我的博客下面写的。我宁愿做错,也不愿什么都不做 ps:好像是伊泽瑞尔说的,看来你游戏没少玩啊 23333333333333