我有一个带有3个主机的堆叠控制平面的Kubernetes集群-因此每个主机都在本地运行自己的etcd实例。我正在尝试解决的问题是这样的：“如果一个主机死亡而无法重新启动，我该如何更换它？”
当前，当我尝试将替换母版添加到群集中时，在运行kubeadm join时出现以下错误：
[check-etcd] Checking that the etcd cluster is healthy
I0302 22:43:41.968068 9158 local.go:66] [etcd] Checking etcd cluster health
I0302 22:43:41.968089 9158 local.go:69] creating etcd client that connects to etcd pods
I0302 22:43:41.986715 9158 etcd.go:106] etcd endpoints read from pods: https://10.0.2.49:2379,https://10.0.225.90:2379,https://10.0.247.138:2379
error execution phase check-etcd: error syncing endpoints with etc: dial tcp 10.0.2.49:2379: connect: no route to host
10.0.2.49节点是死亡的节点。这些节点都在AWS AutoScaling组中运行，因此我无法控制地址。
我已使用kubectl drain和kubectl delete清空并删除了死主节点；并且我已经使用etcdctl来确保死节点不在成员列表中。
为什么它仍试图连接到该节点的etcd？
它仍在尝试连接到该成员，因为etcd在其商店中维护着一个成员列表-这就是它知道如何对仲裁决定进行投票的方式。我认为etcd并不是唯一的方式-大多数分布式键值存储都知道其成员列表
[The fine manual显示了如何删除死成员，但是it also warns显示了如何在删除不健康成员之前添加新成员。
还有一个项目etcdadm被设计用来消除关于etcd集群管理的一些粗糙边缘，但是我没有用它来说明它擅长与不擅长什么