调度器

在k8s集群中,能运行pod资源的只有工作节点,master 主要是做为控制平面组件 (api-server, contarner-manage, 调度器), 也依赖于etcd(最好能有冗余能力)

节点创建流程

  1. 当用户发起请求向Api Server 要求创建一个新的Pod资源对象时, Api Server先检查权限、授权、准入控制皆无问题,
  2. 然后将请求交给scheduler(调度器), 然后从集群中的work节点中匹配一个此Pod资源的运行节点, 调度器的选择结果并不会直接产生对应的Pod资源,而是会告诉 Api Server, 并且会将结果记录到Etcd中,实现持久化功能,
  3. 而每一个节点上的 Kubelet会一直监听着Api Server与自己节点相关连的事件变动, 当 Api Server发生变动时, 这个变动节点上的Kubelet会尝试获取Api server中定义的Pod清单,并且根据这个清单去创建一个Pod,
  4. 在创建这个Pod时会根据image或ImagePolicy下载或从私有仓库下载,如果是私有仓库那么它会检查对应的SA,当SA通过下载镜像并根据清单创建Pod(容器),
  5. 如果还有PVC那么还得根据相对应的存储创建PV
  6. 在创建和运行时,Pod有生命周期,我们此时在前端加一个serivces以提供一个固定的访问端点
  7. 而services并不是一个实实在在的组件,它其实只是每一个节点上的iptables或ipvs规则
  8. 当用户通过任意api调用的接口创建service时,这个请求也会向api service发送
  9. kubeproxy会监控着跟api service资源的变动,而后把创造成当前节点上的iptables或ipvs规则,kubeproxy是管理service资源的重要组件

节点过滤

  1. Volumes Filters:如果某一个Pod要求要使用本地的临时存储,而且需要至少有20G的存储空间,正好所有节点当中有的节点有20G有的节点没有20G,那么没有20G的就会被排除掉;
  2. Resources Filters:如果某一节点要求resource,CPU至少有四核,那么CPU也需要经过一次筛选;
  3. Topology Filters:

节点挑选

调度器是如何决策哪一个Pod在哪一个节点上运行的,简单来说 当用户创建Pod资源对象时,有一组节点可以选择, 调度器会从集群中的节点挑出一个匹配的,default scheduler通过三级来挑选节点

  1. 排除此Pod完全不符合的节点, 比如 Predicate(预选)
  • 当前资源占用
  • 资源限额
  • 最低资源需求 (1c、2G内存),
  • 比如污点,当我们节点有污点而Pod不能容忍该污点,那么这些所有不能容忍的污点就会被排队在外,只能留下没有污点的或者此Pod能容忍的污点的节点
  1. 优选策略, priority(优选)
  • 基于一系列的算法,函数把每一个节点的属性输出进去 ,然后计算每一个节点的优先级,在进行排序
  1. 选定节点: Selector
  • 如果还是有多个节点,那就随机挑选一个

基本工作流程

        对于预选,k8s会有很多预选器也会参与挑选节点是否符合Pod的基本要求,对于Predicate来讲,它是一个或者一组程序,会将Kubernetes之上的所有节点拿来,进行一次计算,如果其中有一组程序声明这个节点不符合运行此Pod的条件,那么这就被预选排除了,以此类推,这些左右节点都经过这一组Predicate进行评估之后,留下的都是至少能符合运行此Pod的基本条件;

        于是这些节点谁是最好的,因此就需要进入第二步,Priority也是有一组优先函数组成的,这个函数不像Predicate它合不合理,而评估的是这个节点和运行此Pod的评估分数,比如node1进来,进入第一个Priority函数计算得两分,进入第二个Priority函数计算得三分,最终所有的Priority函数的分值的和就是这个node节点的整体得分分值,而后基于得分进行排序,逆序排序;

​        排完序之后,就看得分最高的有几个,然后会将得分最高的挑选出来,进入Select流程,进行随机挑选;

在这里插入图片描述

调度器流程

当我们未定义调度器的时候,直接使用默认值,准入控制器会为我们补齐该字段,

# 查看已创建的Pod调度器默认值 
]# kubectl get pods -n dev my-dev-6568b4bdb-b4zmf -o yaml | grep schedulerName
  schedulerName: default-scheduler
预先策略

pod以及节点对象

  • CheckNodeCondition: 检查是否可以在节点磁盘、网络或未准备好的前提下能够将Pod调度上来;
  • GeneralPredicates: 通用预先策略,它并不是一个单独的预选策略,如
    • HostName: 对应的节点上Pod名称未被使用, 检查Pod对象是否定义了 pod.spec.hostname;
    • PodFitsHostPorts: pod.spec.containers.ports.hostport,如果pod指定了hostport那么该pod就会绑定在节点的这个端口,如果占用那么就不会匹配这个节点;
    • MatchNodeselector: pods.spec.nodeSelector,匹配与节点选择器一致的节点, 节点亲和性;
    • PodFitsResoures: 检查节点是否有足够资源支撑这个pod运行;
  • NoDiskConflict: 检查Pod依赖的存储卷是否满足需求, [ 以下默认没有启用] ;
  • PodToleratesNodeTaints:检查Pod上的pod.spec.tolerations可容忍污点是否完全包含节点上的污点;
  • PodToleratesNodeNoExecuteTaints: [未启];
  • CheckNodeLabelPresence: 检查标签存在性, [未启];
  • CheckServiceAffinity: 根据当前Pod对象所属的service,Pod可以属于一个或多个serivce [未启] ;

存储资源

  • CheckVolumeBinding: 检查存储绑定关系
  • NoVolumeZoneConflict: 是否为NoVolume指定区域

底层资源

  • CheckNodeMemoryPressure: 检查内存节点是否处于压力过大的情况
  • CheckNodePidPressure: 检查节点pid进程过多的情况
  • CheckNodeDiskPressure: 检查磁盘是否将满

亲和性

  • MatchInterPodAffinity: pod之间的亲和性
优先函数

如果定义多个, 得分分值越高挑选越大

  • leastRequested: 有节点的空闲资源,与节点的总容量进行对比
  • 算法:cpu((capacity-sum(request))*10/capacity)+memeory((capacity-sum(request))*10/capacity/2 说明:cpu*((总容量-已用容量)*10/总容量)+内存((总容量-已用容量)*10/总容量/2)
  • BalancedResourceAllocation: Cpu和内存资源占用均衡越平均,优先级越高
  • CPU和 内存资源被占用率相近胜出
  • NodePreferAvoidPods: 节点倾向不要运行这个pod
  • 根据节点注解信息来判定 “scheduler.alpha.kubernetes.io/preferAvoidPods”, 存在此注解得分为 0
  • TaintToleration: 基于pod资源对节点污点的容忍度调度偏好,
  • 将pod对象的spec.tolerations列表项与节点的taints列表项进行匹配度检查,匹配的条目越多得分越低;
  • SelectorSpreading: 查找与Pod对象匹配的services,(rs, deploy, sts)
  • 已经运行此类Pod对象的节点越少,得分度越高
  • InterPodAffinity:
  • 遍历Pod对象的亲和性条目,并将能够匹配到节点的权重相加,结果值越大,得分越高
  • NodeAffinity: 节点亲和性,
  • MostReuqestd: [未启]
    • 与 leastRequested 相反,不同时使用, 使用越多,优先级越高,直到占用100%
  • NodeLabel: 根据节点特定标签得分,只要有标签就行 [未启]
  • ImageLocality: 根据满足当前Pod对象需求的镜像的体积大小之和 [未启]
selector

当一个Pod被调度的时候,所有通过预选策略的node都会进行一些硬性条件检查,而后经过优选策略进行软性分值计算,而后通过分值进行排序,接下来进行选择阶段了,最高分胜出;

  • 节点倾向性

    nodeName:     节点名称
    nodeSelector: 节点挑选, 节点倾向性
    
  • Pod亲和性

    • 某些个Pod运行在同一节点,或相邻节点
  • 污点

    • 给某些节点打上污点,这样Pod在挑选时如果能容忍这个节点那么就能运行在这个节点之上, 如这个pod有十个污点,而这个节点有五个污点并且是有Pod亲和性的子集
    • Taints: 节点之上的污点
    • Tolerations: Pod之上的污点

k8s调度器

​        一般来讲当我们创建Pod时都会被kube-scheduler当中的default-scheduler调取,目前来讲,k8s内部只有一个调度器,但是它支持插件式调度器,允许用户自定义调度器对接到已有的调度程序上;我们可以在外部施加各种条件,来影响调度结果,比如在定义Pod时,在spec字段中加上nodeName或nodeSelector来影响它的调度结果,或指定匹配node节点,如果没有节点被匹配,那它就会被Pending,这种就属于硬性调度机制

​        也可以有一些柔性调度机制,比如Affinity,亲和性也分硬亲和和软亲和,硬亲和指的是,如果满足它的亲和性,它就可以把node作为调度节点,如果不满足,就直接排除,而软亲和指的是如果我们经过亲和性检测,发现没有一个节点符合这个亲和性,那么就随机亲和;

        当然我们也可以使用污点, 从上面描述的来看可以看出node都是等待着被选择,那么我们也可以赋予node的主动权,给node加上一个污点,如果节点不能容忍这个污点,那么就不会调度上面来,这就给了node主动控制权;

高级调度设计

如果在某些特定场景当中,我们期望通过自己的预设来影响它的预先和优选过程,从而使得调度操作符合我们期望,此类的影响方式通常有如下几种:

  1. 节点选择器: nodeSelector, nodeName
  2. 节点亲和调度: nodeAffinity

节点选择器

  • nodeName:如果我们期望将pod调度到某一特定的节点上,直接指定nodeName节点名称就行
]# cat nodeName-1.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: pod-node-select
spec:
  containers:
  - name: pod-node-select
    image: ikubernetes/myapp:v1
    imagePullPolicy: IfNotPresent 
  nodeName: slave1     # 将节点指定至slave1的节点上 通过kubectl get nodes查看节点 
  
  nodeName: slave11    # 如果节点不存在,那么该pod会一直Pending等待该节点
  # pod-node-select-2    0/1     Pending     slave3
  • nodeSelector: 给一部分节点打上特有标签,节点通过nodeSelector匹配

    ]# kubectl explain pod.spec.nodeSelector  # 可查看对应参数
    
    # 通过 kubectl label 添加标签  kubectl label node slave1 disk=ssd
    
    # 通过给一些节点添加标签,然后通过 nodeSelector 选择更具有亲和性一些的节点,比如 全固态跑数据库
    ]# cat nodeSelecto-1.yaml 
    apiVersion: v1
    kind: Pod
    metadata:
      name: pod-select-1
    spec:
      containers:
      - name: pod-select-1
        image: ikubernetes/myapp:v1
        imagePullPolicy: IfNotPresent
      nodeSelector:   # kubectl get node --show-labels, 或通过 kubectl label node 打标
        disk: ssd
    

节点亲和调度

查看节点亲和性调度参数: ~]# kubectl explain pods.spec.affinity

  1. 同时指定nodeAffinity和nodeSeletor,那么他们是“与”关系,即符合条件的Node需要同时满足两个条件;
  2. 为nodeAffinity同时指定多个nodeSelectorTerms时,各条目间取逻辑“或”关系,即满足一个条件即可;
  3. 同一个nodeSeletorTerms中的多个matchExpression存在逻辑“与”关系,即Node需要同时满足多个条件;
  4. 如果调度以及完成了,后来将节点的label删除了,导致这个节点不能再满足这个亲和性了,那么已调度的Pod不会被remove,这个亲和性仅仅发生在调度的过程当中,调度完成后label的变动将不再有任何影响;

.nodeAffinity

节点亲和性

# kubectl explain pods.spec.affinity.nodeAffinity

# preferredDuringSchedulingIgnoredDuringExecution  软亲和性, 尽量满足的条件,不满足也可以
	preference: 节点选择
	weight: 权重 1-100

# requiredDuringSchedulingIgnoredDuringExecution  硬亲和性,必须要满足的条件,不满足一定不运行pending状态
    nodeSelectorTerms: 节点选择器
        matchExpressions: 匹配正则表达式
        	operator参数: In,NotIn, Exists, DoesNotExist. Gt, and Lt
        matchFields:      匹配字段
硬亲和性
# 硬亲和性,必须要满足,不满足就pending
]# cat nodeAffinity-required-1.yaml
apiVersion: v1
kind: Pod
metadata:
  name: nodeaffinity-hard-1
spec:
  containers:
  - name: nodeaffinity-hard-1
    image: ikubernetes/myapp:v1
    imagePullPolicy: IfNotPresent
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: disk      # key为disk
            operator: In   # disk的value值应当包含 ssd或 pcie
            values:       # 只要满足这些条件,Pod就会运行在这个节点之上
            - ssd         # 不满足就会一直处于pending的状态
            - pcie
软亲和性
]# cat nodeAffinity-required-2.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: nodeaffinity-soft-2
spec:
  containers:
  - name: nodeaffinity-soft-2
    image: ikubernetes/myapp:v1
    imagePullPolicy: IfNotPresent
  affinity:
    nodeAffinity:
     # 软亲和性,当条件不满足时,使用默认的default-schedule挑选节点
      preferredDuringSchedulingIgnoredDuringExecution:
      - preference:
          matchExpressions:
          - key: disk
            operator: In
            values:
            - pcie
        weight: 30

.podAffinity

Pod亲和性调度,调度器随机将第一个Pod选择一个位置,然后第二个Pod会根据第一个Pod进行调度。Pod亲和性并不强制限制在同一个节点,也可以是相近的节点(或拥有一样标签)
~]# 通过 kubectl explain pods.spec.affinity.podAffinity 查看选项

        对于Pod资源来讲,在运行过程中因为Pod之间的关系,可能会根据业务需求将其运行在同一个或不能在同一个节点上,像这种高级调度控制器,称之为Pod间的Affinity或Anti-Affinity,这两种调度关系分别为亲和性、反亲和性;

        Pod亲和性主要用于描述两个Pod之间能否运行于同一位置,同一位置可能是同一机房,同一节点,同一集群等,因此在定义Pod亲和性时,我们必须有一个机制来人为定义何为同一位置,有一个专门的字段,叫做topologyKey;

​        如果要使用Pod亲和性来调度,只需要在Pod的spec下面的affinity字段当中使用podAffinity或者使用podAntiAffinity来定义即可,但是Pod的亲和性和反亲和性有一个要求,如果要使用Pod亲和性,假如有三百个节点,每调度一个Pod都需要评估这个Pod和其他Pod是不是在同一个位置,可能会遍历每一个节点查询位置是不是一样的,所以评估过程就被拖慢,因此在较大的规模的集群当中,反而不是特别适合于使用podAffinity,或者不易于使用较细的粒度进行区分同一位置;

        podAntiAffinity指的是几个Pod一定不能在同一个位置,Pod的podAntiAffinity严格要求集群当中的每一个节点,都必须设置正确的标签,否则没法评估到底是不是反亲和性的,否则反亲和性就无法工作,因此Pod的亲和性调度,还是有着较大局限性的;

preferredDuringSchedulingIgnoredDuringExecution  软亲和性

requiredDuringSchedulingIgnoredDuringExecution   硬亲和性
	labelSelector:指定一组目标Pod资源
	namespaces:   指定labelSelector是哪一组名称空间
	topologyKey:  位置拓扑键, 相同即是同一位置,只能有一个key
亲和性
]# cat podAffinity-hard.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: pod-affinity-p-1
  labels:
    app: pod-affinity-1
spec:
  containers:
  - name: podaffinity-1
    image: ikubernetes/myapp:v1
    imagePullPolicy: IfNotPresent
---
apiVersion: v1
kind: Pod
metadata:
  name: pod-affinity-m-2
  labels:
    app: pod-affinity-2
spec:
  containers:
  - name: podaffinity-1
    image: ikubernetes/myapp:v1
    imagePullPolicy: IfNotPresent
  affinity:
    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector: 
          matchExpressions:
          - key: app
            operator: In
            values: ["pod-affinity-1"]
        topologyKey: kubernetes.io/hostname  # 选择相同的逻辑节点或同一区域的物理节点,硬亲和性,指定必须运行在同一个区域节点相匹配亲和性 Pod的机房,通过 kubectl get nodes --show-labels 查看labels 

]# kubectl get pods -o wide
NAME                         READY   STATUS    IP            NODE
pod-affinity-m-2             1/1     Running   10.244.2.6    slave2
pod-affinity-p-1             1/1     Running   10.244.2.5    slave2

demo-2

#  slave 1  slave2  运行 tj-pod  
#  pod2 亲和 tj-pod这个pod , 但是pod2 依赖于 slave1 天津机房
#  kubectl labels node slave jf=tj

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-execution
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-execution
  template:
    metadata:
      labels:
        app: my-execution
    spec:
      containers:
      - name: my-execution
        image: ubuntu:latest
        imagePullPolicy: IfNotPresent
        command: ["/bin/sh"]
        args: ["-c", "while true;do sleep 10;done"]
        resources:
          limits:
            memory: "10Mi"
            cpu: "5m"
          requests:
            memory: "10Mi"
            cpu: "5m"
---
apiVersion: v1
kind: Pod
metadata:
  name: tj-pod
  labels:
    name: tj-pod
spec:
  affinity:
    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - topologyKey: jf
        labelSelector:
          matchExpressions:
            - key: app    # 这里是pod亲和, 需要选择的是pod的标签而不是node的
              operator: In
              values: 
              - my-execution
          # matchLabels: jf: bj
  containers:
  - name: tj-pod
    image: ubuntu:latest
    command:
      - sleep
      - "3600"
    resources:
      limits:
        memory: "10Mi"
        cpu: "5m"
      requests:
        memory: "10Mi"
        cpu: "5m"
反亲和性
# 将两个节点加至同一个区域,测试反亲和性如果在同一个区域, 反亲和节点是否运行
]# kubectl label nodes slave1 zone=bj 
]# kubectl label nodes slave2 zone=bj

]# cat podAffinity-anti.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: pod-affinity-anti-p-1
  labels:
    app: pod-affinity-anti-1
spec:
  containers:
  - name: podaffinity-anti-1
    image: ikubernetes/myapp:v1
    imagePullPolicy: IfNotPresent
---
apiVersion: v1
kind: Pod
metadata:
  name: pod-affinity-anti-m-2
  labels:
    app: pod-affinity-anti-2
spec:
  containers:
  - name: podaffinity-anti-1
    image: ikubernetes/myapp:v1
    imagePullPolicy: IfNotPresent
  affinity:
    podAntiAffinity:  # 反亲和性,与定义的Pod运行节点刚好相反的
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector: 
          matchExpressions:
          - key: app
            operator: In
            values: ["pod-affinity-anti-1"]
        topologyKey: zone       # 选择为zone的逻辑或物理位置节点 

]# kubectl get pods -o wide
NAME                         READY   STATUS   IP            NODE    
pod-affinity-anti-m-2        0/1     Pending  <none>        <none>  
pod-affinity-anti-p-1        1/1     Running  10.244.1.13   slave1  

# 将 slave2 的zone label删除, 反亲和性的Pod会立即运行到与之相反的节点。
]# kubectl label nodes slave2 zone-
]# kubectl get pods -o wide
NAME                         READY   STATUS   IP            NODE  
pod-affinity-anti-m-2        1/1     Running  10.244.2.8    slave2
pod-affinity-anti-p-1        1/1     Running  10.244.1.13   slave1

污点和容忍度

  • 无论是NodeAffinity还是PodAffinity还是PodAntiAffinity都是Pod选择运行在哪个节点上,他们都是基于Pod选节点的,所以无论是哪一个都是我们的节点等待被选择,Taints这种机制使得我们的节点可以反对Pod被调度,或接纳Pod调度的主控权, 从而能够使得节点在必要时可以排斥它不期望运行的Pod
  • 与NodeAffinity或者PodAffinity不同的是,它必须要结合Tolerations才能协同工作的,也就是说一旦一个节点打上了污点之后Pod能不能调度到这个节点上要取决于这个Pod上有没有对应污点的容忍度,以将来要基于污点来调度的话,那就必须要确保在节点上能够有污点,在Pod上有容忍度,否则的话,任何不能容忍这个污点的Pod都无法调度上来,从而使得该节点可以用于运行特定类型的Pod;

污点参数

taint的effect定义对Pod排斥效果, 当Pod不能容忍这个污点时,采取的行为

参数说明
Noschedule仅影响调度过程,对现存的Pod对象不产生影响,
如果不容忍就不允许调度过来
NoExecute不仅影响调度还影响现存Pod对象, 不容忍Pod对象将被驱逐
PreferNoschedule不容忍会影响调度,但最终还是能被允许

Tolerations匹配Taints

  1. key必须相同;
  2. value必须相同;
  3. effect必须相同;

容忍度评估

  1. 等值比较-Equal: 我们定义容忍度,表示容忍度与污点在key,value和effect完全匹配
  2. 存在性判断-Exists:两者的key与effect必须完全匹配,但是value可以使用空值,只需要判断存不存在,一个节点可以有多个污点,一个Pod对象也可以有多个容忍度,两者在做匹配时要遵循
污点使用

Command: kubectl taint node nodename key=value:effect参数

  • 添加污点

    # 给节点打上污点
    ~]# kubectl taint node slave2 node-type=qa:NoSchedule
    
    # 删除污点
    ~]# kubectl taint node slave2 node-type-
     
    # 查看节点的污点情况
    ~]# kubectl get nodes slave2  -o yaml
        spec:
          podCIDR: 10.244.2.0/24
          podCIDRs:
          - 10.244.2.0/24
          taints:
          - effect: NoSchedule
            key: node-type
            value: qa
    
    # 给节点打上污点
    ~]# kubectl taint node slave1 node-type=dev:NoExecute
     
    # 查看节点的污点情况
    ~]# kubectl get nodes slave2  -o yaml
        spec:
          podCIDR: 10.244.1.0/24
          podCIDRs:
          - 10.244.1.0/24
          taints:
          - effect: NoExecute
            key: node-type
            value: dev
    
  • 定义Pod污点容忍度

~]# kubectl explain deploy.spec.template.spec.tolerations 容忍污点
   effect   # 污点级别参数  
   key:     # 节点定义的taints key
   operator: # 污点评估值 Exists and Equal
   tolerationSeconds:# 容忍时间,定义可以忍受在一段时间内的驱逐 单位: 秒
   value: # 节点定义的 taints value
   
# 先定义一个普通的Pod查看 是否能够运行
]# cat deploy-effect.yaml 
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-myapp-effect
  labels:
    app: my-effect-first
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-effect-first
  template:
    metadata:
      name: my-myapp-effect
      labels:
        app: my-effect-first
    spec:
      containers:
      - name: my-myapp-effect
        image: ikubernetes/myapp:v1
        imagePullPolicy: IfNotPresent
        
# 当没有定义污点时,节点的NoSchedule 不允许没有定义Pod 容忍度的容器运行
  • 添加污点-Equal
spec:
  # Pod内容不变
  template:
    # Pod内容不变
    spec:
      # Pod内容不变
      tolerations:
      - effect: NoSchedule
        key: node-type
        operator: Equal  # 当定义 Equal时  key value必须相等
        value: "qa"

]# kubectl get pods -o wide
NAME                              READY   STATUS   IP            NODE  
my-myapp-effect-6964b5756-cdmzs   1/1     Running  10.244.2.9    slave2
my-myapp-effect-6964b5756-j2mpm   1/1     Running  10.244.2.10   slave2
my-myapp-effect-6964b5756-js42g   1/1     Running  10.244.2.11   slave2
  • Exists
tolerations:
- effect: NoExecute
  key: node-type
  operator: Exists   # 只需要 key跟effect能相等,那么就能匹配到对应节点的污点
  value: ""          # 此处需为空, 通配符匹配 
  
]# kubectl get pods -o wide
NAME                               READY   STATUS   IP            NODE   
my-myapp-effect-65f65f8784-j8k2w   1/1     Running  10.244.1.14   slave1 
my-myapp-effect-65f65f8784-s6n4t   1/1     Running  10.244.1.15   slave1 
my-myapp-effect-65f65f8784-vftnh   1/1     Running  10.244.1.16   slave1 
  • effect不添加等值时
tolerations:
- effect: ""         # 啥都不加 匹配所有
  key: node-type     # key必须要有
  operator: Exists   # 只需要 key跟effect能相等,那么就能匹配到对应节点的污点
  value: ""          # 此处需为空, 通配符匹配 

# Pod会随机挑选一个节点运行。

k8s内建污点

Kubernetes在1.6之后引入了几个表达节点问题的几个污点,他们由Node Controller根据节点的实际状态在需要时自动添加;

key说明
node.kubernetes.io/not-ready节点未就绪
node.kubernetes.io/unreachable节点不可达
node.kubernetes.io/unreachable磁盘耗尽
node.kubernetes.io/out-of-disk内存耗尽
node.kubernetes.io/disk-pressure磁盘耗尽
node.kubernetes.io/network-unavailable网络不可用
node.kubernetes.io/unschedulable不可被调度
node.kubernetes.io/uninitialized未被初始化
Logo

K8S/Kubernetes社区为您提供最前沿的新闻资讯和知识内容

更多推荐