问题描述
在使用Kubernetes时，遇到了一个问题：在他的5节点裸机集群上，使用Calico网络插件。这个集群在运行了22天后突然出现了通信中断的问题。经过调查，他发现服务到Pod的通信中断，但所有组件都正常运行，kubectl也没有问题。
在集群内部（组件A）如果尝试使用IP来访问另一个组件（bridge），是可以正常工作的：
$ curl -vvv http://10.4.130.184:9998
nslookup也可以解析服务的IP：
$ nslookup bridge
但是，使用服务名称进行通信的时候，大部分时间（60-70%）会卡住：
$ curl -vvv http://bridge:9998
当检查该服务的endpoints时，可以看到该pod的IP：
$ kubectl get ep -n 170 bridge
但是，使用服务名称进行通信时（包括curl和其他方法），都无法正常工作。这是服务的描述：
$ kubectl describe svc -n 170 bridge
这个问题不仅限于这个组件，对于所有组件都是如此。
用户已经尝试过重启CoreDNS（删除其pod），但问题仍然存在。他之前遇到过类似的问题，当时认为是与使用的Weavenet网络插件有关，所以他拆除了集群并使用Calico重新构建了集群，但现在他确定这与CNI无关，是其他问题导致的。
环境：
– Kubernetes版本：1.14.1（客户端），1.16.0（服务器）
– 云服务商或硬件配置：这是一个由5个节点组成的裸机集群，1个主节点和4个工作节点。所有节点都运行Ubuntu 18.04，并连接到同一个子网。
– 操作系统：Ubuntu 18.04.2 LTS (Bionic Beaver)
– 内核：Linux serflex-argus-1 4.15.0-55-generic #60-Ubuntu SMP Tue Jul 2 18:22:20 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
– 安装工具：Kubeadm
– 网络插件和版本：Calico “cniVersion”: “0.3.1”
用户还尝试过删除所有kube-proxy的pod，问题似乎得到了解决，但他仍然想知道是什么原因导致了这个问题。他检查了journalctl日志，但没有发现任何异常。iptables-save命令返回了大量的规则，但是当使用grep查找”hostnames”时，没有找到相关内容。
解决方案
请注意以下操作注意版本差异及修改前做好备份。
方案1
根据用户的描述，问题可能是由于kube-proxy未正确创建iptables规则导致的。以下是一些诊断Kubernetes问题的链接，您可以参考：
– Troubleshoot Applications
– Troubleshooting Kubernetes Networking Issues
– Troubleshooting GKE（适用于GKE，但仍然有用）
– Deploy Kubespy
这些链接提供了一些诊断Kubernetes问题的方法，包括使用iptables-save命令来检查是否由kube-proxy创建了规则。
方案2
如果问题仍然存在，您可以尝试重新部署kube-proxy。首先，删除kube-proxy的pod：
$ kubectl delete pods -n kube-system -l k8s-app=kube-proxy
然后，等待kube-proxy重新创建pod：
$ kubectl get pods -n kube-system -l k8s-app=kube-proxy
如果kube-proxy重新创建pod后问题仍然存在，您可能需要进一步检查kube-proxy的日志以查找更多信息。
方案3
如果以上解决方案都无法解决问题，您可以尝试重新启动整个集群。首先，备份您的数据和配置。然后，使用kubeadm重置集群：
$ kubeadm reset
接下来，重新初始化集群：
$ kubeadm init
最后，按照初始化时的指示将节点加入集群。
以上是一些可能的解决方案，希望能帮助您解决问题。如果问题仍然存在，请提供更多详细信息以便我们进一步帮助您。