Pod 一直处于Pending状态？可能是拓扑约束的问题
共 2636字，需浏览 6分钟
· 2023-06-21
Sealos 公众号已接入了 GPT-4，完全免费！欢迎前来调戏👇
❝原文链接：https://juejin.cn/post/7245179553886486584
起因：今天在部署组件的时候，发现组件的 pod 一直处于 Pending 状态，报错显示的原因是：不满足 Pod 拓扑分布约束，看了代码发现是原来同事给组件新增了 Pod 拓扑约束。对于 Pod 拓扑约束，我先前并没有认真了解过，刚好可以借这个排查问题的机会深入了解什么是 Pod 拓扑约束。
❝文档参考：
kubernetes.io/zh-cn/docs/…[1]
文档参考主要是上述两篇 k8s 官方的文档，建议英文功底好的可以直接看第二篇文档。
API 定义
topologySpreadConstraints 是一个 Pod Spec 层级的字段，其定义的结构体如下：
spec:
topologySpreadConstraints:
- maxSkew:
topologyKey:
whenUnsatisfiable:
labelSelector:
在官方文档里还描述了许多 beta 特性的字段，但如果是刚上手 Pod 拓扑约束的小伙伴，可以从这上面的四个基本字段入手，先把这四个字段的含义吃透。
labelSelector：labelSelector 是用来寻找匹配标签的 Pod，对于每一个拓扑域来说，k8s 调度器会计算其中匹配 labelSelector 的 Pod 数量。在上图中，我们定义的拓扑约束只针对含有 label app=foo 的 Pod 生效。 topologyKey：topologyKey 用于一个拓扑域，这个值通常情况下是定义在节点上的标签。在上图中，我们定义的拓扑域就是 zone，也就是含有 zone 这个 label 的节点才算在我们的拓扑域中。 maxSkew：maxSkew 指的就是 Pod 分布在不同的拓扑域中的数量差异。maxSkew 要求其设定的值大于 0，其值越小，说明我们期望 Pod 能够越均衡地打散分布在拓扑域中，其值越大，则反之。在上图中，如果新的 Pod 调度到 Zone1 中，则 Zone1 和 Zone2 的 skew 就是 3-0=3，如果新的 Pod 调度到 Zone2 中，则 Zone1 和 Zone2 的 skew 就是 2-1=1. whenUnsatisfiable：whenUnsatisfiable 指当 skew 不满足 maxSkew 时，调度器会执行的动作，可选值为： DoNotSchedule：（默认值）不调度。 ScheduleAnyway：仍然调度，但会趋向于调度到使 skew 最小的拓扑域中。
了解到这里，我就已经排查出来调度不上去的原因了：集群是一个两节点的集群（1master+1worker），但这两个节点属于同一个可用区，但有一点奇怪的是，按照算法，应该会有一个 Pod 调度上去，另一个 Pod 处于 Pending 状态，但现实却是两个 Pod 都处于 Pending 状态。继续看代码，我发现了同事不仅用了 topologySpreadConstraints，还结合了亲和性反亲和性一起使用。
拓扑分布约束 and 亲和性反亲和性
Pod 拓扑约束可以结合亲和和反亲和特性一起使用，达到更丰富的效果，以实际业务场景中的代码为例：
affinity:
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchLabels:
app.kubernetes.io/name: app-server
topologyKey: kubernetes.io/hostname
schedulerName: default-scheduler
topologySpreadConstraints:
- maxSkew: 1
topologyKey: topology.kubernetes.io/zone
whenUnsatisfiable: DoNotSchedulable
labelSelector:
matchLabels:
app.kubernetes.io/instance: app-server
app.kubernetes.io/name: app-server
可以看到，我们设置了 Pod 反亲和性，禁止符合条件的 Pod 调度到同一个节点上（可能是出于容灾或其他方面的考虑），再看 Pod 拓扑约束，要求 Pod 均匀地分布在每个可用区中，且每个可用区之间符合条件的 Pod 的数量差值最大为 1，如果不满足的条件下，禁止调度。（强打散 Pod 到每个可用区中，可能是出于网络带宽，cpu 内存等资源角度的考虑）。
因此，在仅有两个节点的集群中，且这两个节点还是属于同一个可用区的情况下，无法满足上述的调度条件，因此两个 Pod 均处于 Pending 状态。
❝解决方式有两种，可以设置 maxSkew 的值为 2，或者设置 whenUnsatisfiable 的值为 ScheduleAnyway。
引用链接
kubernetes.io/zh-cn/docs/…: https://kubernetes.io/blog/2020/05/introducing-podtopologyspread/
关于 Sealos
Sealos 是一款以 Kubernetes 为内核的云操作系统发行版。它以云原生的方式，抛弃了传统的云计算架构，转向以 Kubernetes 为云内核的新架构，使企业能够像使用个人电脑一样简单地使用云。
🌟GitHub：https://github.com/labring/sealos
🏠官网：https://sealos.io
💻开发者论坛：https://forum.laf.run
关注 Sealos 公众号与我们一同成长👇👇👇