这期内容当中小编将会给大家带来有关k8s运维06-kubectl delete node的过程是怎么样的,文章内容丰富且以专业的角度为大家分析和叙述,阅读完这篇文章希望大家可以有所收获。
让客户满意是我们工作的目标,不断超越客户的期望值来自于我们对这个行业的热爱。我们立志把好的技术通过有效、简单的方式提供给客户,将通过不懈努力成为客户在信息化领域值得信任、有价值的长期合作伙伴,公司提供的服务项目有:申请域名、网站空间、营销软件、网站建设、宾阳网站维护、网站推广。
delete是一个比较粗暴的命令,它会将被删node上的pod直接驱逐,由其他node创建(针对replicaset),然后将被删节点从master管理范围内移除,master对其失去管理控制,若想使node重归麾下,必须在node节点重启kubelet
以删除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
10.5.0.45节点有4个pod
image.png
[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
image.png
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
docker ps查看容器 已为空
[root@docker000045.ppdgdsl.com ~] $docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
重启节点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
此三个命令都会使node停止被调度,后期创建的pod不会继续被调度到该节点上,但操作的暴力程度不一
影响最小,只会将node调为SchedulingDisabled
之后再发创建pod,不会被调度到该节点
旧有的pod不会受到影响,仍正常对外提供服务
恢复调度
kubectl uncordon node_name
首先,驱逐node上的pod,其他节点重新创建
接着,将节点调为** SchedulingDisabled**
恢复调度
kubectl uncordon node_name
首先,驱逐node上的pod,其他节点重新创建
然后,从master节点删除该node,master对其不可见,失去对其控制,master不可对其恢复
恢复调度,需进入node节点,重启kubelet
基于node的自注册功能,节点重新恢复使用
systemctl restart kubelet
上述就是小编为大家分享的k8s运维06-kubectl delete node的过程是怎么样的了,如果刚好有类似的疑惑,不妨参照上述分析进行理解。如果想知道更多相关知识,欢迎关注创新互联行业资讯频道。
当前标题:k8s运维06-kubectldeletenode的过程是怎么样的
浏览路径:https://www.cdcxhl.com/article16/gdhdgg.html
成都网站建设公司_创新互联,为您提供静态网站、全网营销推广、网站导航、Google、网站收录、动态网站
声明:本网站发布的内容(图片、视频和文字)以用户投稿、用户转载内容为主,如果涉及侵权请尽快告知,我们将会在第一时间删除。文章观点不代表本网站立场,如需处理请联系客服。电话:028-86922220;邮箱:631063699@qq.com。内容未经允许不得转载,或转载时需注明来源: 创新互联