我们kops在 AWS 中使用通过 1.9.3 管理的 k8s 1.9.3 和基于 Gossip 的 DNS，使用 weave cni 网络插件。
我正在对主 IG 进行滚动更新，以启用一些额外的准入控制器。（PodNodeSelector 和 PodTolerationRestriction）我在另外两个集群中做到了这一点，没有任何问题。当集群开始滚动第三个主实例（我们在 3 个主设置中运行我们的集群）时，它关闭了实例并尝试启动新的主实例，但新的主实例未能加入集群。在进一步研究和随后尝试滚动第三个主服务器以将其带入集群后，我发现第三个未能加入主服务器，继续尝试作为旧主服务器 IP 地址加入集群。即使它的IP地址是不同的。看着一个kubectl get nodes | grep master表明集群认为它是旧的 ip 地址并且它失败了，因为它不再是那个 ip。似乎由于某种原因，基于集群八卦的 DNS 没有收到有关新主服务器 IP 地址的通知。
这会导致问题，因为 kubernetes svc 中仍然有旧主服务器的 IP 地址，这导致任何指向该不存在的后端主服务器的 api 请求失败。它也给 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)
一件奇怪的事情是，如果我etcdctl cluster-health在可用的主 etcd 实例上运行，它们都会显示不健康的成员 ID，f90faf39a4c5d077但是当我查看 etcd-events 日志时，我发现它看到不健康的成员 ID 为3b7c45b923efd852. 所以似乎与etcd有些不一致。
由于我们在一个主节点关闭的三节点主节点设置中运行，我们不想重新启动任何其他主节点来尝试解决问题，因为我们害怕失去 etcd 集群上的仲裁。
我们使用weave2.3.0 作为我们的网络 CNI 提供程序。
注意到失败的主服务器没有创建weavecni 配置，并且工作主服务器上的文件没有正确更新新的主服务器 IP 地址。似乎由于某种原因没有得到更新。/etc/cni/net.d/10-weave.conf/etc/hostskube-proxy
kops运行1.9提供的默认 debian 8 (jessie) 映像。
我们如何才能让主服务器使用它的新 IP 地址正确更新 DNS？