编辑：从头开始重建新群集已解决了该问题。如果将流量切换回旧群集，问题仍然存在。
因此，现在看来我的Kubernetes集群已损坏，我不确定如何检测或诊断将来是否发生这种集群。可能：EC2网络适配器出现故障，一个节点或主节点上的服务出现故障，kube-proxy pod出现故障或其他kube-system问题...
如果对如何检测Pod和ClusterIP之间的间歇性拒绝连接的来源有任何建议，我很乐意找到根本问题。
我已经设置了nginx Kubernetes服务（在Kubernetes设置外部AWS LoadBalancer之后）。此Nginx服务通过ClusterIP代理多个入站服务。
它看起来像这样：
ELB ---> Nginx代理（PodA）--->内部服务（PodB）
我看到此（非常繁忙）服务之一拒绝了随机502连接。 Nginx错误日志如下所示：
2019/10/15 19:27:57 [error] 13#0: *71355 connect() failed (111: Connection refused) while connecting to upstream, client: X.X.X.X, server: api.acme.com, request: "GET /XYZ HTTP/1.1", upstream: "http://100.67.38.167:80/XYZ", host: "acme.com"
我每秒收到这502个错误中的10-15个（也许占请求总数的1％）。
我的内部服务（在clusterip 100.67.38.167上）似乎没有超出容量，但是我还是尝试扩展它。我把豆荚的数量增加了一倍。 502个错误的数量保持完全相同。
为了确定内部服务没有问题，我在其容器中添加了第二个容器，运行其自己的nginx代理。因此连接看起来像：
ELB ---> Nginx Proxy1（PodA）---> Nginx Proxy2（PodB）->内部服务（PodB）
第二个Nginx代理看到零错误。因此，所有错误似乎都在Nginx和ClusterIP地址之间。这是否意味着kube-proxy容量过大？
有什么方法可以确定这种情况吗？
注意：这是一个14个节点的群集，向该群集添加一个节点（并移动一些吊舱）也不会减少502。
我也尝试过：（1）为nginx proxy_pass添加和删除保持活动超时。 （2）通过ip地址或DNS解决内部服务（3）扩展kube-dns
有人知道会发生什么吗？