一. 本节记录kubectl delete node的执行过程
delete是一个比较粗暴的命令,它会将被删node上的pod直接驱逐,由其他node创建(针对replicaset),然后将被删节点从master管理范围内移除,master对其失去管理控制,若想使node重归麾下,必须在node节点重启kubelet
提前查看所有node
- 以删除10.5.0.45为例,看到节点存在
[root@k8smaster163075 ~]
$kubectl get nodes
NAME STATUS ROLES AGE VERSION
10.5.0.44 Ready,SchedulingDisabled <none> 41h v1.11.3
10.5.0.45 Ready <none> 41h v1.11.3
10.5.0.46 Ready <none> 41h v1.11.3
10.5.0.47 Ready <none> 41h v1.11.3
10.5.0.48 Ready <none> 41h v1.11.3
10.5.0.49 Ready <none> 41h v1.11.3
查看所有pod
- 10.5.0.45节点有4个pod
执行 kubectl delete node 10.5.0.45
[root@k8smaster163075 ~]
$kubectl get pods -n test-kubeasy-k8s -o wide | grep 10.5.0.45
atlas-uat-deployment-5b65898567-85jpb 1/1 Running 0 14m 10.5.45.104 10.5.0.45 <none>
atlas-uat-deployment-5b65898567-8l7gm 1/1 Running 0 41h 10.5.45.102 10.5.0.45 <none>
atlas-uat-deployment-5b65898567-cqzj7 1/1 Running 0 41h 10.5.45.103 10.5.0.45 <none>
atlas-uat-deployment-5b65898567-lzp7k 1/1 Running 0 41h 10.5.45.101 10.5.0.45 <none>
[root@k8smaster163075 ~]
$kubectl delete node 10.5.0.45
node "10.5.0.45" deleted
重新查看pod,看到新建了4台pod
image.pngmaster查看所有node
- node已经不在master的控制范围
- 对比kubectl drain/cordon node,
[root@k8smaster163075 ~]
$kubectl get nodes
NAME STATUS ROLES AGE VERSION
10.5.0.44 Ready,SchedulingDisabled <none> 41h v1.11.3
10.5.0.46 Ready <none> 41h v1.11.3
10.5.0.47 Ready <none> 41h v1.11.3
10.5.0.48 Ready <none> 41h v1.11.3
10.5.0.49 Ready <none> 41h v1.11.3
ssh 到 10.5.0.45 机器
- docker ps查看容器 已为空
[root@docker000045.ppdgdsl.com ~]
$docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
delete节点的恢复
- 重启节点kubelet
- 进入master查看node,节点10.5.0.45出现,AGE=2m16s,刚生效
[root@k8smaster163075 ~]
$kubectl get nodes
NAME STATUS ROLES AGE VERSION
10.5.0.44 Ready,SchedulingDisabled <none> 42h v1.11.3
10.5.0.45 Ready <none> 2m16s v1.11.3
10.5.0.46 Ready <none> 42h v1.11.3
10.5.0.47 Ready <none> 42h v1.11.3
10.5.0.48 Ready <none> 42h v1.11.3
10.5.0.49 Ready <none> 42h v1.11.3
二. cordon,drain,delete node区别
此三个命令都会使node停止被调度,后期创建的pod不会继续被调度到该节点上,但操作的暴力程度不一
cordon 停止调度
- 影响最小,只会将node调为SchedulingDisabled
- 之后再发创建pod,不会被调度到该节点
- 旧有的pod不会受到影响,仍正常对外提供服务
- 恢复调度
kubectl uncordon node_name
drain 驱逐节点
- 首先,驱逐node上的pod,其他节点重新创建
- 接着,将节点调为** SchedulingDisabled**
- 恢复调度
kubectl uncordon node_name
delete 删除节点
- 首先,驱逐node上的pod,其他节点重新创建
- 然后,从master节点删除该node,master对其不可见,失去对其控制,master不可对其恢复
- 恢复调度,需进入node节点,重启kubelet
- 基于node的自注册功能,节点重新恢复使用
systemctl restart kubelet
网友评论