原有环境说明

主机名	系统版本	ip地址	docker version	kubelet version	kubeadm version	kubectl version	flannel version	备注
master	centos-release-7-7.1908.0.el7.centos.x86_64	192.168.137.221	Docker 18.09.6	V1.14.2	V1.14.2	V1.14.2	V0.11.0	master节点
node01	centos-release-7-7.1908.0.el7.centos.x86_64	192.168.137.222	Docker 18.09.6	V1.14.2	V1.14.2	V1.14.2	V0.11.0	node节点
node02	centos-release-7-7.1908.0.el7.centos.x86_64	192.168.137.223	Docker 18.09.6	V1.14.2	V1.14.2	V1.14.2	V0.11.0	node节点
node03	centos-release-7-7.1908.0.el7.centos.x86_64	192.168.137.224	Docker 18.09.6	V1.14.2	V1.14.2	V1.14.2	V0.11.0	node节点
node04	centos-release-7-7.1908.0.el7.centos.x86_64	192.168.137.225	Docker 18.09.6	V1.14.2	V1.14.2	V1.14.2	V0.11.0	node节点

本次演示从集群中安全地删除一个节点，节点删除之后，该节点上的任务会自动转移到其他节点。
下面以删除node04节点为例。

一、删除node04节点

以下操作如果没有特别说明，则都在master节点上进行

1.查看当前集群的节点信息

1.1查看node节点信息

[root@master ~]# kubectl get node

node01节点因为服务器没启动所以是NotReady状态

1.2查看部署在node04上的资源

这里有一个名为：nginx-addnode-node04-dep 的容器组，一共有6个资源实例，并且有一个部署在node04上面。

2.使用kubectl命令删除node节点

[root@master ~]# kubectl delete node node04

显示node04已删除。

3.查看当前集群的节点信息

3.1查看node信息

[root@master ~]# kubectl get node

显示node04已经不存在，则表明删除成功。

3.2验证资源是否自动转移

可以看到nginx-addnode-node04-dep的容器组没有一个实例是在node04上面的了，并且在node03上面多了一个节点，同时，该容器组实例的创建时间是最新的。这就验证了被删除节点的资源会自动分布的其他活动的节点上面。

4.在node节点上彻底删除集群信息

** 该部分在node04节点上进行操作 **
删除kube-controller-manager 为node04节点生成的kubeconfig 文件和公私钥：

[root@node04 ~]# rm -rf /etc/kubernetes/kubelet.kubeconfig
[root@node04 ~]# rm -rf /etc/kubernetes/cert/kubelet*

5.node节点停止相关服务

该部分在node04节点上进行操作

[root@node04 ~]# systemctl stop kubelet kube-proxy flanneld docker kube-proxy kube-nginx
[root@node04 ~]# systemctl disable kubelet kube-proxy flanneld docker kube-proxy kube-nginx

此时，node04节点相关服务已经从集群中彻底删除，且设置成开机不自动启动。等待资源被重新分配到其他活动节点即可。

6.清除kube-proxy 和 docker 创建的 iptables

这步如果不执行的话，可能会出现使用被删除节点的ip也能访问集群的情况

[root@node04 ~]# iptables -F && iptables -X && iptables -F -t nat && iptables -X -t nat

二、node节点重新加入集群

以下操作如果没有特别说明，则都在master节点上进行

这里所讲的node节点是指之前按照以上步骤删除的节点，该节点上已经有一些k8s的工具或服务，所以可以直接进行加入集群的操作。

1.重启k8s集群相关服务

1.1重启服务

该部分在node04节点上进行操作

[root@node04 ~]# systemctl restart kubelet kube-proxy flanneld docker kube-proxy kube-nginx
[root@node04 ~]# systemctl enable kubelet kube-proxy flanneld docker kube-proxy kube-nginx

1.2查看kubelet状态

该部分在node04节点上进行操作

[root@node04 ~]# systemctl status kubelet

如果出现以下错误，则说明之前使用的token已经过期了。我们可以使用kubeadm给node04重新创建一个token。如果没有出现以下错误，请直接查看1.3节。

1.2.1使用kubeadm创建token

[root@master ~]# kubeadm token create \
 --description kubelet-bootstrap-token \
 --groups system:bootstrappers:node03 \
 --kubeconfig ~/.kube/config

1.2.2查看token

[root@master ~]# kubeadm token list --kubeconfig ~/.kube/config

1.2.3替换已过期的token

该部分在node04节点上进行操作
使用vim替换/etc/kubernetes/kubelet-bootstrap.kubeconfig文件中的token为1.22中查询出来的token。

[root@node04 ~]# vim /etc/kubernetes/kubelet-bootstrap.kubeconfig

1.2.4再次查看kubelet的状态

该部分在node04节点上进行操作

[root@node04 ~]# systemctl restart kubelet
[root@node04 ~]# systemctl status kubelet

此时发现之前的错误已经不见了。

1.2.5查看node集群状态

[root@master ~]# kubectl get node

可以看到node04已经是Ready状态了。

1.3timed out waiting for the condition

如果在查看kubelet的时候出现了如下错误。则需要去master节点上主动approve server cert csr。

1.3.1查看csr

[root@master ~]# kubectl get csr

1.3.2手动approve

把node04节点的pending状态的csr都approve掉，正常情况下应该只有一条信息需要approve，我这里是做了多次试验所以才有多个。

[root@master ~]# kubectl certificate approve csr-5rh7g csr-blptz csr-cgz7f csr-h899h csr-kks55

再次去node04上面查看状态，发现错误已经消失了。

至此，k8s集群删除节点并重新加入集群就记录完毕了。