关于topology-spread-constraints的一些随记

来自三线的随记
Admin讨论 | 贡献2024年8月16日 (五) 01:15的版本 (创建页面,内容为“k8s中有个特性叫做 topology-spread-constraints,利用此特性能做到将pod尽量均匀分布在不同节点或者拓扑域上(根据topologyKey决定) 简单解释: <blockquote>maxSkew意思是 同一个拓扑域中,假设拓扑域 key 就是节点名,部分节点有污点,maxSkew假设为1 假设拓扑域中有ABCD四个节点,pod需要4个副本,A节点有污点 这时候节点BCD能各调度一个pod,但是A节点由于有污点,…”)
(差异) ←上一版本 | 最后版本 (差异) | 下一版本→ (差异)

k8s中有个特性叫做 topology-spread-constraints,利用此特性能做到将pod尽量均匀分布在不同节点或者拓扑域上(根据topologyKey决定)

简单解释:

maxSkew意思是

同一个拓扑域中,假设拓扑域 key 就是节点名,部分节点有污点,maxSkew假设为1

假设拓扑域中有ABCD四个节点,pod需要4个副本,A节点有污点

这时候节点BCD能各调度一个pod,但是A节点由于有污点,所以禁止调度到A节点,这时候第四个pod只能调度到BCD节点,但是BCD已经有一个pod了,这时候A节点没有同一服务的任何pod,所以此时集群的maxSkew为1

同时因为有DoNotSchedule,导致这种情况下,第四个pod不允许调度到BCD节点,因为调度上去以后maxskew会变成 2

利用这个特性能够比配置 强反亲和 或 弱反亲和 来实现POD尽可能在一个拓扑域打散分布有效(强反亲和固定同拓扑域中只能有一个副本,弱反亲和没办法尽力打散,会受到很多其他因素影响调度)


但是在使用的时候,如果是deployment类型pod,需要注意要把 pod-template-hash 作为 key 添加到 topologySpreadConstraints 的 matchLabelKeys 中(matchLabelKeys: # optional; beta since v1.27)

否则会造成,多副本的 deployment 在 rolling update 的时候(delete pod 没办法,算是一个小的难受点),terminating pod 也会被纳入计算,进而导致即使在DoNotSchedule模式下,POD 副本数依然不是绝对均匀


同样需要注意,在 k8s v1.26 中,topology-spread-constraint 还引入了 nodeAffinityPolicy 等配置,会影响Skew的计算结果(默认为Honor: only nodes matching nodeAffinity/nodeSelector are included in the calculations.)


https://kubernetes.io/docs/concepts/scheduling-eviction/topology-spread-constraints/