CKA备考实验 | 节点的cordon与drain

已于 2023-09-25 15:49:09 修改
阅读量434 收藏 1
点赞数 1
文章标签： kubernetes
于 2023-06-29 08:51:47 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/guolianggsta/article/details/131448974
版权
本文详细介绍了如何在Kubernetes中使用Cordon和Drain命令将节点标记为不可调度，以及这两个操作的区别。Cordon只阻止新Pod调度到节点，而Drain会驱逐节点上的所有Pod。在维护节点时，Drain是一个更全面的选择，因为它同时处理了现有Pod。
摘要由CSDN通过智能技术生成

书籍来源：《CKA/CKAD应试指南：从Docker到Kubernetes完全攻略》

一边学习一边整理老师的课程内容及实验笔记，并与大家分享，侵权即删，谢谢支持！

附上汇总贴：CKA备考实验 | 汇总_热爱编程的通信人的博客-CSDN博客

如果想把某个节点设置为不可用的话，可以对节点实施cordon或drain操作，这样节点就会被标记为SchedulingDisabled，新创建的pod就不会再分配到这些节点上了。

节点的cordon

如果某个节点要进行维护，希望此节点不再被分配pod，那么可以使用cordon把此节点标记为不可调度，但是运行在此节点上的pod依然会运行在此节点上。

步骤1：查看现有节点信息。

##########实操验证##########
[root@vms10 pod]#    kubectl get nodes
NAME            STATUS   ROLES    AGE     VERSION
vms10.rhce.cc   Ready    master   4d17h   v1.21.1
vms11.rhce.cc   Ready    <none>   4d17h   v1.21.1
vms12.rhce.cc   Ready    <none>   4d17h   v1.21.1
[root@vms10 pod]#

所有状态都是Ready，也就是说现在都是可以调度的。

步骤2：创建一个deployment（后面会讲）测试。

##########实操验证##########
[root@vms10 pod]# kubectl create deployment nginx --image=nginx --dry-run=client -o yaml > d1.yaml
[root@vms10 pod]#

步骤3：修改d1.yaml里的replicas的值为3，并将镜像下载策略设置为IfNotPresent:，内容如下。

##########实操验证##########
[root@vms10 pod]# cat d1.yaml 
apiVersion: apps/v1
kind: Deployment
metadata:
  creationTimestamp: null
  labels:
    app: nginx
  name: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  strategy: {}
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: nginx
    spec:
      containers:
      - image: nginx
        imagePullPolicy: IfNotPresent
        name: nginx
        resources: {}
status: {}
[root@vms10 pod]#

步骤4：应用此文件创建deployment。

##########实操验证##########
[root@vms10 pod]# kubectl apply -f d1.yaml 
deployment.apps/nginx created
[root@vms10 pod]#

步骤5：查看pod运行情况。

##########实操验证##########
[root@vms10 pod]# kubectl get pods -o wide
NAME                     READY   STATUS    RESTARTS   AGE   IP             NODE            NOMINATED NODE   READINESS GATES
nginx-7cf7d6dbc8-ldkwk   1/1     Running   0          21s   10.244.81.77   vms11.rhce.cc   <none>           <none>
nginx-7cf7d6dbc8-mrbl7   1/1     Running   0          21s   10.244.14.8    vms12.rhce.cc   <none>           <none>
nginx-7cf7d6dbc8-ppgxh   1/1     Running   0          21s   10.244.81.78   vms11.rhce.cc   <none>           <none>
[root@vms10 pod]#

可以看到3个pod被分配到vms11和vms12两个节点上了。

步骤6：现在通过cordon把vms11标记为不可用。

##########实操验证##########
[root@vms10 pod]# kubectl cordon vms11.rhce.cc
node/vms11.rhce.cc cordoned
[root@vms10 pod]#

步骤7：查看node的状态。

##########实操验证##########
[root@vms10 pod]# kubectl get nodes
NAME            STATUS                     ROLES    AGE     VERSION
vms10.rhce.cc   Ready                      master   4d17h   v1.21.1
vms11.rhce.cc   Ready,SchedulingDisabled   <none>   4d17h   v1.21.1
vms12.rhce.cc   Ready                      <none>   4d17h   v1.21.1
[root@vms10 pod]#

可以看到此时vms11的状态为SchedulingDisabled，也就是不可用。

步骤8：扩展此deployment的副本数为6个（后面会讲，先跟着做）。

##########实操验证##########
[root@vms10 pod]# kubectl scale deployment nginx --replicas=6
deployment.apps/nginx scaled
[root@vms10 pod]#

这个命令后面会讲到，然后再次查看pod的分布情况。

##########实操验证##########
[root@vms10 pod]# kubectl get pods -o wide
NAME                     READY   STATUS    RESTARTS   AGE    IP             NODE            NOMINATED NODE   READINESS GATES
nginx-7cf7d6dbc8-6pjwm   1/1     Running   0          4m5s   10.244.14.9    vms12.rhce.cc   <none>           <none>
nginx-7cf7d6dbc8-9cmnr   1/1     Running   0          26s    10.244.14.12   vms12.rhce.cc   <none>           <none>
nginx-7cf7d6dbc8-ldkwk   1/1     Running   0          8m9s   10.244.81.77   vms11.rhce.cc   <none>           <none>
nginx-7cf7d6dbc8-mrbl7   1/1     Running   0          8m9s   10.244.14.8    vms12.rhce.cc   <none>           <none>
nginx-7cf7d6dbc8-ppgxh   1/1     Running   0          8m9s   10.244.81.78   vms11.rhce.cc   <none>           <none>
nginx-7cf7d6dbc8-vbslh   1/1     Running   0          4m5s   10.244.14.10   vms12.rhce.cc   <none>           <none>
[root@vms10 pod]#

可以看到新创建的pod（时间为38s的那3个pod）只会分布到vms12节点上，不会再分配vms11节点，但是对原本已经分布到vms11的pod（这里是nginx-5957f949fc-s6zhh），还是继续在vms11上运行，此时我们只要删除运行在vms11上的这些pod，那么所有的pod都在vms12上运行。

步骤9：删除vms11上运行的pod。

##########实操验证##########
[root@vms10 pod]# kubectl delete pod nginx-7cf7d6dbc8-ldkwk
pod "nginx-7cf7d6dbc8-ldkwk" deleted
[root@vms10 pod]# kubectl delete pod nginx-7cf7d6dbc8-ppgxh
pod "nginx-7cf7d6dbc8-ppgxh" deleted
[root@vms10 pod]#

步骤10：查看pod的分布情况。

##########实操验证##########
[root@vms10 pod]# kubectl get pods -o wide
NAME                     READY   STATUS    RESTARTS   AGE    IP             NODE            NOMINATED NODE   READINESS GATES
nginx-7cf7d6dbc8-6pjwm   1/1     Running   0          5m1s   10.244.14.9    vms12.rhce.cc   <none>           <none>
nginx-7cf7d6dbc8-9cmnr   1/1     Running   0          82s    10.244.14.12   vms12.rhce.cc   <none>           <none>
nginx-7cf7d6dbc8-mrbl7   1/1     Running   0          9m5s   10.244.14.8    vms12.rhce.cc   <none>           <none>
nginx-7cf7d6dbc8-n2pf6   1/1     Running   0          33s    10.244.14.13   vms12.rhce.cc   <none>           <none>
nginx-7cf7d6dbc8-n59qp   1/1     Running   0          21s    10.244.14.14   vms12.rhce.cc   <none>           <none>
nginx-7cf7d6dbc8-vbslh   1/1     Running   0          5m1s   10.244.14.10   vms12.rhce.cc   <none>           <none>
[root@vms10 pod]#

可以看到新的pod也是在vms12上运行了。

注意：这里用到了控制器deployment，关于deployment如何管理pod，后面的章节会讲。

步骤11：如果要恢复vms11，只要对vms11进行uncordon操作即可。

##########实操验证##########
[root@vms10 pod]# kubectl uncordon vms11.rhce.cc
node/vms11.rhce.cc uncordoned
[root@vms10 pod]#

步骤12：查看节点状态。

##########实操验证##########
[root@vms10 pod]# kubectl get nodes
NAME            STATUS   ROLES    AGE     VERSION
vms10.rhce.cc   Ready    master   4d17h   v1.21.1
vms11.rhce.cc   Ready    <none>   4d17h   v1.21.1
vms12.rhce.cc   Ready    <none>   4d17h   v1.21.1
[root@vms10 pod]#

步骤13：把这个deployment的副本数设置为0。

##########实操验证##########
[root@vms10 pod]# kubectl scale deploy nginx --replicas=0
deployment.apps/nginx scaled
[root@vms10 pod]#

节点的drain

对节点的drain操作和对节点的cordon操作的作用是一样的，但是drain比cordon多了一个驱逐（evicted）的效果，即当我们对某节点进行drain操作的时候，不仅把此节点标记为不可调度，且会把上面正在运行的pod删除。

步骤1：使用前面的方法，把名字为nginx的deployment的副本数设置为4。

##########实操验证##########
[root@vms10 pod]# kubectl scale deploy nginx --replicas=4
deployment.apps/nginx scaled
[root@vms10 pod]#

步骤2：查看pod的运行状态。

##########实操验证##########
[root@vms10 pod]# kubectl get pod -o wide --no-headers
nginx-7cf7d6dbc8-28ccn   1/1   Running   0     35s   10.244.81.80   vms11.rhce.cc   <none>   <none>
nginx-7cf7d6dbc8-dm9r7   1/1   Running   0     35s   10.244.14.16   vms12.rhce.cc   <none>   <none>
nginx-7cf7d6dbc8-hbdcb   1/1   Running   0     35s   10.244.81.79   vms11.rhce.cc   <none>   <none>
nginx-7cf7d6dbc8-mrdww   1/1   Running   0     35s   10.244.14.15   vms12.rhce.cc   <none>   <none>
[root@vms10 pod]#

可以看到现在分别运行在两个节点上了，其中nginx-5957f949f-stllx是在vms12上运行的。

步骤3：现在对vms12进行drain操作。

##########实操验证##########
[root@vms10 pod]# kubectl drain vms12.rhce.cc
node/vms12.rhce.cc cordoned
error: unable to drain node "vms12.rhce.cc", aborting command...

There are pending nodes to be drained:
 vms12.rhce.cc
error: cannot delete DaemonSet-managed Pods (use --ignore-daemonsets to ignore): kube-system/calico-node-jgj2s, kube-system/kube-proxy-tcjt6
[root@vms10 pod]#

可以看到此操作有报错信息，因为在vms12上运行了一些由daemonset（后面会讲）控制的pod，此时运行在vms12上的pod依然在vms12上运行，但是已经被标记为不可调度。

##########实操验证##########
[root@vms10 pod]# kubectl get nodes
NAME            STATUS                     ROLES    AGE     VERSION
vms10.rhce.cc   Ready                      master   4d17h   v1.21.1
vms11.rhce.cc   Ready                      <none>   4d17h   v1.21.1
vms12.rhce.cc   Ready,SchedulingDisabled   <none>   4d17h   v1.21.1
[root@vms10 pod]#

提示：可以用--ignore-daemonsets选项忽略由daemonset控制的pod。

步骤4：取消vms12的drain操作。

##########实操验证##########
[root@vms10 pod]# kubectl uncordon vms12.rhce.cc
node/vms12.rhce.cc uncordoned
[root@vms10 pod]#

注意：取消drain仍然是用的uncordon，没有undrain操作。

步骤5：查看节点状态。

##########实操验证##########
[root@vms10 pod]# kubectl get nodes
NAME            STATUS   ROLES    AGE     VERSION
vms10.rhce.cc   Ready    master   4d17h   v1.21.1
vms11.rhce.cc   Ready    <none>   4d17h   v1.21.1
vms12.rhce.cc   Ready    <none>   4d17h   v1.21.1
[root@vms10 pod]#

步骤6：再次对vms12进行drain操作。

##########实操验证##########
[root@vms10 pod]# kubectl drain vms12.rhce.cc --ignore-daemonsets --delete-local-data
Flag --delete-local-data has been deprecated, This option is deprecated and will be deleted. Use --delete-emptydir-data.
node/vms12.rhce.cc cordoned
WARNING: ignoring DaemonSet-managed Pods: kube-system/calico-node-jgj2s, kube-system/kube-proxy-tcjt6
evicting pod kube-system/calico-kube-controllers-7cc8dd57d9-2rzpg
evicting pod default/nginx-7cf7d6dbc8-dm9r7
evicting pod default/nginx-7cf7d6dbc8-mrdww
pod/nginx-7cf7d6dbc8-dm9r7 evicted
pod/calico-kube-controllers-7cc8dd57d9-2rzpg evicted
pod/nginx-7cf7d6dbc8-mrdww evicted
node/vms12.rhce.cc evicted
[root@vms10 pod]#

此时vms12被标记为不可调度，且原来运行在vms12上的pod全部跑到vms11上了。

步骤7：查看节点状态。

##########实操验证##########
[root@vms10 pod]# kubectl get nodes
NAME            STATUS                     ROLES    AGE     VERSION
vms10.rhce.cc   Ready                      master   4d17h   v1.21.1
vms11.rhce.cc   Ready                      <none>   4d17h   v1.21.1
vms12.rhce.cc   Ready,SchedulingDisabled   <none>   4d17h   v1.21.1
[root@vms10 pod]#

可以看到，vms12已经是SchedulingDisabled了。

步骤8：查看pod运行状态。

##########实操验证##########
[root@vms10 pod]# kubectl get pods -o wide --no-headers
nginx-7cf7d6dbc8-28ccn   1/1   Running   0     5m16s   10.244.81.80   vms11.rhce.cc   <none>   <none>
nginx-7cf7d6dbc8-bwckp   1/1   Running   0     53s     10.244.81.81   vms11.rhce.cc   <none>   <none>
nginx-7cf7d6dbc8-hbdcb   1/1   Running   0     5m16s   10.244.81.79   vms11.rhce.cc   <none>   <none>
nginx-7cf7d6dbc8-w4sdm   1/1   Running   0     53s     10.244.81.82   vms11.rhce.cc   <none>   <none>
[root@vms10 pod]#

上面ngix-5957f949fc-58h7x是新生成的pod，已经跑到vms11上了。

步骤9：取消drain操作。

##########实操验证##########
[root@vms10 pod]# kubectl uncordon vms12.rhce.cc
node/vms12.rhce.cc uncordoned
[root@vms10 pod]#
热爱编程的通信人
关注
cka-lab：CKA考试的实验室环境
02-06
《CKA考试实验室环境搭建详解》 在深入探讨CKA（Certified Kubernetes Administrator）认证考试的实验室环境之前，我们先来了解一下CKA考试的核心。CKA是由Cloud Native Computing Foundation（CNCF）主办的一项...
kubernetes 安全的清空一个节点
最新发布
qq_49109854的博客
03-28 248
原因分析： node2-2-6 节点上还有运行着 k8s 组件相关pod ，是由DaemonSet 方式运行，使用 --ignore-daemonsets 忽略错误错误警告。可以看到node2-2-6节点已经被暂停调度（SchedulingDisabled）查看pod 还有 pod 运行在 node2-2-6 节点上，等会会自动消失。注：为了升级某一些组件等，可以不用删除，升级完成之后，重新设置为可调度。3、驱逐节点上运行的pod。
k8s 移除node 全过程
qq_36270681的博客
09-16 1324
可以看到node3上有 5个pod [root@VM-2-5-centos ~]# kubectl get pod -A -owide NAMESPACE NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES kube-system calico-kube.
K8S排水错误汇总（忽略DaemonSet管理Pod、Mysql集群排水报错、Mongo集群排水报错）
运维玄德公
07-19 703
【成功排水展示】 初始状态 排水命令 正确排水的输出 排水后结果 恢复节点 【FAQ】 1. 忽略DaemonSet管理的Pod 2. 删除本地数据（mysql集群节点删除失败） 3. mongo集群排水报错
k8s运维-06-kubectl delete node的过程
chuxiong5717的博客
07-07 2571
一. 本节记录kubectl delete node的执行过程 delete是一个比较粗暴的命令，它会将被删node上的pod直接驱逐，由其他node创建（针对replicaset），然后将被删节点从master管理范围内移除，master对其失去管理控制，若想使node重归麾下，必...
k8s pod 在节点间调度控制
ksj367043706的博客
03-24 4397
博客作为学习笔记记录，若有理解，表述错误，欢迎指出。 k8s起pod时，会通过调度器scheduler选择某个节点完成调度，选择在某个节点上完成pod创建。 当需要在指定pod运行在某个节点上时，可以通过以下几种方式： 1. 在部署pod的yaml中，指定nodeName 指定了nodeName的Pod会直接跳过Scheduler的调度逻辑，直接写入PodList列表，该匹配规则是强制匹...
2021 CKA-CKS（Kubernetes管理员/专家）备考攻略.pptx
10-26
2021 CKA-CKS（Kubernetes管理员/专家）备考攻略
cka-practice-environment：帮助准备CKA认证的示例实验室测试环境
02-03
cka实践环境 准备好环境 确保已安装docker-compose（）。 要启动实验室环境，您可以执行以下两个操作之一： 要使用预构建的映像，请运行： docker-compose up -d并将浏览器指向http://localhost 要自己在本地生成...
K8S中的cordon、uncordon和drain node标签 节点标签
yuezhilangniao的博客
12-15 1802
drain：驱除+不可调度 cordon：不可调度 uncordon：可调度 node及pod状态 [root@hanyu-210 ~]# kubectl get nodes NAME STATUS ROLES AGE VERSION hanyu-210 Ready master 31d v1.16.0 hanyu-211 Ready 31d v1.16.0 hanyu-212 Ready 31d v1.16.0 [roo
cordon、drain、delete node区别
weixin_30339457的博客
08-23 497
cordon、drain、delete node区别主要目的：导致node处于不可调度状态，新创建的pod容器不会调度在node上。 cordon将node置为SchedulingDisabled不可调度状态，后续的新创建pod容器时scheduler调度不会考虑该node旧的pod容器不会正常受影响，仍可以对外提供正常服务。(特殊情况：pod容器如果跟node绑定的话，容器下次更新就...
Kubernetes(K8s) kubectl cordon, drain, uncordon 常用命令
weixin_42098295的博客
02-13 798
Kubernetes(K8s)中使用Kubectl 命令行工具管理 Kubernetes 集群。 kubectl 在 $HOME/.kube 目录中查找一个名为 config 的配置文件。 可以通过设置 KUBECONFIG 环境变量或设置 --kubeconfig 参数来指定其它 kubeconfig 文件。本文主要介绍Kubernetes(K8s)中kubectl cordon, drain, uncordon 常用命令。 原文地址：Kubernetes(K8s) kubectl cordon, dra
Kubernetes节点的cordon和drain
memory_hahaha的博客
02-19 324
Kubernetes节点的cordon和drain
kubernetes 节点维护 cordon, drain, uncordon
tonysh_zds的博客
03-06 7799
这三个命令是正式release的1.2新加入的命令，三个命令一起介绍，是因为三个命令配合使用可以实现节点的维护。在1.2之前，因为没有相应的命令支持，如果要维护一个节点，只能stop该节点上的kubelet将该节点退出集群，是集群不在将新的pod调度到该节点上。如果该节点上本生就没有pod在运行，则不会对业务有任何影响。如果该节点上有pod正在运行，kubelet停止后，master会发现该节点不...
kubernetes升级
shajc0504的专栏
10-08 1581
升级过程中会用到的几个命令。 cordon：标记节点unschedulable。 drain：删除节点上的pods。如果APIserver支持eviction(http://kubernetes.io/docs/admin/disruptions/).操作，那么就会将pods移动到其他节点。否则，drain将会删除这些pods，但是无法删除mirror pods。此外如果有DaemonSet管...
SLURM 节点状态总是drained问题
热门推荐
kongxx的专栏
09-03 2万+
问题描述新装的 SLURM 集群在运行了一些作业并修改一些配置项目以后，用sinfo查看信息的时候看到部分节点状态总是 drained ，但是在这个节点上并没有作业在运行，重启 slurm 服务问题依旧，如下$ sinfoPARTITION AVAIL TIMELIMIT NODES STATE NODELIST debug* up infinite 1 drain
Drain算法：日志解析
qq_39378221的博客
11-08 9469
文章目录论文1 算法的作用2 算法原理0 树结构1 算法第一步：**通过专业知识对消息进行预处理**2 算法第二步：**通过日志消息长度进行搜索**3 算法第三步：**通过前面的tokens进行搜索**4 算法第四步：通过token相似度搜索5 算法第五部：更新解析树 论文 《Drain: An Online Log Parsing Approach with Fixed Depth Tree》 1 算法的作用   Drain是一种基于固定深度树的在线日志解析（日志解析的目标是将原始日志信息转换为结构化的日
2021 CKA-CKS备考策略：官方资源与实战指南
在准备2021年的CKA-CKS...这份备考攻略强调了理论学习与实践经验的结合，以及对官方文档的深入研究，确保考生具备应对CKA-CKS认证所需的知识和技能。通过系统的复习和实践，考生将能更好地准备并取得理想的成绩。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值