最近遇到了这段代码:
kubernetes/pkg/scheduler/framework/plugins/volumezone/volume_zone.go
第220行到第224行:
| | if!hasAnyNodeConstraint { |
| | // 节点没有区域约束,所以我们可以调度。 |
| | // 这是处理单区域集群场景,其中节点可能没有任何拓扑标签。 |
| | returnnil |
| | } |
这段代码的意思是:如果一个节点没有以下拓扑标签
kubernetes/pkg/scheduler/framework/plugins/volumezone/volume_zone.go
第79行到第84行:
| | vartopologyLabels= []string{ |
| | v1.LabelFailureDomainBetaZone, |
| | v1.LabelFailureDomainBetaRegion, |
| | v1.LabelTopologyZone, |
| | v1.LabelTopologyRegion, |
| | } |
即使Pod通过PVC绑定请求的PV具有拓扑信息,它仍然可以适应Pod。但是,如果我们阅读PV的拓扑信息为“硬调度要求”,这看起来并不正确。我认为我们应该跳过对节点标签的检查;相反,将其留给后面的podPVTopologies
检查。这样,任何非空的podPVTopologies
都将被评估,因此只有与PV拓扑匹配的节点才能成为调度候选。否则,在部分节点未正确标记(带有拓扑信息)的环境中,这将导致意外行为:将Pod调度到PV不可访问的节点上,从而导致运行时错误。
7条答案
按热度按时间mnowg1ta1#
/sig scheduling
/sig storage
/cc @cofyc@msau42@ddebroy what's your take on this?
vsmadaxz2#
/cc
d7v8vwbk3#
这是一个很好的捕获,是的,我认为如果节点没有任何区域标签,那么允许。我不认为我们应该完全删除检查,因为我们可能会破坏单个节点的情况。标记节点和标记PV的控制器是不同的。
q0qdq0h24#
/triage accepted
wqnecbli5#
/kind bug
z9ju0rcb6#
我认为我们不应该完全移除检查,因为我们可能会破坏单个节点的情况。标记节点的控制器和标记PV的控制器是不同的。
如果这里的意图是处理
single node case
,我认为我们可以在预过滤器中检查节点编号,并在filter
中移除约束检查?xghobddn7#
这个问题已经超过一年没有更新了,应该重新进行优先级评估。
你可以:
/triage accepted
(仅组织成员)相关/close
关闭这个问题有关优先级评估过程的更多详细信息,请参见 https://www.kubernetes.dev/docs/guide/issue-triage/
已接受移除优先级评估