<p>kubeadm重置成功，但是此节点ip仍在kubeadm-config configmap中</p>

cc @fabriziopandini

理想情况下，将有一种“刷新” ClusterStatus的方法。 我们运行带有混乱测试的集群，完全有可能终止控制平面节点而不会发出警告，也没有机会运行kubeadm reset 。 理想情况下，将有一种干净的方法来显式更新ClusterStatus，以删除我们知道不再存在于集群中的控制平面节点。 这是在运行kubeadm join --control-plane ...或内置之前完成的事情吗？

一些评论在这里：

kubeadm-config ConfigMap删除此节点ip。

@pytimer我知道在群集状态下保留节点api地址并不理想，但是我有兴趣了解这种“缺乏清理”是否会产生问题。 您是否尝试过再次加入同一控制平面？ 您是否尝试加入另一个控制平面？ 我不希望出现问题，但对此点得到确认将是不胜感激的。

我还有一个问题，为什么kubeadm reset不能直接从集群中删除该节点？ 而是运行kubectl delete节点手动。

@luxas可能有点历史背景，可以在这里提供帮助。
我的猜测是该节点无权删除自己（但这适用于工作节点，而不适用于控制平面节点...）

理想情况下，将有一种“刷新” ClusterStatus的方法/将有一种干净的方法来显式更新ClusterStatus

@danbeaulieu很好。 具有明确的命令来同步集群状态和/或在执行kubeadm时强制执行自动同步是一个好主意。
但是，由于kubeadm没有任何连续运行的控制循环，因此我认为总有可能使ClusterStatus不同步。
这应该不成问题，或者更多地是专门为不再存在的节点设置节点ip（缺少清理）应该不是问题。
相反，如果存在一个节点，并且ClusterStatus中缺少相应的节点ip（错误的初始化），则可能会产生例如更新的问题。

您能否报告上述假设是否通过您的混乱测试得到了证实？ 任何反馈都会很感激。

@fabriziopandini我加入了同一控制平面节点，但失败了。

我的加入步骤：

第二控制平面节点ip是192.168.46.212 。

• 从etcd集群中删除192.168.46.212节点的etcd成员。
• kubectl delete node k8s-212
• 此控制平面节点上的kubeadm reset -f 。
• 再次运行kubeadm join --experimental-control-plane --config kubeadm.yaml -v 5 。

kubeadm连接日志：

...
[etcd] Checking Etcd cluster health
I1207 17:57:18.109993    8541 local.go:66] creating etcd client that connects to etcd pods
I1207 17:57:18.110000    8541 etcd.go:134] checking etcd manifest
I1207 17:57:18.119797    8541 etcd.go:181] etcd endpoints read from pods: https://192.168.46.211:2379,https://192.168.46.212:2379
I1207 17:57:18.131111    8541 etcd.go:221] etcd endpoints read from etcd: https://192.168.46.211:2379
etcd cluster is not healthy: context deadline exceeded

我看到了kubeadm代码，并且我认为此问题可能是由kubeadm-config ConfigMap中剩余的192.168.46.212引起的。

当加入控制平面节点时，Kubeadm从kubeadm-config ConfigMap获取api端点，而etcd端点与api端点相同。 但是912.168.46.212控制平面节点已被删除并且尚未加入，因此请检查etcd集群的运行状况是否错误。

当我从kubeadm-config ConfigMap中删除192.168.46.212 api端点，并再次加入该控制平面节点时，它加入成功。

@pytimer谢谢！
应该对此进行调查。 已经有一种逻辑试图将etcd端点的假定列表与真实的etcd列表端点进行同步，但是似乎有些东西无法正常工作

是的，这似乎是一个错误。 我们有一个3节点控制平面ASG。 如果我们终止实例，则会根据ASG规则创建一个新实例。 在这段时间内，终止的节点在etcd的成员列表中被列为不正常。 当新实例出现时，在运行kubeadm join... ，它将从etcd中删除不健康的成员。 到我们运行kubeadm join... ，etcd群集已正常运行，根据etcd有2个节点。 但是kubeadm使用ClusterStatus作为其事实来源，该来源仍然列出了旧实例。

在执行etcd成员资格管理后，对我们来说，解决方法就是使用集群的真实性更新kubeadm-config ConfigMap，然后运行kubeadm join... 。

理想情况下， kubeadm join...将使用etcd作为真理的来源，并相应地更新kubeadm-config ConfigMap。

@fabianofranz我也许找到了此问题的原因。

将etcd端点与真实的etcd端点列表同步时，同步成功。 但是，将实际的etcd端点分配给etcd客户端Endpoints ，此客户端变量不是指针，因此，当其他代码使用该客户端时，该客户端端点仍然是旧的端点，而不是同步后的真实端点。

我在我的fork库中解决了这个问题，您可以检查此PR https://github.com/pytimer/kubernetes/commit/0cdf6cad87a317be5326f868bafe4faecc80f033。 我测试了join the same control-plane node用户案例，它成功加入了。

@pytimer看起来很棒！ 好眼力！
您能发送公关吗？ 海事组织这将有资格进行樱桃采摘。

@ neolit123 @timothysc ^^^

@fabianofranz第一个PR是错误的，我忘记了确认CLA。

您可以检查此PR https://github.com/kubernetes/kubernetes/pull/71945 。 如果有任何问题，希望您指出。

@fabriziopandini我加入了同一控制平面节点，但失败了。

我的加入步骤：

第二控制平面节点ip是192.168.46.212 。

• 从etcd集群中删除192.168.46.212节点的etcd成员。
• kubectl delete node k8s-212
• 此控制平面节点上的kubeadm reset -f 。
• 再次运行kubeadm join --experimental-control-plane --config kubeadm.yaml -v 5 。

kubeadm连接日志：

...
[etcd] Checking Etcd cluster health
I1207 17:57:18.109993    8541 local.go:66] creating etcd client that connects to etcd pods
I1207 17:57:18.110000    8541 etcd.go:134] checking etcd manifest
I1207 17:57:18.119797    8541 etcd.go:181] etcd endpoints read from pods: https://192.168.46.211:2379,https://192.168.46.212:2379
I1207 17:57:18.131111    8541 etcd.go:221] etcd endpoints read from etcd: https://192.168.46.211:2379
etcd cluster is not healthy: context deadline exceeded

我看到了kubeadm代码，并且我认为此问题可能是由kubeadm-config ConfigMap中剩余的192.168.46.212引起的。

当加入控制平面节点时，Kubeadm从kubeadm-config ConfigMap获取api端点，而etcd端点与api端点相同。 但是912.168.46.212控制平面节点已被删除并且尚未加入，因此请检查etcd集群的运行状况是否错误。

当我从kubeadm-config ConfigMap中删除192.168.46.212 api端点，并再次加入该控制平面节点时，它加入成功。

在kubeadm版本1.13.2中出现了相同的错误，我尝试手动删除该节点并更新kubeadm-config，它不起作用，其余的etcd节点仍尝试连接该删除的节点

当我从kubeadm-config ConfigMap中删除192.168.46.212 api端点，并再次加入此控制平面节点时，它加入成功。

@pytimer您能否详细说明如何手动删除旧的api服务器？

我正在运行1.13.3; 通过以下方式手动删除旧服务器：

1. kubectl -n kube-system get cm kubeadm-config -o yaml > /tmp/conf.yml
2. manually edit /tmp/conf.yml to remove the old server
3. kubectl -n kube-system apply -f /tmp/conf.yml 

由于以下错误，我仍然无法加入集群：

[etcd] Checking etcd cluster health
etcd cluster is not healthy: context deadline exceeded

然后，我杀死了api荚和etcd荚（每个2个）。

它们被重新创建，但是在尝试连接其他节点时我仍然遇到相同的错误。

在1.13.3中有相同的问题（HA群集设置：3个主节点+ 3个工作器）。 仅在执行以下步骤后，才能成功替换主节点：

从集群中删除节点

kubectl delete node master03

下载etcdctl（例如，在master01上）

mkdir /opt/tools && cd /opt/tools
wget https://github.com/etcd-io/etcd/releases/download/v3.3.12/etcd-v3.3.12-linux-arm64.tar.gz
tar xfz etcd-v3.3.12-linux-arm64.tar.gz

从etcd删除主节点

cd /opt/tools/etcd-v3.3.12-linux-arm64
./etcdctl --endpoints https://192.168.0.11:2379 --ca-file /etc/kubernetes/pki/etcd/ca.crt --cert-file /etc/kubernetes/pki/etcd/server.crt --key-file /etc/kubernetes/pki/etcd/server.key member list
./etcdctl --endpoints https://192.168.0.11:2379 --ca-file /etc/kubernetes/pki/etcd/ca.crt --cert-file /etc/kubernetes/pki/etcd/server.crt --key-file /etc/kubernetes/pki/etcd/server.key member remove 28a9dabfcfbca673

从kubeadm-config中删除

kubectl -n kube-system get cm kubeadm-config -o yaml > /tmp/conf.yml
manually edit /tmp/conf.yml to remove the old server
kubectl -n kube-system apply -f /tmp/conf.yml

@zhangyelong现在，kubeadm reset无法删除etcd成员，因此您发现etcd群集仍连接已删除的etcd节点。 您应该立即使用etcdctl删除etcd成员。

您可以看到，我发送了一个PR来实现在重置时删除etcd节点。 https://github.com/kubernetes/kubernetes/pull/74112

@lvangool您可以按照@Halytskyi的步骤进行操作。 PR： https :

重置后从etcd集群中删除etcd成员，您可以看到kubernetes / kubernetes＃74112。

这似乎仍然是1.13.4中的错误。

我们仍然需要手动更新kubeadm配置图ala https://github.com/kubernetes/kubeadm/issues/1300#issuecomment -463374200

是不是在这种情况下修复
kubernetes / kubernetes＃71945会使用etcd集群成员身份作为集群成员的真实来源吗？ 如果没有，那公关到底能解决什么问题？

有趣的是，它偶尔会起作用，因为在golang范围内，诸如ClusterStatus之类的地图是不确定的。 因此，如果它找到的第一个端点来自不再存在的旧端点，那么事情将会失败。 如果找到健康的端点，它将从etcd Sync更新ClusterStatus ...

我相信，这的根本原因是etcd clientv3中的错误，该错误导致客户端在第一个失败的情况下不重试其他端点https://github.com/etcd-io/etcd/issues/9949。

请使用以下问题跟踪重置改进

• https://github.com/kubernetes/kubeadm/issues/1312从ClusterStatus（ @Klaven https://github.com/kubernetes/kubernetes/pull/72886）删除控制平面节点
• https://github.com/kubernetes/kubeadm/issues/1211从etcd集群中删除etcd成员（ @pytimer https://github.com/kubernetes/kubernetes/pull/74112）

@fabriziopandini这里至少还有一个与kubeadm reset无关的问题。

如果节点失败而没有机会执行kubeadm重置（实例终止，硬件故障等）
群集处于以下状态：ClusterStatus.apiEndpoints仍列出群集中不再存在的节点。 这需要在执行kubeadm join之前读取，编辑和更新配置映射的解决方法。 Kubeadm可能有2个选择：

1）如果拨号失败，请执行etcd客户端重试
2）等待修复go-grpc错误，然后将其修复到etcd客户端

此问题可能是一个很好的问题，可用于跟踪这些选项中的任何一个。

如果节点失败而没有机会执行kubeadm重置（实例终止，硬件故障等）
群集处于以下状态：ClusterStatus.apiEndpoints仍列出群集中不再存在的节点。 这需要在执行kubeadm join之前读取，编辑和更新配置映射的解决方法。

没错，无需调用reset，您将必须手动更新ClusterStatus。
我们没有执行该操作的命令。 如果您认为此功能是kubeadm应该支持的功能，请另外提交一张票证。

刚刚在1.14.1上经历了这一天

运行我的一个主节点的实例发生故障，导致无法正常删除该实例。 当尝试插入新节点时，由于此票证中描述的错误，它未能加入。

我必须通过etcdctl手动删除etcd成员，然后才能加入一个新节点。 我还从kubeadm-config ConfigMap中手动删除了该节点，但是我不确定是否需要这样做。

@Halytskyi谢谢etcdctl部分为我提供了帮助.....

今天在1.15.5中经历过

就我而言，我加入了集群，但版本为1.16。 然后删除此节点kubectl delete node ，降级为15.5.5并尝试重新加入（相同的ip，相同的主机名，不同的版本），并得到etcd不正常的错误。

解决者（基于@Halytskyi答案，但具有更新的etcdctl）：

• 从kubeadm-config configmap删除节点

>: kubectl edit configmap  kubeadm-config -n kube-system
configmap/kubeadm-config edited

• 在有问题的节点&& iptables -t -f -X中kubeadm reset -f，依此类推。

• 删除etcd成员（这是关键）：

root@k8s-nebula-m-115-2:wget https://github.com/etcd-io/etcd/releases/download/v3.4.3/etcd-v3.4.3-linux-amd64.tar.gz
root@k8s-nebula-m-115-2:tar xfz etcd-v3.4.3-linux-amd64.tar.gz

外壳
root @ k8s-nebula-m-115-2 ：〜/ etcdctl / etcd-v3.4.3-linux-amd64＃./etcdctl --endpoints https://127.0.0.1：2379 --cacert / etc / kubernetes / pki /etcd/ca.crt --cert /etc/kubernetes/pki/etcd/server.crt --key /etc/kubernetes/pki/etcd/server.key成员列表
289ed62da3c6e9e5，已启动，k8s-nebula-m-115-1， https ://10.205.30.2：2380， https ://10.205.30.2：2379，false
917e16b9e790c427，已启动，k8s-nebula-m-115-0， https ://10.205.30.1：2380， https ://10.205.30.1：2379，false
ad6b76d968b18085，已启动，k8s-nebula-m-115-2， https ：//10.205.30.0：2380， https ：//10.205.30.0：2379，否

```shell
root@k8s-nebula-m-115-2:~/etcdctl/etcd-v3.4.3-linux-amd64# ./etcdctl --endpoints https://127.0.0.1:2379 --cacert /etc/kubernetes/pki/etcd/ca.crt --cert /etc/kubernetes/pki/etcd/server.crt --key /etc/kubernetes/pki/etcd/server.key member remove 289ed62da3c6e9e5
Member 289ed62da3c6e9e5 removed from cluster d4913a539ea2384e

然后重新加入作品。

如果kubeadm reset被中断并且无法从kubeadm CM中删除节点，则会发生这种情况。
在这种情况下，您需要从kubeadm CM中手动将其删除。

因此，如果我删除带有kubectl delete node foobar的节点，则不会
从etcd成员中删除它？ 但是如果我在节点中执行kubeadm reset
删除，然后呢？ 🙄

2019年10月30日，星期三，13：27卢博米尔·伊万诺夫（Lubomir I.Ivanov）， notifications@ github.com
写道：

如果kubeadm重置中断并且无法删除
来自kubeadm CM的节点。
在这种情况下，您需要从kubeadm CM中手动将其删除。

-
您收到此邮件是因为您发表了评论。
直接回复此电子邮件，在GitHub上查看
https://github.com/kubernetes/kubeadm/issues/1300吗
或退订
https://github.com/notifications/unsubscribe-auth/AF7BZL4EOZV7GQYNQOM3773QRF4SXANCNFSM4GIIZTPA
。

“ kubeadm重置”应将其从kubeadm CM中删除，但是还需要调用“ kubectl删除节点”，以删除Node API对象。

在我的情况下，从de configmap中删除节点并没有将其从
etcd集群我需要手动etcdctl delete member 。

2019年10月31日，星期四，16：28，卢博米尔·伊万诺夫（Lubomir I.Ivanov） [email protected]
写道：

“ kubeadm重置”应将其从kubeadm CM中删除，但应调用“ kubectl
还需要删除节点”，以删除节点API对象。

-
您收到此邮件是因为您发表了评论。
直接回复此电子邮件，在GitHub上查看
https://github.com/kubernetes/kubeadm/issues/1300吗
或退订
https://github.com/notifications/unsubscribe-auth/AF7BZL2KB3GVLTFKQTJTYXLQRL2TLANCNFSM4GIIZTPA
。

kubeadm reset还应该从etcd集群中删除etcd成员。
尝试用--v = 5执行它，看看它能做什么。

但是请记住，kubeadm reset是一项尽力而为的命令，因此，如果由于某种原因而失败，则可能仅显示警告。

因此kubectl delete node不会将其从etcd中删除。 而是在节点kubeadm reset中运行它。
听起来对我来说很糟糕，我认为kubectl delete node应该从etcd中删除它。 还是我错过了一个明显的用例？
也许问是否也应该从那里删除它？
无论如何，感谢您对@ neolit123的澄清，我首先从控制平面删除了它，然后进行了重置，以为将自己从etcd中删除已经为时已晚。

因此有不同的责任。
kubectl delete节点，删除Node API对象-当您确实确定不再需要该节点时，应执行此操作，
在此之前，您应该在该节点上调用kubeadm reset。 我要做的是清除磁盘上的状态并删除etcd成员（如果这是一个控制平面节点，并且如果您使用默认选项，其中每个控制平面节点都在运行etcd实例）

kubeadm reset会重置节点，但由于以下两个原因它不会删除Node对象：

• reset只是重置节点，您可以重新加入它。 节点名称保留。
• 节点本身没有足够的特权来删除其Node对象。 这是“ admin.conf”所有者（例如管理员）的责任。

kubeadm reset是一项尽力而为的命令

关于此问题：当kubeadm reset由于某种原因未能完成（包括基础服务器的严重故障，因此首先不会执行kubeadm重置）时，除了手动编辑外，还有其他选项可以手动调整状态kubeadm-config configmap对象并删除节点？

如果该节点很难发生故障，并且您无法在其上调用kubeadm reset，则它需要手动操作。 您必须：
1）从kubeadm-config CM ClusterStatus中删除控制平面IP
2）使用etcdctl删除etcd成员
3）使用kubectl删除Node对象（如果您不想再使用Node了）

1和2仅适用于控制平面节点。

如果无法运行kubeadm reset，是否有任何方法可以自动执行此故障转移？

在1.9上也有同样的问题。 感谢您的解决方案。