k8s调度、污点、容忍、不可调度、排水、数据卷挂载

2024-09-05 00:12

本文主要是介绍k8s调度、污点、容忍、不可调度、排水、数据卷挂载,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

一、Kubernetes的list-watch机制

1、List-watch

K8S集群中,通过List-watch机制进行每个组件的协作,保持数据同步。这种设计可以实现每个组件之间的解耦

kubectl配置文件,统一向集群内部apiserver发送命令——通过apiserver把命令发送到各个组件

创建成功之后,kubectl get pod,kubectl describe pod nginx查看信息——在ETCD数据库中

List-watch会在每一步把监听的消息(apiserver:6443)——组件controller-manager、schedule、kubelet、ETCD都会监听apiserver的6443端口

2、创建pod的过程:

1、客户端向apiserver发送创建创建pod的请求,然后apiserver将请求信息存入到ETCD中

2、存入完之后,ETCD会通过apiserver发送创建pod资源的事件

3、controller-manager通过List-watch机制监听apiserver发送出来的事件,并创建相关的pod资源。创建完成之后,通过apiserver将信息存入到ETCD中

4、ETCD存入更新信息之后,再次通过apiserver发送调度pod资源的事件到scheduler

5、scheduler通过List-watch机制监听到apiserver发出的调度事件,通过调度算法,将pod资源调度到合适的node节点上,调度完成后通过apiserver将调度信息更新到ETCD中

6、ETCD收到更新信息后,再次向apiserver发出的创建pod的事件

7、kubelet通过List-watch机制监听apiserver发出的创建pod的事件,然后根据事件信息,在相应的node节点完成pod的创建

二、scheduler调度的过程和策略:

1、简介

scheduler是K8S集群的调度器,把pod分配到集群的节点

调度规则:

  1. 公平,每个节点都能够分配资源
  2. 资源高效利用,集群中的资源可以被最大化使用
  3. 效率:调度的性能要好,能够尽快的完成大批量pod的调度工作
  4. 灵活:允许用户根据自己的需求,控制和改变调度的逻辑

scheduler:负责调度资源,把Pod调度到node节点上

有两种策略:预算策略、优选策略

scheduler是一个单独运行的程序,只要启动之后就会一直监听apiserver。获取报文中的字段:spec中的nodeName字段

创建pod时,为每个pod创建一个binding,表示该往哪个节点上部署

创建pod到节点时,有两个策略

先执行预算策略,在执行优先策略。这两步的操作都必须成功,否则立刻返回报错

部署的node必须满足这两个策略,少一个都不行

2、预算策略:predicate

自带一些算法,选择node节点,是scheduler自带的算法策略,不需要人工干预

  1. podfitsresources:pod的适应策源,检查节点上剩余的资源是否满足pod请求的资源(主要是CPU和内存)
  2. podfitshost:po适应主机,如果pod指定了node的name,检测主机名是否存在,如果存在要和pod指定的名称匹配,这才能调度过去
  3. podselectormarches:pod选择器匹配,创建pod的时候,可以根据node'节点的标签来进行匹配。他查找指定的node节点上标签是否存在。存在的标签是否匹配
  4. nodeskconflict:无磁盘冲突,确保已挂载的卷和pod卷不发生冲突。除非目录是只读

如果预算策略不满足,pod将始终处于pending状态,不断重试调度,直到节点满足条件为止

若三个node节点都满足——>优选策略

3、优先策略:
3.1、leastrequestedpriority:

最低请求优先级,通过算法计算节点上的CPU和内存使用率,确定节点的权重

使用率越低的节点,相应的权重就越高。调度时会更倾向于这些使用率低的节点。实现资源合理的利用

3.2、balanceresourceallocation:

平衡资源分配,算CPU和内存的使用率,给节点赋予权重。权重算的是CPU和内存使用率接近,权重越高。

和上面的最低请求优先级一起使用

举例:

node1 CPU和内存使用率:20 60

node2 CPU和内存使用率:50 50

node2的内存和CPU使用率接近,权重高,会被选择

3.3、imagelocalitypriority:

节点上是否已经有了要部署的镜像。镜像的总数成正比,满足的镜像数越多,权重越好

以上三个策略都是scheduler自带的算法,自动的

4、选择的过程:

先通过预算策略选择出可以部署的节点,在通过优选策略选择出最好的节点,以上都是自带的算法。K8S集群自己来选择

三、kubernetes对Pod的调度策略


在 Kubernetes 中,调度 是指将 Pod 放置到合适的节点上,以便对应节点上的 Kubelet 能够运行这些 Pod。

1)定向调度: 使用 nodeName 字段指定node节点名称;使用 nodeSelector 字段指定node节点的标签;

2)亲和性调度: 使用 节点/Pod 亲和性(NodeAffinity、PodAffinity、PodAntiAffinity);

3)污点与容忍: 使用 节点设置污点,结合 Pod设置容忍。

4)全自动调度:运行在哪个节点上完全由Scheduler经过一系列的算法计算得出;
 

  1. #补充,Pod和node的关系

  2. Node 是 Kubernetes 集群中的工作节点

  3. 一个 Node 可以运行多个 Pod,而一个 Pod 只能运行在一个 Node 上

  4. 使用标签和选择器可以管理 Node 和 Pod 之间的关系,从而实现灵活的调度和管理。

四、定向调度

1、调度策略简介:


nodeName:指定节点名称,用于将Pod调度到指定的Node上,不经过调度器。

nodeSelector:在 Pod 定义文件的 spec 下的 nodeSelector 字段中设置一个标签选择器,在 Pod 调度的时候,只有具有这些标签的 Node 才会被考虑用来运行这个 Pod。
 

2、指定节点:

spec参数设置:

nodeName: node2

指定了节点,在参数中设置了nodeName,指定了节点的名称,会跳过scheduler的调度策略,这个规则是强制匹配

3、指定标签:

spec参数设置:

nodeSelector:

节点自定义标签:

 
  1. kubectl label nodes master01 test1=a

  2. kubectl label nodes node01 test2=b

  3. kubectl label nodes node02 test3=c

  4. kubectl get nodes --show-labels

  5. #查看节点的标签

指定节点标签部署pod,是要经过scheduler的算法,如果节点不满足条件,pod会进入pending状态。直到节点满足条件为止

五、亲和性调度:

1、介绍:

两种亲和性:节点亲和性和pod亲和性

两种策略:软策略和硬策略

node节点的亲和性:

preferredDuringSchedulingIgnoredDuringExecution:软策略

选择node节点时,声明了我最好能部署在node01。如果是软策略,他会尽量满足这个条件,不一定会完全部署在node01节点上。

requiredDuringSchedulinglgnoredDuringExecution:硬策略

选择pod时,声明了部署在node1上。如果是硬策略,必须满足硬策略的条件,必须部署在node1上。强制性要求

pod的亲和性:

preferredDuringSchedulingIgnoredDuringExecution:软策略

要求调度器将pod调度到其他pod的亲和性匹配的节点上。可以是,也可以不是,尽量满足

requiredDuringSchedulingIgnoredDuringExecution:硬策略

要求调度器将pod调度到其他pod的亲和性匹配的节点上,强制性满足

2、键值的运算关系:

都是根据标签来选择node或者pod的亲和性

  1. In(大写的i):在,选择的标签值在node节点上存在
  2. Notin:不在,选择label的值不在node节点上
  3. Gt:大于,要大于选择的标签值,只能比较整数
  4. Lt:小于,要小于选择的标签值,只能比较整数
  5. Exists:存在,只是选择标签对象,不考虑值
  6. DoesNotExist:不存在,选择不具有指定标签的对象。不考虑值

3、node亲和性实例

node亲和性的硬策略:

in策略:

 
  1. apiVersion: apps/v1

  2. kind: Deployment

  3. metadata:

  4. labels:

  5. app: nginx

  6. name: nginx

  7. spec:

  8. replicas: 3

  9. selector:

  10. matchLabels:

  11. app: nginx

  12. template:

  13. metadata:

  14. labels:

  15. app: nginx

  16. spec:

  17. containers:

  18. - image: nginx:1.22

  19. name: nginx

  20. affinity:

  21. #选择亲和性部署方式

  22. nodeAffinity:

  23. #选择的是node节点的亲和性

  24. requiredDuringSchedulingIgnoredDuringExecution:

  25. nodeSelectorTerms:

  26. #选择了亲和性的策略。nodeSelectorTerms你要选择哪个node作为硬策略。匹配的节点标签

  27. - matchExpressions:

  28. #定义了一个符合我要选择的node节点信息

  29. - key: test3

  30. operator: In

  31. #指定键值对的算法

  32. values:

  33. - c

硬限制选择test3=c的节点

Notin:

notin,只要不在test3=c的节点,都能够部署

删除节点上的标签:

 
  1. kubectl label nodes master01 test1-

  2. kubectl label nodes node01 test2-

  3. kubectl label nodes node02 test3-

更改标签名:

kubectl label nodes node02  memory=1000 --overwrite

Gt:     

 
  1.  affinity:

  2.         nodeAffinity:

  3.           requiredDuringSchedulingIgnoredDuringExecution:

  4.             nodeSelectorTerms:

  5.             - matchExpressions:

  6.               - key: memory

  7.                 operator: Gt

  8.                 values:

  9.                 - "612"

大于612节点上部署

Exists:


    

 
  1.   affinity:

  2.         nodeAffinity:

  3.           requiredDuringSchedulingIgnoredDuringExecution:

  4.             nodeSelectorTerms:

  5.             - matchExpressions:

  6.               - key: memory

  7.                 operator: Exists

  8. #指定键值对的算法为Exists或DoesNotExist,不能使用values字段

DoesNotExist:
     

 
  1.  affinity:

  2.         nodeAffinity:

  3.           requiredDuringSchedulingIgnoredDuringExecution:

  4.             nodeSelectorTerms:

  5.             - matchExpressions:

  6.               - key: memory

  7.                 operator: DoesNotExist

软策略:


    

 
  1.   affinity:

  2.         nodeAffinity:

  3.           preferredDuringSchedulingIgnoredDuringExecution:

  4.           - weight: 1

  5.             preference:

  6.               matchExpressions:

  7.               - key: memory

  8.                 operator: In

  9.                 values:

  10.                 - "1000"

  11.           preferredDuringSchedulingIgnoredDuringExecution:

  12.           - weight: 10

  13.             preference:

  14.               matchExpressions:

  15.               - key: memory

  16.                 operator: In

  17.                 values:

  18.                 - "500"

多个软策略看权重,权重高,执行指定的软策略

硬策略和软策略一起执行:

先满足硬策略,再考虑软策略。若硬策略无法满足,软策略一个都不会执行

面试题:

你在部署pod的时候选择什么样的策略:

根据node的亲和性:

性能不一致,尽量把pod往性能高的多部署,选择软策略

节点故障或者节点维护中,只能选择硬策略,把故障节点剔除

4、pod亲和性实例
4.1、pod的亲和性和反亲和性:

调度策略:

匹配标签

操作符

拓扑域

调度目标

node的亲和性

主机标签

In、NotIn、Exists、DoesNotExist、Gt、Lt

不支持

指定主机

pod的亲和性

pod的标签

In、NotIn、Exists、DoesNotExist

支持

pod和指定标签的pod部署在同一个拓扑域

pod的反亲和性

pod的标签

In、NotIn、Exists、DoesNotExist

支持

pod和指定标签的pod部署在不同一个拓扑域

4.2、拓扑域:

K8S集群节点当中的一个组织结构,可以根据节点的物理关系或者逻辑关系进行划分

可以用来标识节点之间的空间关系,网络关系,或者其他类型的关系

这里pod的亲和性的拓扑域是标签

4.3、pod的亲和性实例:

1、In

  1. apiVersion: apps/v1

  2. kind: Deployment

  3. metadata:

  4. labels:

  5. app: nginx

  6. name: nginx

  7. spec:

  8. replicas: 3

  9. selector:

  10. matchLabels:

  11. app: nginx

  12. template:

  13. metadata:

  14. labels:

  15. app: nginx

  16. spec:

  17. containers:

  18. - image: nginx:1.22

  19. name: nginx

  20. affinity:

  21. podAffinity:

  22. requiredDuringSchedulingIgnoredDuringExecution:

  23. - labelSelector:

  24. matchExpressions:

  25. - key: app

  26. operator: In

  27. values:

  28. - nginx

  29. topologyKey: test1

  30. #topologyKey指定拓扑域的关键字段,表示正在使用test1作为拓扑的关键字。test1一般是节点标签,表示希望吧pod调度到包含有app标签的pod,值为nginx1的在test1的拓扑域上的节点

2、Exists

满足test1节点,且满足pod标签等于app的

 
  1.       affinity:

  2.         podAffinity:

  3.           requiredDuringSchedulingIgnoredDuringExecution:

  4.           - labelSelector:

  5.               matchExpressions:

  6.               - key: app

  7.                 operator: Exists

  8.             topologyKey: test1

软策略:

表示尽量选择满足不存在app的pod标签的 并且 是满足test1的节点的   

  1.    affinity:

  2.         podAffinity:

  3.           preferredDuringSchedulingIgnoredDuringExecution:

  4.           - weight: 1

  5.             podAffinityTerm:

  6.               labelSelector:

  7.                 matchExpressions:

  8.                 - key: app

  9.                   operator: DoesNotExist

  10.               topologyKey: test1

反亲和性:

表示反转,满足哪个就不去哪个

软策略反亲和性:

硬策略反亲和性:

注意点:

  1. pod的亲和性策略,在配置时,必须要加上拓扑域的关键字topologykey,指向的是节点标签
  2. pod亲和性的策略分为硬策略和软策略
  3. pod亲和性的NotIn可以替代反亲和性
  4. pod亲和性主要是为了把相关联的pod组件部署在同一节点上。lnmp

你在进行部署的时候,怎么考虑node节点:

软硬策略

污点和容忍

污点和容忍可以配合node的亲和性一块使用

污点:是node的调度机制,不是pod

被设为污点的节点,不会部署pod

污点和亲和性相反,亲和性是尽量选择和一定选择

污点的节点一定不被选择?

一、污点

1.查看主节点污点:kubectl describe nodes master

2.污点是什么:一旦节点上有污点的标签,那么调度器在部署pod的时候会避开这些有污点标签的节点。 

3.污点的两种格式:

1》key:effect   键值:类型

kubectl taint node node1 test1:effect

2》key=value:effect    键值=值:类型

kubectl taint node node1 test1=1:effect

3.污点的类型:

1》NoSchedule:节点上一旦有这个污点,调度器不会把pod部署到该节点上。

2》PreferNoSchedule:尽量避免把pod部署到该节点。

3》NoExecute:调度器不仅不会把pod部署到该节点,而且会把该节点的pod驱逐到其它节点上。

4.删除污点:

 三种污点类型

修改污点类型

 

 二、容忍:k8s第二个机制

1.容忍:即使节点上有污点,调度依然可以把pod部署在有污点的节点上。

2.容忍的类型只有两个 operator: Equal(等于)和Exists(包含)

Equal类型

 污点的容忍类型为驱逐NoExecute

tolerationseconds只能和Equal一起使用

 

Exists类型

 只要是指定污点,不管节点key键值是啥都会部署

 

只要键值key存在,不考虑你是啥污点类型都会部署

 

 三、cordon不可调度:直接标记节点为不可用节点

kubectl cordon node1

四、drain排水(谨慎使用):标记节点为不可调度,而且会把节点上的pod驱逐到其它节点

--ignore:无视daemonsets的部署的pod

-data:如果被排水的节点上有本地的挂载点,会强制杀死

--force:不是控制器创建的pod会被强制释放

如何恢复

五、面试题

问:当排水和驱逐之后,怎么样能让pod重新回到节点?

回:污点类型放逐必须要取消

       kubectl  uncordon node1

       重启   delete -f 

六、关于主节点master一般情况下做为集群的调度器,尽量不部署pod,但是为了资源最大化,master也可以部署,前提是设置污点类型为preferNoschedule;如果集群规模很小,可以直接用来当节点部署。 

七、数据卷volum

pod的生命周期是有限的,一旦重启或者崩溃数据就会丢失,为了保证数据的完整,我们要实现pod内的容器和节点进行挂载

1.数据卷类型:

emptyDir存储卷:容器和容器之间挂载;pod分配给节点之前,首先创建emotyDir卷,只要运行在节点,数据卷就会一直存在;这个数据卷不能和宿主机共享,pod内容器之间共享,一旦pod重启,enptyDir卷的数据也会一起删除。主要用于容器内部组件通信,不涉及敏感数据。

hostPath数据卷:每个pod和节点进行挂载,当pod部署到节点时,就会和节点的指定目录进行挂载;数据可以持久化;node节点数据格式化pod数据也就会消失。每个pod运行的数据不同,保留的数据要做分区,所以需要hostPath挂载。

Nfs共享存储卷:整个k8s集群里的pod相当于客户端,另外一台服务器提供Nfs共享;也就是所有pod共享一个挂载点,所有的数据也都在这一个挂载点。用于nginx服务或者pod的数据是一致的。

2.实验:

1》emptyDir:用{}代表

容器1的user/share和容器2 data/目录进行挂载,数据卷类型为emptyDir

 

 进入pod其中一个容器内

2》hostPath数据卷实验

 

三台共同操作:以节点的数据为主

 3》Nfs共享存储卷实验

K8s集群:

192.168.127.44  master1

192.168.127.55  node1

192.168.127.66  node2

192.168.127.36  集群外主机

首先四台主机做IP--主机名的映射

 集群外主机创建目录 mkdir /opt/data1

在k8s主节点yaml文件内进行nfs挂载

 

于集群外主机创建的data1目录下创建文件并查看挂载结果

 查看容器内挂载情况

这篇关于k8s调度、污点、容忍、不可调度、排水、数据卷挂载的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/1137434

相关文章

大模型研发全揭秘:客服工单数据标注的完整攻略

在人工智能(AI)领域,数据标注是模型训练过程中至关重要的一步。无论你是新手还是有经验的从业者,掌握数据标注的技术细节和常见问题的解决方案都能为你的AI项目增添不少价值。在电信运营商的客服系统中,工单数据是客户问题和解决方案的重要记录。通过对这些工单数据进行有效标注,不仅能够帮助提升客服自动化系统的智能化水平,还能优化客户服务流程,提高客户满意度。本文将详细介绍如何在电信运营商客服工单的背景下进行

基于MySQL Binlog的Elasticsearch数据同步实践

一、为什么要做 随着马蜂窝的逐渐发展,我们的业务数据越来越多,单纯使用 MySQL 已经不能满足我们的数据查询需求,例如对于商品、订单等数据的多维度检索。 使用 Elasticsearch 存储业务数据可以很好的解决我们业务中的搜索需求。而数据进行异构存储后,随之而来的就是数据同步的问题。 二、现有方法及问题 对于数据同步,我们目前的解决方案是建立数据中间表。把需要检索的业务数据,统一放到一张M

关于数据埋点,你需要了解这些基本知识

产品汪每天都在和数据打交道,你知道数据来自哪里吗? 移动app端内的用户行为数据大多来自埋点,了解一些埋点知识,能和数据分析师、技术侃大山,参与到前期的数据采集,更重要是让最终的埋点数据能为我所用,否则可怜巴巴等上几个月是常有的事。   埋点类型 根据埋点方式,可以区分为: 手动埋点半自动埋点全自动埋点 秉承“任何事物都有两面性”的道理:自动程度高的,能解决通用统计,便于统一化管理,但个性化定

使用SecondaryNameNode恢复NameNode的数据

1)需求: NameNode进程挂了并且存储的数据也丢失了,如何恢复NameNode 此种方式恢复的数据可能存在小部分数据的丢失。 2)故障模拟 (1)kill -9 NameNode进程 [lytfly@hadoop102 current]$ kill -9 19886 (2)删除NameNode存储的数据(/opt/module/hadoop-3.1.4/data/tmp/dfs/na

异构存储(冷热数据分离)

异构存储主要解决不同的数据,存储在不同类型的硬盘中,达到最佳性能的问题。 异构存储Shell操作 (1)查看当前有哪些存储策略可以用 [lytfly@hadoop102 hadoop-3.1.4]$ hdfs storagepolicies -listPolicies (2)为指定路径(数据存储目录)设置指定的存储策略 hdfs storagepolicies -setStoragePo

Hadoop集群数据均衡之磁盘间数据均衡

生产环境,由于硬盘空间不足,往往需要增加一块硬盘。刚加载的硬盘没有数据时,可以执行磁盘数据均衡命令。(Hadoop3.x新特性) plan后面带的节点的名字必须是已经存在的,并且是需要均衡的节点。 如果节点不存在,会报如下错误: 如果节点只有一个硬盘的话,不会创建均衡计划: (1)生成均衡计划 hdfs diskbalancer -plan hadoop102 (2)执行均衡计划 hd

【Prometheus】PromQL向量匹配实现不同标签的向量数据进行运算

✨✨ 欢迎大家来到景天科技苑✨✨ 🎈🎈 养成好习惯,先赞后看哦~🎈🎈 🏆 作者简介:景天科技苑 🏆《头衔》:大厂架构师,华为云开发者社区专家博主,阿里云开发者社区专家博主,CSDN全栈领域优质创作者,掘金优秀博主,51CTO博客专家等。 🏆《博客》:Python全栈,前后端开发,小程序开发,人工智能,js逆向,App逆向,网络系统安全,数据分析,Django,fastapi

搭建Kafka+zookeeper集群调度

前言 硬件环境 172.18.0.5        kafkazk1        Kafka+zookeeper                Kafka Broker集群 172.18.0.6        kafkazk2        Kafka+zookeeper                Kafka Broker集群 172.18.0.7        kafkazk3

烟火目标检测数据集 7800张 烟火检测 带标注 voc yolo

一个包含7800张带标注图像的数据集,专门用于烟火目标检测,是一个非常有价值的资源,尤其对于那些致力于公共安全、事件管理和烟花表演监控等领域的人士而言。下面是对此数据集的一个详细介绍: 数据集名称:烟火目标检测数据集 数据集规模: 图片数量:7800张类别:主要包含烟火类目标,可能还包括其他相关类别,如烟火发射装置、背景等。格式:图像文件通常为JPEG或PNG格式;标注文件可能为X

pandas数据过滤

Pandas 数据过滤方法 Pandas 提供了多种方法来过滤数据,可以根据不同的条件进行筛选。以下是一些常见的 Pandas 数据过滤方法,结合实例进行讲解,希望能帮你快速理解。 1. 基于条件筛选行 可以使用布尔索引来根据条件过滤行。 import pandas as pd# 创建示例数据data = {'Name': ['Alice', 'Bob', 'Charlie', 'Dav