[问题重写，包含调查结果的详细信息。]
我正在运行一个 Google Container Engine 集群，该集群包含大约 100 个容器，每天执行大约 100,000 次 API 调用。一些 pod 开始出现 50% 的 DNS 解析失败。我深入研究了这个问题，它只发生在正在运行的节点上的 pod 上kube-dns。我还注意到，这只会在系统中的某个节点因内存不足而关闭之前发生。
后台救援作业正在附加到 Google API，然后将数据上传到 S3。当我看到失败的作业时，它们会失败并显示“名称解析暂时失败”。这种情况发生在“accounts.google.com”和“s3.amazonaws.com”上。
当我登录服务器并尝试使用 、 或 连接到这些（或其他主机）时host，nslookup它dig似乎工作正常。当我连接到 rails 控制台并运行队列中失败的相同代码时，我无法看到失败。然而，正如我所说，这些后台故障似乎是间歇性的（对于在运行 的节点上运行的工作程序，大约 50% 的时间kube-dns）。
到目前为止，我的临时修复是删除出现故障的 pod，并让 kubernetes 重新安排它们，并继续执行此操作，直到 kubernetes 将它们安排到未运行的节点kube-dns。
顺便说一句，删除故障节点并不能解决这个问题。它只是导致 kubernetes 将所有内容移至其他节点并转移了问题。
答案1
我通过升级到 Kubernetes 1.4 解决了这个问题。
1.4 版本包含几个修复程序，以防止 Kubernetes 在内存不足的情况下崩溃。我认为这有助于降低出现此问题的可能性，尽管我不确定核心问题是否已得到修复（除非问题是由于kube-dnsKubernetes 系统在节点出现 OOM 时不稳定而导致其中一个实例崩溃或无响应）。
答案2
对我来说，问题确实是 kube-dns 被调度到内存压力大的节点，导致它不断死机。我所做的是创建一个专用于 kube-system 服务的节点池。我通过 kubectl 编辑了部署，并为它们设置了一个节点选择器，这样它们就会始终被调度到专用节点池，不会与我的服务争夺资源。