关于topology-spread-constraints的一些随记
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/