kubernetes的调度机制
k8s的调度机制
scheduler组件
k8s调度器会将pod调度到资源满足要求并且评分最高的node上。
我们可以使用多种规则比如:
1.设置cpu、内存的使用要求;
2.增加node的label,并通过pod.Spec.NodeSelector进行强匹配;
3.直接设置pod的nodeName,跳过调度直接下发。
k8s 1.2加入了一个实验性的功能:affinity。意为亲和性。这个特性的设计初衷是为了替代nodeSelector,并扩展更强大的调度策略。
调度器的工作机制是这样的:
一、预备工作
1、缓存所有的node节点,记录他们的规格:cpu、内存、磁盘空间、gpu显卡数等;
2、缓存所有运行中的pod,按照pod所在的node进行区分,统计每个node上的pod request了多少资源。request是pod的QoS配置,可以参考之前的文章。
3、list & watch pod资源,当检查到有新的Pending状态的pod出现,就将它加入到调度队列中。
4、调度器的worker组件从队列中取出pod进行调度。
二、调度过程
1、先将当前所有的node放入队列;
2、执行predicates算法,对队列中的node进行筛选。这里算法检查了一些pod运行的必要条件,包括port不冲突、cpu和内存资源QoS(如果有的话)必须满足、挂载volume(如果有的话)类型必须匹配、nodeSelector规则必须匹配、硬性的affinity规则(下文会提到)必须匹配、node的状态(condition)必须正常,taint_toleration硬规则(下文会提到)等等。
3、执行priorities算法,对队列中剩余的node进行评分,这里有许多评分项,各个项目有各自的权重:整体cpu,内存资源的平衡性、node上是否有存在要求的镜像、同rs的pod是否有调度、node affinity的软规则、taint_toleration软规则(下文会提到)等等。
4、最终评分最高的node会被选出。即代码中suggestedHost, err := sched.schedule(pod)
一句(plugin/pkg/scheduler/scheduler.go
)的返回值。
5、调度器执行assume
方法,该方法在pod调度到node之前,就以“该pod运行在目标node上” 为场景更新调度器缓存中的node 信息,也即预备工作中的1、2两点。这么做是为了让pod在真正调度到node上时,调度器也可以同时做后续其他pod的调度工作。
6、调度器执行bind
方法,该方法创建一个Binding资源,apiserver检查到创建该资源时,会主动更新pod的nodeName
字段。完成调度。
nodeSelector
举例:
apiVersion: v1 kind: Pod metadata: name: nginx labels: env: test spec: containers: - name: nginx image: nginx imagePullPolicy: IfNotPresent nodeSelector: disktype: ssd
上面这个pod会且仅会被调度到带有disktype: ssd
这个label的node上。这是一种强规则,没有妥协,必须遵守。
affinity 和 anti-affinity
- 有亲和性规则,那么反亲和性规则肯定也要有。
- 亲和性规则实现了更丰富的规则表达方式。并且包含了nodeSelector的硬规则和另一种软规则。
- 软规则是一种优先规则,如果没有符合这个优先规则的节点,它仍然会被进行调度。
node亲和性
node亲和性和nodeSelector类似,通过label进行可调度node的过滤,现在有两种node亲和性:requiredDuringSchedulingIgnoredDuringExecution
和 preferredDuringSchedulingIgnoredDuringExecution
:
requiredDuringSchedulingIgnoredDuringExecution
强规则。和nodeSelector完全相同,以label进行强制的约束。需要指出的是:目前,如果一个node在运行时label发生了变化,变化后和其上运行的pod的requiredDuringSchedulingIgnoredDuringExecution
不再匹配,这个node上的pod也不会被驱逐,这个功能会在以后被改进,届时会增加一种类型RequiredDuringSchedulingRequiredDuringExecution
。
preferredDuringSchedulingIgnoredDuringExecution
软规则。举例来说:我们要将某个容器尽可能地调度到可用域X中,但如果不存在这个可用域或者可用域无法再运行pod,调度器也允许这个pod被调度到其他可用域。
以下是一个包含了强规则和软规则的案例:
apiVersion: v1 kind: Pod metadata: name: with-node-affinity spec: affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: kubernetes.io/e2e-az-name operator: In values: - e2e-az1 - e2e-az2 preferredDuringSchedulingIgnoredDuringExecution: - weight: 1 preference: matchExpressions: - key: another-node-label-key operator: In values: - another-node-label-value containers: - name: with-node-affinity image: gcr.io/google_containers/pause:2.0
该案例表明,这个pod只允许被调度到带有kubernetes.io/e2e-az-name=e2e-az1或e2e-az2
的label的node上,也即只允许被调度到e2e-az1或者e2e-az2两个可用域中;
另外,pod要尽量调度到包含another-node-label-key
的值为another-node-label-value
的node上。
matchExpressions
结构记录各种表达式,一个表达式包含key
,operator
,values
,分别表示关键字、关键字匹配关系、关键字匹配值。匹配关系包括:In
,NotIn
,Exists
,DoesNotExist
,Gt
,Lt
。NotIn
和DoesNotExist
是node anti-affinity的一种表现。
如果一个pod的描述信息中同时包含了nodeSelector
和nodeAffinity
,那么调度时两个规则都要满足。
如果一个nodeAffinity
中包含了多条nodeSelectorTerms
, 调度器只需要满足其中一条; 如果一个 nodeSelectorTerms
中记录了多条matchExpressions
,那么调度器要满足所有的matchExpressions
inter-pod affinity 和 anti-affinity
这两个特性都包含在1.4版本中,上面的亲和性是node亲和性,这个就是pod亲和性,简而言之,要把pod调度到某个node上,这个node上已有的pod能满足、或尽量满足某些条件。这个特性用pod.spec.affinity.podAffinity
和pod.spec.affinity.podAntiAffinity
来表示。
pod亲和性的规则可以这么表示:
这个pod应该(或者不应该)运行在节点X上,X上必须已经运行了一个或多个满足规则Y的pod。规则Y的表达方式类似于一个labelSelector并关联了一个namespace列表:namespaces
(若没有则表示“allnamespaces”),X可能是node或一个az,我们通过字段topologyKey
来规划X,即所有的X都要满足topologyKey
相同,一般topologyKey
是一个label的key。
为什么要有namespace列表?因为和node不同,pod是有分namespace的,因此pod的label也是有分namespace的。在这种情况下,规则Y必须要指明自己这个规则要适用于哪些namespace。比如node上运行的是hy
这个namespace下的pod,即便pod的label和规则Y的nodeSelector都相同,我们也视为不符合规则。
和node亲和性一样,pod亲和性也包含两个(硬规则和软规则):
requiredDuringSchedulingIgnoredDuringExecution
: 硬规则。preferredDuringSchedulingIgnoredDuringExecution
:
举个例子:
apiVersion: v1 kind: Pod metadata: name: with-pod-affinity spec: affinity: podAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: security operator: In values: - S1 topologyKey: failure-domain.beta.kubernetes.io/zone podAntiAffinity: preferredDuringSchedulingIgnoredDuringExecution: - weight: 100 podAffinityTerm: labelSelector: matchExpressions: - key: security operator: In values: - S2 topologyKey: kubernetes.io/hostname containers: - name: with-pod-affinity image: gcr.io/google_containers/pause:2.0
上面的pod模板使用了podAffinity的硬规则和podAntiAffinity的软规则。
- podAffinity规则中
topologyKey
是zone,也就是可用域,说明这条规则可以规划处调度到的域,首先,node上必须至少有一个running状态的pod包含key为security
,value为S1
的label。只要满足这个条件,那么这个node和其同一个域(拥有相同的failure-domain.beta.kubernetes.io/zone
为key,且值相同的label)的node均会被调度。 - podAntiAffinity规则中
topologyKey
是hostname,表明该规则约定了某种node尽量不会被调度到,这种node上已经运行了包含key为security
,value为S2
的label的pod。 - 假如现在有node a,b,c,其中a和b拥有相同的zone,且b上运行了一个pod,这个pod有一个label,key为
security
,value为S1
。那么我们创建如上的一个亲和性规则的3副本时,三个副本都会被调度到a或者b上。假如b上同时运行了一个pod,这个pod有一个label,key为security
,value为S2
,那么所有的副本都会调度到node a上。
taint toleration
node 可以被打上污点标记,并配置污点容忍策略。而pod的描述信息中如果包含了相同的污点容忍策略,就可以被调度到这个node上,反之则不可、或尽量不允许。
硬性规则
给node a 打上污点 name=huang, 策略为不可调度:kubectl taint nodes a name=huang:NoSchedule
若我创建的pod中包含如下描述:
tolerations:
- key: "name"
operator: "Equal"
value: "huang"
effect: "NoSchedule"
则这个pod可以容忍有这类污点的node,即可以调度到node a,当然,也可以用如下的描述:
tolerations:
- key: "name"
operator: "Exist"
effect: "NoSchedule"
类似的硬性规则体现在effect
字段中,还有NoExecute
,它比NoSchedule
更严格,不止pod不能调度上去,node上原有的pod如果不能容忍污点,就会被驱逐(eviction),配合字段tolerationSeconds
可以规定这些会被驱逐的pod能在node上呆多久。
软规则
除了NoExecute
,NoSchedule
,还有一条软规则:PreferNoSchedule
.配置effect=PreferNoSchedule
后,没有相关污点策略的pod会尽量避免调度到该node上。