调度架构
Kubernetes 调度架构
调度单元
Pod 调度
当新增一个
- 节点状态为不可用的,如,节点不通或者
K8s 服务运行异常等; - 节点剩余的
CPU, 内存资源不足以运行容器的; - 容器运行时占用的宿主机端口出现冲突的;
- 按照节点选择
label 不匹配的;
然后通过打分机制决定将
# 标准打分公式
score = (权重 * 评价策略分值) + (weight1 * priorityFunc1) + (weight2 * priorityFunc2) + ...
# LeastRequestedPriority
score = cpu((capacity - sum(requested)) * 10 / capacity) + memory((capacity - sum(requested)) * 10 / capacity) /2
# BalanceResourceAllocation
score = 10 -abs (cpuFraction - memoryFraction) * 10
cpuFraction = requested / capacity; memoryFraction = requested / capacity
# CalculateSpreadPriority
score = 10 * ((maxCount -counts) / (maxCount))
-
LeastRequestedPriority: CPU 可用资源为100 ,运行容器申请的资源为15 ,则cpu 分值为8.5 分,内存可用资源为100 ,运行容器申请资源为20 ,则内存分支为8 分。则此评价规则在此节点的分数为(8.5 +8) / 2 = 8.25 分。 -
BalanceResourceAllocation: CPU 可用资源为100 ,申请10 ,则cpuFraction 为0.1 ,而内存可用资源为20 ,申请10 ,则memoryFraction 为0.5 ,这样由于CPU 和内存使用不均衡,此节点的得分为10-abs ( 0.1 - 0.5 ) * 10 = 6 分。假如CPU 和内存资源比较均衡,例如两者都为0.5 ,那么代入公式,则得分为10 分。 -
CalculateSpreadPriority: 一个web 服务,可能存在5 个实例,例如当前节点已经分配了2 个实例了,则本节点的得分为10 _ ((5-2) / 5) = 6 分,而没有分配实例的节点,则得分为10 _ ((5-0) / 5) = 10 分。没有分配实例的节点得分越高。
资源保障
目前,
Guaranteed
如果
containers:
name: foo
resources:
limits: //只设置了limits
cpu: 10m
memory: 1Gi
name: bar
resources:
limits:
cpu: 100m
memory: 100Mi
requests: //requests 和 limits均已设定,并且值相同
cpu: 100m
memory: 100Mi
Burstable
当以下情形设置,limits
。
Pod 里的一个或多个容器只设置了requests
参数。Pod 里的一个或多个容器同时设置了requests
和limits
参数,但是两者值不一样。Pod 里的所有容器均设置了limits
,但是他们的类型不一样,不如容器1 只定义了CPU ,容器2 只定义了Memory 。Pod 里存在多个容器时,其中存在容器可被定义为Bustable 条件的Pod 也是Bustable 类型,比如有两个容器,容器1 设置了limits
,容器2 没有任何设置。
containers:
name: foo
resources:
limits:
memory: 1Gi
name: bar
resources:
limits:
cpu: 100m
name: duck
BestEffort
当
containers:
name: foo
resources:
name: bar
resources: