我们在AWS中使用通过kops 1.9.3管理的k8s 1.9.3，并使用weave cni网络插件通过基于Gossip的DNS。
我正在对主IG进行滚动更新，以启用一些其他的准入控制器。 （PodNodeSelector和PodTolerationRestriction）我在其他两个集群中都做到了这一点，没有问题。当群集开始滚动第三个主机时（我们在3个主机设置中运行群集），它关闭了实例并尝试启动新的主机实例，但是新的主机实例无法加入群集。经过进一步的研究以及随后尝试将第三个主节点带入群集中，我发现第三个未能加入master的节点继续尝试将群集作为旧的master ip地址加入集群。即使是ip地址也有所不同。观察kubectl get nodes | grep master会表明群集认为它是旧的IP地址，但由于不再是该IP而失败。似乎出于某种原因，基于群集八卦的DNS并未收到有关新主服务器IP地址的通知。
这引起了问题，因为kubernetes svc仍然具有旧主服务器的ip地址，这导致定向到该不存在的后端主服务器的任何api请求都将失败。这也给etcd带来了问题，etcd一直试图通过旧的IP地址与它联系。很多这样的日志：
018-10-29 22:25:43.326966 W | etcdserver: failed to reach the peerURL(http://etcd-events-f.internal.kops-prod.k8s.local:2381) of member 3b7c45b923efd852 (Get http://etcd-events-f.internal.kops-prod.k8s.local:2381/version: dial tcp 10.34.6.51:2381: i/o timeout)
2018-10-29 22:25:43.327088 W | etcdserver: cannot get the version of member 3b7c45b923efd852 (Get http://etcd-events-f.internal.kops-prod.k8s.local:2381/version: dial tcp 10.34.6.51:2381: i/o timeout)
奇怪的是，如果我在可用的masters etcd实例上运行etcdctl cluster-health，它们都将不健康的成员id显示为f90faf39a4c5d077，但是当我查看etcd-events日志时，我看到了非健康会员ID为3b7c45b923efd852。因此似乎与etcd不一致。
由于我们在三节点主服务器中运行，而一个主服务器处于关闭状态，因此我们不希望重新启动任何其他主服务器来尝试解决此问题，因为我们担心在etcd群集上丢失仲裁。
我们使用weave 2.3.0作为我们的网络CNI提供程序。
在发生故障的主服务器上发现未创建weave cni config /etc/cni/net.d/10-weave.conf，并且工作主服务器上的/etc/hosts文件未正确更新为新的主服务器IP地址。似乎kube-proxy由于某种原因未获得更新。
运行kops 1.9随附的默认debian 8（jessie）图像。
我们如何让主服务器使用其新的IP地址正确更新DNS？
答案 0 :(得分：0)
我的同事发现该修补程序正在重新启动kube-dns和kube-dns-autoscaler pod。我们仍然不确定为什么他们无法使用新的主IP更新dns，但是在重新启动它们之后，将新的主添加到群集中就可以了。