[问题重写了调查结果的细节。]
我正在运行一个Google容器引擎群集，每天大约有100个容器执行大约10万次API调用。 一些豆荚开始得到50％的DNSparsing失败。 我深入研究了这一点，它只发生在运行kube-dns节点上的豆荚。 我还注意到，这只发生在系统中的节点由于内存不足而closures之前发生。
后台恢复作业将附加到Google API，然后将数据上传到S3。 当我看到失败的工作，他们失败，“名称parsing临时失败”。 这发生在“accounts.google.com”和“s3.amazonaws.com”。
当我login到服务器，并尝试连接到这些（或其他主机）与host ， nslookup ，或dig它似乎工作得很好。 当我连接到轨道控制台，并运行相同的代码，在队列中失败，我不能失败发生。 Howerver，正如我所说的，这些背景故障似乎是间歇性的（大约50％的时间运行在运行kube-dns节点上）。
到目前为止，我的临时修复是删除那些失败的豆荚，让kubernetes重新安排它们，并继续这样做，直到kubernetes将它们调度到一个不运行kube-dns的节点。
顺便说一句，删除失败的节点没有解决这个问题。 它只是让kubernetes把所有的东西都移动到其他节点上，并且移动了问题。
我通过升级到Kubernetes 1.4来解决这个问题。
1.4版本包含了几个修复程序，以防止在内存不足的情况下崩溃。 我认为这有助于降低这个问题的可能性，尽pipe我不相信核心问题是固定的（除非由于kubernetes系统不稳定而导致kube-dns实例之一崩溃或无响应）一个节点命中OOM）。