7.k8s.调度器scheduler 亲和性、污点

#k8s. 调度器scheduler 亲和性、污点

默认调度过程:预选 Predicates (过滤节点) --> 优选 Priorities(优先级排序) --> 优先级最高节点
实际使用,根据需求控制Pod调度,需要用到如下:
指定节点、nodeAffinity(节点亲和性)、podAffinity(pod 亲和性)、 podAntiAffinity(pod 反亲和性)

#指定调度节点

# Pod.spec.nodeName 强制匹配,直接指定Node 节点,跳过 Scheduler 调度策略
#node-name-demo.yaml
apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: demo-nodename
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: demo1
    spec:
      nodeName: node03  #指定Node节点
      containers:
      - name: demo1
        image: alivv/nginx:node
        ports:
        - containerPort: 80
#部署
kubectl apply -f node-name-demo.yaml
#查看pod全部在node03上 (node03节点不存在会一直处于pending)
kubectl get pod -o wide
#删除
kubectl delete -f node-name-demo.yaml
# Pod.spec.nodeSelector 强制约束,调度策略匹配 label,调度 Pod 到目标节点
#node-selector-demo.yaml
apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: demo-node-selector
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: demo1
    spec:
      nodeSelector:
        test1: node  #匹配lable test1=node
      containers:
      - name: demo1
        image: alivv/nginx:node
        ports:
        - containerPort: 80
#部署
kubectl apply -f node-selector-demo.yaml

#查看pod处于pending
kubectl get pod -o wide
#给node02节点添加lable
kubectl label nodes node02 test1=node
kubectl get nodes --show-labels
#再次查看pod在node02节点
kubectl get pod -o wide

#删除
kubectl delete -f node-selector-demo.yaml
kubectl label nodes node02 test1-

亲和性调度

亲和性调度可以分成软策略硬策略两种方式

  • preferredDuringSchedulingIgnoredDuringExecution:软策略,没满足条件就忽略,Pod可以启动
  • requiredDuringSchedulingIgnoredDuringExecution:硬策略,没满足条件就等待,Pod处于Pending

操作符

  • In:label 的值在某个列表中
  • NotIn:label 的值不在某个列表中
  • Gt:label 的值大于某个值
  • Lt:label 的值小于某个值
  • Exists:某个 label 存在
  • DoesNotExist:某个 label 不存在

#节点亲和性 pod.spec.nodeAffinity

#node-affinity-demo.yaml
apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: node-affinity
  labels:
    app: affinity
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: affinity
    spec:
      containers:
      - name: nginx
        image: alivv/nginx:node
        ports:
        - containerPort: 80
          name: nginxweb
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:  #硬策略,不在node01节点
            nodeSelectorTerms:
            - matchExpressions:
              - key: kubernetes.io/hostname
                operator: NotIn
                values:
                - node01
          preferredDuringSchedulingIgnoredDuringExecution:  #软策略,优先匹配test2=node
          - weight: 1
            preference:
              matchExpressions:
              - key: test2
                operator: In
                values:
                - node
#给node03节点添加lable
kubectl label nodes node03 test2=node
kubectl get nodes --show-labels

#部署
kubectl apply -f node-affinity-demo.yaml

#查看pod
kubectl get pod -o wide

#删除
kubectl delete -f node-affinity-demo.yaml
kubectl label nodes node03 test2-

#Pod亲和性pod.spec.affinity.podAffinity/podAntiAffinity

podAffinity Pod亲和性,解决 pod 部署在同一个拓扑域 、或同一个节点
podAntiAffinity Pod反亲和性,避开Pod部署在一起

#pod-affinity-demo.yaml
apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: pod-affinity-demo
  labels:
    app: pod-affinity
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: pod-affinity
    spec:
      containers:
      - name: nginx
        image: alivv/nginx:node
        ports:
        - containerPort: 80
          name: nginxweb
      affinity:
        podAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:  #硬策略
          - labelSelector:  #匹配Pod有 app=demo1
              matchExpressions:
              - key: app
                operator: In
                values:
                - demo1
            topologyKey: kubernetes.io/hostname
#部署
kubectl apply -f pod-affinity-demo.yaml

#查看pod全部处于Pending 因为没标签app=demo1的Pod
kubectl get pod -o wide

#部署上面的node-name-demo.yaml
kubectl apply -f  node-name-demo.yaml
#再次查看pod全部在node03节点
kubectl get pod -o wide
#Pod反亲和性测试
#改podAffinity为podAntiAffinity
sed -i 's/podAffinity/podAntiAffinity/' pod-affinity-demo.yaml
kubectl apply -f pod-affinity-demo.yaml

#查看node03节点移除pod-affinity-demo
kubectl get pod -o wide
#删除
kubectl delete -f pod-affinity-demo.yaml
kubectl delete -f node-name-demo.yaml

# 污点taints与容忍tolerations

节点标记为 Taints ,除非 pod可以容忍污点节点,否则该 Taints 节点不会被调度pod
kubeadm安装k8s,默认master节点会添加NoSchedule 类型污点

#污点设置 kubectl taint nodes node-name key=value:effect
#key 和 value 为污点标签, value 可以为空,effect 描述污点的作用,effect 支持如下三个选项:

  • NoSchedule 不会将 Pod 调度到有污点的 Node
  • PreferNoSchedule 避免将 Pod 调度到有污点的 Node
  • NoExecute 不会将 Pod 调度到有污点的 Node ,将已经存在的 Pod 驱逐出去
#给node03添加污点
kubectl taint nodes node03 test-taint=node:NoSchedule
#查看
kubectl describe node node03 |grep Taints

#容忍 pod.spec.tolerations

#pod-tolerations-demo.yaml
apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: pod-tolerations-demo
  labels:
    app: pod-tolerations
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: pod-tolerations
    spec:
      containers:
      - name: nginx
        image: alivv/nginx:node
        ports:
        - containerPort: 80
          name: http
#创建Pod
kubectl apply -f pod-tolerations-demo.yaml

#查看Pod,node03节点有污点将不会创建Pod
kubectl get pod -o wide

#文件pod-tolerations-demo.yaml追加容忍污点配置
echo '#容忍污点
      tolerations:
      - key: "test-taint"
        #value: "node"
        operator: "Exists"  #忽略value值
        effect: "NoSchedule"
'>>pod-tolerations-demo.yaml
cat pod-tolerations-demo.yaml

#更新
kubectl apply -f pod-tolerations-demo.yaml
#Pod扩容
kubectl scale deployment pod-tolerations-demo --replicas 5

#再次查看Pod,Node03有Pod
kubectl get pod -o wide
#删除Pod
kubectl delete -f pod-tolerations-demo.yaml
#删除污点
kubectl taint nodes node03 test-taint-

#不指定 key 值时,容忍所有的污点 key

tolerations:
- operator: "Exist

#不指定 effect 值时,表示容忍所有的污点作用

tolerations:
- key: "key"
  operator: "Exist"

#避免资源浪费,设置master运行Pod,可以如下配置:

kubectl taint nodes --all  node-role.kubernetes.io/master- #先删除默认污点
kubectl taint nodes Node-Name node-role.kubernetes.io/master=:PreferNoSchedule

Blog地址 https://www.cnblogs.com/elvi/p/11755828.html
本文git地址 https://gitee.com/almi/k8s/tree/master/notes

原文地址:https://www.cnblogs.com/elvi/p/11755828.html

时间: 2024-10-12 23:41:37

7.k8s.调度器scheduler 亲和性、污点的相关文章

从零开始入门 K8s | 调度器的调度流程和算法介绍

导读:Kubernetes 作为当下最流行的容器自动化运维平台,以声明式实现了灵活的容器编排,本文以 v1.16 版本为基础详细介绍了 K8s 的基本调度框架.流程,以及主要的过滤器.Score 算法实现等,并介绍了两种方式用于实现自定义调度能力. 调度流程 调度流程概览 Kubernetes 作为当下最主流的容器自动化运维平台,作为 K8s 的容器编排的核心组件 kube-scheduler 将是我今天介绍的主角,如下介绍的版本都是以 release-1.16 为基础,下图是 kube-sch

(5)调度器(scheduler)

继承关系 原理介绍 Cocos2d-x调度器为游戏提供定时事件和定时调用服务.所有Node对象都知道如何调度和取消调度事件,使用调度器有几个好处: 每当Node不再可见或已从场景中移除时,调度器会停止. Cocos2d-x暂停时,调度器也会停止.当Cocos2d-x重新开始时,调度器也会自动继续启动. Cocos2d-x封装了一个供各种不同平台使用的调度器,使用此调度器你不用关心和跟踪你所设定的定时对象的销毁和停止,以及崩溃的风险. 基础用法 游戏中我们经常会随时间的变化而做一些逻辑判断,如碰撞

Cocos2d-X3.0 刨根问底(六)----- 调度器Scheduler类源码分析

上一章,我们分析Node类的源码,在Node类里面耦合了一个 Scheduler 类的对象,这章我们就来剖析Cocos2d-x的调度器 Scheduler 类的源码,从源码中去了解它的实现与应用方法. 直入正题,我们打开CCScheduler.h文件看下里面都藏了些什么. 打开了CCScheduler.h 文件,还好,这个文件没有ccnode.h那么大有上午行,不然真的吐血了, 仅仅不到500行代码.这个文件里面一共有五个类的定义,老规矩,从加载的头文件开始阅读. #include <funct

cocos2dx调度器(scheduler)

调度器(scheduler) http://cn.cocos2d-x.org/article/index?type=cocos2d-x&url=/doc/cocos-docs-master/manual/framework/native/v3/scheduler/zh.md

K8S调度之pod亲和性

[toc] Pod Affinity 通过<K8S调度之节点亲和性>,我们知道怎么在调度的时候让pod灵活的选择node,但有些时候我们希望调度能够考虑pod之间的关系,而不只是pod与node的关系.于是在kubernetes 1.4的时候引入了pod affinity. 为什么有这样的需求呢?举个例子,我们系统服务 A 和服务 B 尽量部署在同个主机.机房.城市,因为它们网络沟通比较多:再比如,我们系统数据服务 C 和数据服务 D 尽量分开,因为如果它们分配到一起,然后主机或者机房出了问题

Yarn 调度器Scheduler详解

理想情况下,我们应用对Yarn资源的请求应该立刻得到满足,但现实情况资源往往是有限的,特别是在一个很繁忙的集群,一个应用资源的请求经常需要等待一段时间才能的到相应的资源.在Yarn中,负责给应用分配资源的就是Scheduler.其实调度本身就是一个难题,很难找到一个完美的策略可以解决所有的应用场景.为此,Yarn提供了多种调度器和可配置的策略供我们选择. 一.调度器的选择 在Yarn中有三种调度器可以选择:FIFO Scheduler ,Capacity Scheduler,FairS ched

Yarn 组件的指挥部 – 调度器Scheduler

linux基础 为hadoop集群的搭建扫清了障碍,也为内存的管理,文件系统的管理扫清了障碍 接着到Hadoop的阶段,首先做集群的安装,深入到使用这两个核心的组件,分布式文件系统HDFS,解决大量数据怎么存储的问题,第二个就是分布式计算MapReduce.MapReduce的包含Yarn和MapReduce,随着集群规模的扩大,资源的管理必要用一个单独的组件Yarn来管理,程序员只要关注如何来写程序就好了. 然后讲了Zookeeper: 轻量级组件,往大数据集群里导数据的,比如Sqoop和Fl

调度器(scheduler)

调度器(schedule)为游戏提供定时事件和定时调用服务. 调度器(schedule)的功能和事件监听器(eventlistener)的功能有点类似:都是在特定情况下调用某个事先准备好的回调函数. 不同之处在于:事件监听器需要通过手动触发(Trigger)来调用这个准备好的回调函数,而调度器是需要等到游戏运行了一个时间段(delta_time)后来调用这个回调函数 一般会把调度器封装成一个类: 一.需要一个注册回调函数的接口,这个接口的参数可能包括1:time,指需要运行多久后调用注册好的回调

k8s调度器优先级和抢占机制

优先级(Priority)和抢占(Preemption)机制 优先级和抢占机制,解决的是Pod调度失败时该怎么办的问题 正常情况下,当一个Pod调度失败后,它就会被暂时“搁置”起来,直到Pod被更新,或者集群状态发生变化,调度器才会对这个Pod进行重新调度 特殊要求的场景: 当一个高优先级的Pod调度失败后,该Pod并不会被“搁置”,而是会“挤走”某个Node上的一些低优先级的Pod.这样就保证这个高优先级Pod的调度成功 优先级的实现 需要在Kubernetes里提交一个PriorityCla