我们在 Kubernetes 上运行了一款第三方软件，该软件有三个主节点和三个工作节点。一段时间以来，我们遇到了一个奇怪的问题，即 Pod 似乎会随机出现连接同一网络内其他服务器（Kuberenetes 之外）的问题。我们与软件提供商进行了很多讨论，但老实说，我觉得他们的离岸人员一无所知，只是在发明与实际根本原因无关的变通方法，所以我们开始自己进一步调查。
总结我们自己的研究，问题似乎与单个主节点上的 kube-dns 服务不可靠有关。这一结论基于我们通过测试 ping 网络中的特定服务器而了解到的以下事实。在有问题的情况下，ping 的响应时间会有所不同，并且经常会完全失败。
事实 1：问题仅存在于我们的一个主节点上 很容易看出，只有在单个主服务器上运行的 pod 上，对服务器进行 ping 操作才不稳定，并且这可以在日志中看到。
事实 2：该问题仅存在于 Kubernetes pod 内部 主节点本身没有问题。
事实 3：该问题与主机解析有关 在有问题的 pod 中，使用 ip 进行 ping 工作正常，但使用主机名进行 ping 不稳定。
事实 4：问题不在于 coredns pod 通常，pod 的 /etc/resolv.conf 中都有 kube-dns 服务的 ip。我们已测试将其逐个替换为每个 coredns pod 的 ip，并且所有这些 ping 操作均能正常工作。只有在使用该服务作为名称服务器时才会不稳定。
事实 5：重新启动 Pod 和/或服务器似乎没有效果 我们已多次重新启动服务器和吊舱，但问题仍然存在。
通过这些观察，我试图更多地了解 Kubernetes 服务，但我很难发现任何错误。我认为服务配置问题应该会破坏所有主服务器，而不仅仅是一个主服务器，因此似乎可以排除这种可能性。kube-proxy 在每个节点上运行并处理服务，因此我检查了日志，但没有发现节点之间的任何差异。我还检查了 iptables-save 打印出的 kube-dns 服务的 ip，但它在节点之间是相同的。不知何故，我觉得如果服务出现特定于节点的问题，kube-proxy 应该是我的主要怀疑对象，但我无法弄清楚如何找到它的问题。
有人知道我应该在哪里继续挖掘有关主节点上发生的事情的更多信息吗？
答案1
通过设置以下系统参数解决了该问题：
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1
这些曾经被设置过，但是后来发生了一些事情，导致它们在集群中的不同服务器中处于各种状态。