关于topology-spread-constraints的一些随记:修订间差异
小无编辑摘要 |
小无编辑摘要 |
||
第3行: | 第3行: | ||
简单解释: <blockquote>maxSkew意思是 | 简单解释: <blockquote>maxSkew意思是 | ||
同一个拓扑域中,假设拓扑域 key | 同一个拓扑域中,假设拓扑域 key 就是节点名,部分节点有污点或者计算资源已被其他pod请求占用到了上限,且maxSkew假设为1 | ||
假设拓扑域中有ABCD四个节点,pod需要4个副本,A节点有污点 | 假设拓扑域中有ABCD四个节点,pod需要4个副本,A节点有污点 |
2024年8月16日 (五) 01:20的最新版本
k8s中有个特性叫做 topology-spread-constraints,利用此特性能做到将pod尽量均匀分布在不同节点或者拓扑域上(根据topologyKey决定)
简单解释:
maxSkew意思是
同一个拓扑域中,假设拓扑域 key 就是节点名,部分节点有污点或者计算资源已被其他pod请求占用到了上限,且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.)
小声补充: 其实大多数情况下不应该追求绝对均匀(即不开启 DoNotSchedule),否则当k8s集群某些业务节点Not-Ready被打上污点以后,会导致被驱逐的pod无法满足拓扑约束进而无法被调度(除非把 nodeTaintsPolicy 也给配置用上,同样是自k8s 1.26启用,在计算skew的时候忽略有污点无法调度的节点[默认为不忽略] )
https://kubernetes.io/docs/concepts/scheduling-eviction/topology-spread-constraints/