缺陷: 在错误地对同一节点实施两种join后会使它无法被删除

[hmrg-grmh]

命令

sealos join sealos clean

简要描述

• 一个 node 节点被 join 为 master 节点时，不会受到阻止也不会执行失败（返回码 0）；
• 被像这样操作后的节点，执行 sealos clean --master <ip> 会提示需要用 sealos clean --node <ip> ，执行 sealos clean --node <ip> 又会被提示要用 sealos clean --master <ip> 。

复现

前提

1. 节点三台（VMware16的虚拟机），系统为 CentOS7.9.2009 ：
   node-01 192.168.2.101
node-02 192.168.2.102
node-03 192.168.2.103

2. 用 init 初始化命令：
   sealos init --master 192.168.2.101 --node 192.168.2.102 --node 192.168.2.103
   (后面还有url和版本略)

3. sealos 版本： 3.3.9-rc.3 ， 包版本： 1.20.6 和 1.19.10 都试过了

执行

sealos clean --node 192.168.2.102 ：正常执行，会先提示是否删除，是则删除。

sealos join --node 192.168.2.102 ：正常执行（返回码 0），用 kubectl get node 会看到执行完后成功加入。

重头戏来了：

在上述基础上

sealos join --master 192.168.2.102 ：正常执行（返回码 0），用 kubectl get node 会看到 node-02 没有成为 master ！

过程中有这样一行 INFO 级别的日志：

此时的 ~/.sealos/config.yaml 中会出现同一个节点既在 nodes 里也在 masters 里的配置。

这时候其实已经出错了。

再对这个节点执行 sealos clean 的话，不管 --node 还是 --master 就都会出错了（返回码 255）。

可以参考的思路

1. 如果一个节点已经有了身份，那就禁止对它的 join 操作，提示 它已经加入了 之类的；
   或者询问是否一键把它改成另一种类型，带上 -y 或者 --force 之类的就不询问。
2. 同时另一方面，增加这样一个命令： sealos clean --any <ip>
   即，那个中间的选项还是用来防止有人用脚本批量删除的时候误删，只有用 --any 选项的时候才会忽略节点的类型去删。提供一种忽略类型指定但只删一个节点的途径（因为一个节点要么是 master 要么是 node 嘛）。

[oldthreefeng]

如果一个节点已经有了身份，那就禁止对它的 join 操作，提示 它已经加入了 之类的。

我来操作的话，应该会写这个思路。

如果能提交pr就更好了。

[hmrg-grmh]

如果一个节点已经有了身份，那就禁止对它的 join 操作，提示 它已经加入了 之类的。

我来操作的话，应该会写这个思路。

如果能提交 pr 就更好了。

其实我头一回这样玩就是想看看它能不能自动识别我的需求，然后猜测我是不是想要把这个节点做身份切换。。。

（第二点。。。是考虑，用来照顾旧版本中已经发生这种错误却不能删整个集群，这样的情况。。）

[oldthreefeng]

node 节点升级至 master的操作， 内在逻辑应该还有很多操作。
最快速的方法就是先干掉node 然后 join master。 其实很多前置的检查， sealos还没有完善。
当时写clean的时候， master和node节点写错了， 就是考虑了 #566 这个问题，所以加上了限制。