15 资源调度

于 2023-02-21 14:18:54 发布
阅读量99 收藏
点赞数
分类专栏： k8s 文章标签： kubernetes docker 运维
原文链接：https://www.yuque.com/waynehe/k8s/hgfmel
版权

nodeSelector

基础理论

nodeSelector 是节点选择约束的最简单推荐形式。nodeSelector 是 PodSpec 的一个字段。 它包含键值对的映射。为了使 pod 可以在某个节点上运行，该节点的标签中必须包含这里的每个键值对（它也可以具有其他标签）。最常见的用法的是一对键值对。

使用nodeSelector

查看节点标签

[root@clientvm ~]# kubectl get nodes --show-labels
NAME                  STATUS   ROLES    AGE   VERSION   LABELS
master.example.com    Ready    master   17d   v1.19.4   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=master.example.com,kubernetes.io/os=linux,node-role.kubernetes.io/master=
worker1.example.com   Ready    <none>   17d   v1.19.4   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=worker1.example.com,kubernetes.io/os=linux
worker2.example.com   Ready    <none>   17d   v1.19.4   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=worker2.example.com,kubernetes.io/os=linux

给节点打标签

[root@clientvm ~]# kubectl label nodes worker1.example.com disk=ssd
node/worker1.example.com labeled

使用nodeSelector调度Pod

[root@clientvm ~]# cat nodeSelector-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: nginx-nodeselector
  labels:
    env: test
spec:
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent
  nodeSelector:
    disk: ssd

[root@clientvm ~]# kubectl apply -f nodeSelector-pod.yaml
pod/nginx-nodeselector created

[root@clientvm ~]# kubectl get pod -o wide
NAME                                              READY   STATUS      RESTARTS   AGE    IP            NODE                  NOMINATED NODE   READINESS GATES
nginx-nodeselector                                1/1     Running     0          19s    10.244.1.57   worker1.example.com   <none>           <none>

NodeName

基础理论

nodeName 是节点选择约束的最简单方法，但是由于其自身限制，通常不使用它。nodeName 是 PodSpec 的一个字段。如果它不为空，调度器将忽略 pod，并且运行在它指定节点上的 kubelet 进程尝试运行该 pod。因此，如果 nodeName 在 PodSpec 中指定了，则它优先于上面的节点选择方法。 如果指定的节点不存在，将调度失败。

使用NodeName

[root@clientvm ~]# cat nodeName.yaml
apiVersion: v1
kind: Pod
metadata:
  name: nginx-nodename
  labels:
    env: test
spec:
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent
  nodeName: worker1.example.com

[root@clientvm ~]# kubectl apply -f nodeName.yaml
pod/nginx-nodename created

[root@clientvm ~]# kubectl get pod nginx-nodename -o wide
NAME             READY   STATUS    RESTARTS   AGE   IP            NODE                  NOMINATED NODE   READINESS GATES
nginx-nodename   1/1     Running   0          37s   10.244.1.58   worker1.example.com   <none>           <none>

亲和度

基础理论

nodeSelector 提供了一种非常简单的方法来将 pod 约束到具有特定标签的节点上。亲和/反亲和功能极大地扩展了你可以表达约束的类型。关键的增强点是

  1. 语言更具表现力（不仅仅是“完全匹配的 AND”）
  2. 你可以发现规则是“偏好”，而不是硬性要求，因此，如果调度器无法满足该要求，仍然调度该 pod
  3. 你可以使用节点上的 pod 的标签来约束，而不是使用节点本身的标签，来允许哪些 pod 可以或者不可以被放置在一起。
    亲和功能包含两种类型的亲和，即“节点亲和”和“pod 间亲和/反亲和”。节点亲和就像现有的nodeSelector，然而 pod 间亲和/反亲和约束 pod 标签而不是节点标签。

目前有两种类型的节点亲和，分别为 **requiredDuringSchedulingIgnoredDuringExecution **和 preferredDuringSchedulingIgnoredDuringExecution。你可以视它们为“硬”和“软”，意思是，前者指定了将 pod 调度到一个节点上必须满足的规则（就像 nodeSelector 但使用更具表现力的语法），后者指定调度器将尝试执行但不能保证的偏好。

使用节点亲和

[root@clientvm deploy]# kubectl label nodes worker1.example.com app=web
node/worker1.example.com labeled
[root@clientvm deploy]# kubectl label nodes worker2.example.com disk=hybrid
node/worker2.example.com labeled

[root@clientvm ~]# cat node-affinity.yaml
apiVersion: v1
kind: Pod
metadata:
  name: with-node-affinity
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: disk
            operator: In
            values:
            - ssd
            - hybrid
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 1
        preference:
          matchExpressions:
          - key: app
            operator: In
            values:
            - web
  containers:
  - name: with-node-affinity
    image: nginx
    imagePullPolicy: IfNotPresent

[root@clientvm ~]# kubectl apply -f node-affinity.yaml
pod/with-node-affinity created

[root@clientvm ~]# kubectl get pod with-node-affinity -o wide
NAME                 READY   STATUS    RESTARTS   AGE   IP            NODE                  NOMINATED NODE   READINESS GATES
with-node-affinity   1/1     Running   0          13s   10.244.1.59   worker1.example.com   <none>           <none>

重新调度

[root@clientvm deploy]# kubectl label nodes worker1.example.com disk-
node/worker1.example.com labeled

[root@clientvm ~]# kubectl delete -f node-affinity.yaml
pod "with-node-affinity" deleted
[root@clientvm ~]#
[root@clientvm ~]# kubectl apply -f node-affinity.yaml
pod/with-node-affinity created

[root@clientvm ~]# kubectl get pod with-node-affinity -o wide
NAME                 READY   STATUS    RESTARTS   AGE   IP            NODE                  NOMINATED NODE   READINESS GATES
with-node-affinity   1/1     Running   0          4s    10.244.2.73   worker2.example.com   <none>           <none>

pod 间亲和与反亲和

pod 间亲和与反亲和使你可以基于已经在节点上运行的 pod 的标签来约束 pod 可以调度到的节点，而不是基于节点上的标签。规则的格式为“如果 X 节点上已经运行了一个或多个 满足规则 Y 的pod，则这个 pod 应该（或者在非亲和的情况下不应该）运行在 X 节点”。

使用Pod亲和

[root@clientvm ~]# cat pod-affinity.yaml
apiVersion: v1
kind: Pod
metadata:
  name: with-pod-affinity
spec:
  affinity:
    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: run
            operator: In
            values:
            - nginx2
        topologyKey: disk
    podAntiAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 100
        podAffinityTerm:
          labelSelector:
            matchExpressions:
            - key: security
              operator: In
              values:
              - S2
          topologyKey: disk
  containers:
  - name: with-pod-affinity
    image: nginx
    imagePullPolicy: IfNotPresent

[root@clientvm ~]# kubectl apply -f pod-affinity.yaml
pod/with-pod-affinity created

[root@clientvm ~]# kubectl get pod with-pod-affinity -o wide
NAME                READY   STATUS    RESTARTS   AGE   IP            NODE                  NOMINATED NODE   READINESS GATES
with-pod-affinity   1/1     Running   0          14s   10.244.2.74   worker2.example.com   <none>           <none>

使用topologyKey限制包含该键的所有Node

污点和容忍度

Taint（污点）与亲和性相反，它使节点能够排斥一类特定的 Pod。
容忍度（Tolerations）是应用于 Pod 上的，允许（但并不要求）Pod 调度到带有与之匹配的污点的节点上。
污点和容忍度（Toleration）相互配合，可以用来避免 Pod 被分配到不合适的节点上。 每个节点上都可以应用一个或多个污点，这表示对于那些不能容忍这些污点的 Pod，是不会被该节点接受的。

kubectl taint nodes node1 key1=value1:NoSchedule

给节点 node1 增加一个污点，它的键名是 key1，键值是 value1，效果是 NoSchedule。 这表示只有拥有和这个污点相匹配的容忍度的 Pod 才能够被分配到 node1 这个节点。

若要移除上述命令所添加的污点，你可以执行：

kubectl taint nodes node1 key:NoSchedule-

NoSchedule：这表示只有拥有和这个污点相匹配的容忍度的 Pod 才能够被分配到 node1 这个节点。NoExecute ：任何不能忍受这个污点的 Pod 都会马上被驱逐。
用例：

  • 专用节点：如果您想将某些节点专门分配给特定的一组用户使用，您可以给这些节点添加一个污点（即， kubectl taint nodes nodename dedicated=groupName:NoSchedule）， 然后给这组用户的 Pod 添加一个相对应的 toleration（通过编写一个自定义的 准入控制器，很容易就能做到）。
  • 配备了特殊硬件的节点：在部分节点配备了特殊硬件（比如 GPU）的集群中， 我们希望不需要这类硬件的 Pod 不要被分配到这些特殊节点，以便为后继需要这类硬件的 Pod 保留资源。 要达到这个目的，可以先给配备了特殊硬件的节点添加 taint （例如 kubectl taint nodes nodename special=true:NoSchedule 或 kubectl taint nodes nodename special=true:PreferNoSchedule)， 然后给使用了这类特殊硬件的 Pod 添加一个相匹配的 toleration。
  • 基于污点的驱逐: 这是在每个 Pod 中配置的在节点出现问题时的驱逐行为。
    范例：
[root@clientvm ~]# cat taint.yaml
apiVersion: v1
kind: Pod
metadata:
  name: nginx-taint
  labels:
    env: test
spec:
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent
  tolerations:
  - key: "GPU"
    operator: "Exists"
    effect: "NoSchedule"

[root@clientvm ~]# kubectl apply -f taint.yaml
pod/nginx-taint created

[root@clientvm ~]# kubectl get pod nginx-taint -o wide
NAME          READY   STATUS    RESTARTS   AGE   IP            NODE                  NOMINATED NODE   READINESS GATES
nginx-taint   1/1     Running   0          15s   10.244.1.60   worker1.example.com   <none>           <none>

[root@clientvm ~]# kubectl taint nodes worker1.example.com  GPU=yes:NoExecute
node/worker1.example.com tainted
[root@clientvm ~]# kubectl get pod nginx-taint -o wide
Error from server (NotFound): pods "nginx-taint" not found

[root@clientvm ~]# kubectl apply -f taint.yaml
pod/nginx-taint created
[root@clientvm ~]# kubectl get pod  -o wide
NAME                     READY   STATUS      RESTARTS   AGE    IP            NODE                  NOMINATED NODE   READINESS GATES
nginx-taint              1/1     Running     0          2s     10.244.2.76   worker2.example.com   <none>           <none>

operator 的默认值是 Equal。
一个容忍度和一个污点相“匹配”是指它们有一样的键名和效果，并且：

  • 如果 operator 是 Exists （此时容忍度不能指定 value），或者
  • 如果 operator 是 Equal ，则它们的 value 应该相等
    说明：
    存在两种特殊情况：
  • 如果一个容忍度的 key 为空且 operator 为 Exists， 表示这个容忍度与任意的 key 、value 和 effect 都匹配，即这个容忍度能容忍任意 taint。
  • 如果 effect 为空，则可以与所有键名 key1 的效果相匹配。

例如，假设您给一个节点添加了如下污点

kubectl taint nodes node1 key1=value1:NoSchedule 
kubectl taint nodes node1 key1=value1:NoExecute 
kubectl taint nodes node1 key2=value2:NoSchedule

假定有一个 Pod，它有两个容忍度：

tolerations:
- key: "key1"
  operator: "Equal"
  value: "value1"
  effect: "NoSchedule"
- key: "key1"
  operator: "Equal"
  value: "value1"
  effect: "NoExecute"

在这种情况下，上述 Pod 不会被分配到上述节点，因为其没有容忍度和第三个污点相匹配。 但是如果在给节点添加上述污点之前，该 Pod 已经在上述节点运行， 那么它还可以继续运行在该节点上，因为第三个污点是三个污点中唯一不能被这个 Pod 容忍的。

基于节点状态添加污点

控制平面使用节点控制器自动创建 与节点状况对应的带有 NoSchedule 效应的污点。当某种条件为真时，节点控制器会自动给节点添加一个污点。当前内置的污点包括：

  • node.kubernetes.io/not-ready：节点未准备好。这相当于节点状态 Ready 的值为 “False”。
  • node.kubernetes.io/unreachable：节点控制器访问不到节点. 这相当于节点状态 Ready 的值为 “Unknown”。
  • node.kubernetes.io/memory-pressure：节点存在内存压力。
  • node.kubernetes.io/disk-pressure：节点存在磁盘压力。
  • node.kubernetes.io/pid-pressure: 节点的 PID 压力。
  • node.kubernetes.io/network-unavailable：节点网络不可用。
  • node.kubernetes.io/unschedulable: 节点不可调度。

DaemonSet 控制器自动为所有守护进程添加如下 NoSchedule 容忍度以防 DaemonSet 崩溃：

  • node.kubernetes.io/memory-pressure
  • node.kubernetes.io/disk-pressure
  • node.kubernetes.io/pid-pressure
  • node.kubernetes.io/unschedulable
阿扎姆王子
关注
专栏目录
资源管理与调度
weixin_43470617的博客
07-25 785
日知录第四章
资源分配与调度
qq_51173978的博客
05-28 844
第五章 死锁 死锁:各进程互相等待对方手里的资源，导致各进程都阻塞，无法向前推进的现象。 饥饿:由于长期得不到想要的资源，某进程无法向前推进的现象。比如:在短进程优先(SPF) 算法中，若有源源不断的短进程到来，则长进程将一直得不到处理机，从而发生长进程“饥饿”。 死循环:某进程执行过程中- -直跳不出某个循环的现象。有时是因为程序逻辑bug导致的，有时是程序员故意设计的。 死锁产生条件 产生死锁必须同时满足一下四个条件， 只要其中任一条件不成立， 死锁就不会发生。 互斥条件:只有对必须互斥使用的资源的
操作系统资源调度
01-25
详细的资源调度，资源名、资源类型、最小分配单位的大小、地址、分配标志、描述器链接信息、存取权限、密级、存取时间 操作系统通过这些数据来感知到资源的存在，并对资源进行管理。
Hadoop Yarn 的三种资源调度器详解
Hadoop技术博文
08-08 6971
理想情况下，我们应用对Yarn资源的请求应该立刻得到满足，但现实情况资源往往是有限的，特别是在一个很繁忙的集群，一个应用资源的请求经常需要等待一段时间才能的到相应的资源。...
集群资源管理与调度
aq7218的博客
08-27 9667
资源管理方式 静态资源划分：将几圈中的所有资源做出静态划分，将划分后的固定的硬件资源指定给固定的计算框架使用，各框架之间各行其是，互不干扰。 缺点：资源整体利用率不高，经常会出现集群中有些计算系统资源不足，但是有些计算系统存在大量闲置资源的情形。 独立资源管理：在集群硬件层上抽象出一个功能独立的集群资源管理系统，将所有可用资源当成一个整体来进行管理，并对其他所有计算任务提供统一的资源管理与调度框架
LTE资源调度
qihongxu的博客
03-21 3万+
物理层的上一层MAC层传下来的数据叫作传输块（TB，Transport Blocks），物理层以1ms的调度周期对TB进行处理，最终通过天线发射出去。 物理层处理流程与典型通信系统发射机和接收机处理流程类似，具体到4G LTE中，对TB处理包括CRC、信道编码、交织（对抗衰落）、调制、层映射（MIMO）、资源映射等。 这些参数物理层需要提前知道才能开工，这些参数都是由上一层MAC层决定的，基站中有一个资源调取器逻辑上属于MAC层，它从物理层获取一些关键信息（如无线信道质量），通过算法得出各种参数，再告诉
基于语义搜索引擎的云资源调度
08-03
计算机应用研究论文 对现有云资源调度存在的非自动...仿真实验表明，基于 SSE 的云资源调度比传统的云资源调度的点对点通信性能提高了约 15% ，子任务执行时间减少了约 18% ，表明它是一种可行且高效的云资源调度方法。
Kubernetes资源调度
qq_58668102的博客
12-24 777
Kubernetes资源调度 深入理解Pod对象：调度 创建一个Pod的工作流程 Pod中影响调度的主要属性 资源限制对Pod调度的英雄 nodeSelector & nodeAffinity Tain（污点）& Tolerations（污点容忍） nodeName Kubernetes Scheduler 是 Kubernetes 控制平面的核心组件之一。它在控制平面上运行，将 Pod 分配给节点，同时平衡节点之间的资源利用率。将 Pod 分配给新节点后，在该节点上运行的 kubelet
解密微博红包：架构、防刷、监控和资源调度
02-01
春晚直播期间讨论春晚的微博达到5191万条，网友互动量达到1.15亿，网友抢微博红包的总次数超过8亿次。为此，InfoQ策划了“春节红包”系列文章，以期为读者剖析各大平台的红包活动背后的技术细节。本文为微博篇。随着...
资源调度问题——贪心算法
lala_wang的博客
07-19 6175
资源调度：给定等待服务的客户集合A = {1, 2, …, n}，预计对客户i的服务时间是ti，该客户希望的完成时间是di，即T = {t1, t2,…, tn}，D = {d1, d2,…, dn}。如果对客户i的服务在di之前结束，那么对客户i的服务没有延迟；如果在di之后结束，那么这个服务就被延迟了，延迟的时间等于该服务时间减去di。假设都是ti和di正整数，一个调度是函数f：A→N，其中是...
资源调度（学习笔记）
Hellomdk的博客
11-12 3369
文章目录资源调度流程 1，当集群启动时，各个worker向master汇报信息，封装到workerInfo类中，放入workers集合。 2，当客户端向集群提交Application时，首先会在客户端启动一个sparksubmit进程 3，为driver向Master申请资源，此时遍历workers集合，随机找一台资源充沛的worker节点，启动driver进程。 4，Driver启动成功后，向M...
Kubernetes3--资源动态调度
大魔王
11-24 3555
1.基于SLA驱动的资源动态调度算法 将应用分为不同类型，将不同应用调度到不同资源状态节点上，减少应用因资源不足带来的问题，根据SLA协议实时监控应用资源使用状况，动态调整应用资源占用率，提高资源使用率。 SLA协议：Service-Level Agreement的缩写，意思是服务等级协议。是关于网络服务供应商和客户间的一份合同，其中定义了服务类型、服务质量和客户付款等术语。 监控容器在一段...
LTE-TDD资源调度（1）-QCI、GBR和Non-GBR
热门推荐
阿米尔C 的技术博客
04-05 5万+
参考文献 （1）3GPP TS 23.203 V9.12.0 (2012-06) Policy and charging control architecture （2）3GPP TS 36.331 V9.18.0 (2014-06) Radio Resource Control (RRC) （3）3GPP TS 36.300 V9.10.0 (2012-12) Overall description （4）3GPP TS 36.413 V9.10.0 (2014-09) S1 Application Pr
一张图让你轻松搞定yarn资源调度流程
涤生大数据
12-03 1万+
1。yarn概述      Yarn是一个资源调度平台，负责为运算程序提供服务器运算资源，相当于一个分布式的操作系统平台，而mapreduce等运算程序则相当于运行于操作系统之上的应用程序   2.Yarn的重要概念 1）yarn并不清楚用户提交的程序的运行机制 2）yarn只提供运算资源的调度（用户程序向yarn申请资源，yarn就负责分配资源） 3）yarn中的主管角色叫Resour
Spark资源调度和任务调度过程介绍
helloxiaozhe的博客
08-09 6293
Spark资源调度和任务调度过程介绍(ps.未验证) 一、前述 Spark的资源调度是个很重要的模块，只要搞懂原理，才能具体明白Spark是怎么执行的，所以尤其重要。 自愿申请的话，本文分粗粒度和细粒度模式分别介绍。 二、具体 Spark资源调度流程图：               Spark资源调度和任务调度的流程：                  1、启动集群后，Worker...
LTE资源调度（8）-如何计算有效信道码率和Turbo编码码率
阿米尔C 的技术博客
05-30 2万+
今天是端午节，祝大家端午节快乐！这几天有时间，再更新一篇。考虑下行资源调度算法时，主要有两种码率需要考虑：第一种是有效信道码率(effective channel code rate)，第二种是Turbo编码码率。标准协议规定有效信道码率不能超过0.93，但对Turbo编码的码率没有做强制要求。在介绍如何计算有效信道码率和Turbo编码码率之前，简单了解一下下行共享信道的物理层处理过程是很有必要的
语义搜索引擎驱动的云资源优化调度
"基于语义搜索引擎的云资源调度" 在当前的云计算环境中，资源调度是一项至关重要的任务，它涉及到如何有效地分配和管理大量的计算、存储和网络资源，以满足不断变化的用户需求。传统的云资源调度方法往往存在非自动...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值