kubernetes 调度器:ImageLocality 给处于不同情况的节点相同的分数,

p8ekf7hl  于 10个月前  发布在  Kubernetes
关注(0)|答案(5)|浏览(97)

发生了什么?
我成功在最新的主要分支上复现了 a bug that went stale ,并注意到了一个可能触发此 bug 的新情况。
ImageLocality 插件可能会在不同情况下给节点相同的分数。
相关代码:

  1. imageScores := sumImageScores(nodeInfo, pod, totalNumNodes, logger, nodeName)
  2. score := calculatePriority(imageScores, len(pod.Spec.InitContainers)+len(pod.Spec.Containers), logger)
  3. func calculatePriority(sumScores int64, numContainers int, logger klog.Logger) int64 {
  4. maxThreshold := maxContainerThreshold * int64(numContainers)
  5. if sumScores < minThreshold {
  6. sumScores = minThreshold
  7. } else if sumScores > maxThreshold {
  8. sumScores = maxThreshold
  9. }
  10. return framework.MaxNodeScore * (sumScores - minThreshold) / (maxThreshold - minThreshold)
  11. }

当一个节点已经完全拉取了一个相对较小的镜像时,另一个节点还没有(但仍需要时间拉取,这种情况下镜像大小约为70MB)

具有完全拉取的镜像的节点与 minThreshold 太接近,而另一个没有该镜像的节点的原始 sumScores = 0。因此,在剪辑两个节点的 sumScores 之间的差异后,与 maxThreshold - minThreshold 相比,这个差异相对较小。
然后插件计算分数,这将发生:第一个节点的分数 = 100 * 0.0001 = 0 ,第二个节点的分数 = 100 * 0 = 0 。即使第一个节点已经完全拉取了这个大约70MB的镜像(第一个节点),第二个节点还没有,结果也会相同。

我认为这也发生在一个节点有许多相对较大的镜像,另一个节点没有(第二个节点也有一些镜像,但不如第一个大)的情况下。 然后第一个节点的 sumScores 远远超过了 maxThreshold ,第二个节点的 sumScores 只比 maxThreshold 小一点。剪辑后,第一个节点的 sumScores 变成了 maxThreshold

然后插件计算分数,这将发生:第一个节点的分数 = 100 * 1 = 100 ,第二个节点的分数 = 100 * 0.999 = 100 。即使第一个节点的镜像远多于第二个节点,结果也会相同。

你期望会发生什么?

ImageLocality 应该给两个节点不同的分数。

我们如何尽可能精确地重现它(最小化和精确化)?

首先创建两个节点(worker1 已完全拉取镜像,worker2 刚开始拉取),然后应用以下规格的 pod。

  1. apiVersion: v1
  2. kind: Pod
  3. metadata:
  4. name: pod3
  5. spec:
  6. containers:
  7. - name: test-container
  8. image: gke.gcr.io/calico/cni:v3.23.1-gke.0

这里是日志(添加了一些日志以查看 image_locality 中发生了什么):

  1. [image_locality.go:68] "ImageScores" logger="Score.ImageLocality" pod="default/nginx3" node="kind-worker" imageScores=25531886
  2. [image_locality.go:93] "calculatePriority" logger="Score.ImageLocality" pod="default/nginx3" node="kind-worker" minThreshold=24117248 maxThreshold=1048576000 framework.MaxNodeScore=100
  3. [image_locality.go:68] "ImageScores" logger="Score.ImageLocality" pod="default/nginx3" node="kind-worker2" imageScores=0
  4. [image_locality.go:93] "calculatePriority" logger="Score.ImageLocality" pod="default/nginx3" node="kind-worker2" minThreshold=24117248 maxThreshold=1048576000 framework.MaxNodeScore=100
  5. [image_locality.go:112] ImageName="gke.gcr.io/calico/cni:v3.23.1-gke.0" Size="76595659" node="kind-worker"
  6. ...
  7. [schedule_one.go:784] "Plugin scored node for pod" pod="default/nginx3" plugin="ImageLocality" node="kind-worker" score=0
  8. ...
  9. [schedule_one.go:784] "Plugin scored node for pod" pod="default/nginx3" plugin="ImageLocality" node="kind-worker2" score=0
  10. [schedule_one.go:851] "Calculated node's final score for pod" pod="default/nginx3" node="kind-worker" score=492
  11. [schedule_one.go:851] "Calculated node's final score for pod" pod="default/nginx3" node="kind-worker2" score=492

我们需要了解其他任何信息吗?

  • 无响应*

Kubernetes 版本

  1. $ kubectl version
  2. # paste output here

客户端版本:v1.29.1
服务器版本:v1.30.0-

bnl4lu3b

bnl4lu3b1#

这个问题目前正在等待分类。
如果SIG或子项目确定这是一个相关的问题,他们将通过应用triage/accepted标签并提供进一步的指导来接受它。
组织成员可以通过在评论中写入/triage accepted来添加triage/accepted标签。
有关使用PR评论与我互动的说明,请查看here。如果您对我的行为有任何问题或建议,请针对kubernetes/test-infra仓库提出一个问题。

vwhgwdsa

vwhgwdsa2#

/sig scheduling

hof1towb

hof1towb3#

/cc

muk1a3rh

muk1a3rh4#

Kubernetes项目目前缺乏足够的贡献者来充分应对所有问题。
此机器人根据以下规则对未分类的问题进行分级处理:

  • lifecycle/stale应用后的90天不活动后,将应用lifecycle/stale
  • lifecycle/stale应用后的30天不活动后,将应用lifecycle/rotten
  • lifecycle/rotten应用后的30天不活动后,该问题将被关闭

您可以:

  • 将此问题标记为新鲜的/remove-lifecycle stale
  • 使用/close关闭此问题
  • 提供帮助,请使用Issue Triage

请将反馈发送至sig-contributor-experience@kubernetes/community
/lifecycle stale

展开查看全部
mtb9vblg

mtb9vblg5#

/remove-lifecycle stale

相关问题