发生了什么?
我成功在最新的主要分支上复现了 a bug that went stale ,并注意到了一个可能触发此 bug 的新情况。ImageLocality
插件可能会在不同情况下给节点相同的分数。
相关代码:
imageScores := sumImageScores(nodeInfo, pod, totalNumNodes, logger, nodeName)
score := calculatePriority(imageScores, len(pod.Spec.InitContainers)+len(pod.Spec.Containers), logger)
func calculatePriority(sumScores int64, numContainers int, logger klog.Logger) int64 {
maxThreshold := maxContainerThreshold * int64(numContainers)
if sumScores < minThreshold {
sumScores = minThreshold
} else if sumScores > maxThreshold {
sumScores = maxThreshold
}
return framework.MaxNodeScore * (sumScores - minThreshold) / (maxThreshold - minThreshold)
}
当一个节点已经完全拉取了一个相对较小的镜像时,另一个节点还没有(但仍需要时间拉取,这种情况下镜像大小约为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。
apiVersion: v1
kind: Pod
metadata:
name: pod3
spec:
containers:
- name: test-container
image: gke.gcr.io/calico/cni:v3.23.1-gke.0
这里是日志(添加了一些日志以查看 image_locality 中发生了什么):
[image_locality.go:68] "ImageScores" logger="Score.ImageLocality" pod="default/nginx3" node="kind-worker" imageScores=25531886
[image_locality.go:93] "calculatePriority" logger="Score.ImageLocality" pod="default/nginx3" node="kind-worker" minThreshold=24117248 maxThreshold=1048576000 framework.MaxNodeScore=100
[image_locality.go:68] "ImageScores" logger="Score.ImageLocality" pod="default/nginx3" node="kind-worker2" imageScores=0
[image_locality.go:93] "calculatePriority" logger="Score.ImageLocality" pod="default/nginx3" node="kind-worker2" minThreshold=24117248 maxThreshold=1048576000 framework.MaxNodeScore=100
[image_locality.go:112] ImageName="gke.gcr.io/calico/cni:v3.23.1-gke.0" Size="76595659" node="kind-worker"
...
[schedule_one.go:784] "Plugin scored node for pod" pod="default/nginx3" plugin="ImageLocality" node="kind-worker" score=0
...
[schedule_one.go:784] "Plugin scored node for pod" pod="default/nginx3" plugin="ImageLocality" node="kind-worker2" score=0
[schedule_one.go:851] "Calculated node's final score for pod" pod="default/nginx3" node="kind-worker" score=492
[schedule_one.go:851] "Calculated node's final score for pod" pod="default/nginx3" node="kind-worker2" score=492
我们需要了解其他任何信息吗?
- 无响应*
Kubernetes 版本
$ kubectl version
# paste output here
客户端版本:v1.29.1
服务器版本:v1.30.0-
5条答案
按热度按时间bnl4lu3b1#
这个问题目前正在等待分类。
如果SIG或子项目确定这是一个相关的问题,他们将通过应用
triage/accepted
标签并提供进一步的指导来接受它。组织成员可以通过在评论中写入
/triage accepted
来添加triage/accepted
标签。有关使用PR评论与我互动的说明,请查看here。如果您对我的行为有任何问题或建议,请针对kubernetes/test-infra仓库提出一个问题。
vwhgwdsa2#
/sig scheduling
hof1towb3#
/cc
muk1a3rh4#
Kubernetes项目目前缺乏足够的贡献者来充分应对所有问题。
此机器人根据以下规则对未分类的问题进行分级处理:
lifecycle/stale
应用后的90天不活动后,将应用lifecycle/stale
lifecycle/stale
应用后的30天不活动后,将应用lifecycle/rotten
lifecycle/rotten
应用后的30天不活动后,该问题将被关闭您可以:
/remove-lifecycle stale
/close
关闭此问题请将反馈发送至sig-contributor-experience@kubernetes/community。
/lifecycle stale
mtb9vblg5#
/remove-lifecycle stale