Kubernetes FailedScheduling 故障排查

背景

正在使用 Kubernetes 进行 Druid 部署,发现更改 sts 的 replica 之后 pod 一直处于 pending 状态。接下来通过 describe 查看 pod 的部署状态,发现以下日志。

1
2
3
4
5
6
7
8
nodeSelector_new:
dedicated: druid-middlemanager

tolerations:
- key: "dedicated"
operator: "Equal"
value: "druid"
effect: "NoSchedule"
1
2
3
4
5
6
7
8
Node-Selectors:              dedicated=druid-middlemanager
Tolerations: dedicated=druid:NoSchedule

Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal NotTriggerScaleUp 117s cluster-autoscaler pod didn't trigger scale-up: 1 node(s) had untolerated taint {dedicated: ***} .......
Warning FailedScheduling 10s (x9 over 2m8s) default-scheduler 0/84 nodes are available: 1 Insufficient memory, 1 node(s) had untolerated taint {dedicated: ****} ...

排查过程

第一反应认为可能是以下几种 Bug:

  1. nodegroup 资源的 label 错误
  2. sts 资源的 label 错误
  3. nodegroup 的 auto scale 失效

通过检查 sts 和 nodegroup 的 dedicated 和 tolerations 发现并没有问题,排除了 Bug 1 和 Bug 2,重点放在 Bug 3。

1
2
K8s Labels: foc/bottlerocket=true dedicated=druid-middlemanager
K8s Taints: dedicated=druid:NoSchedule

目前 nodegroup 内已经有了一个 node,如果资源不够的话会在 node group 的 activities 中出现尝试扩容的日志,但实际并没有,因此并不是扩容能解决的问题。
据此排除了 Bug 3。

结论

最终发现是 nodegroup 的机型内存较小,即便扩容也无法提供这么大内存的 node 供单个 pod 使用,因此会导致以上报错。
这个日志很容易让人往资源 label 不匹配或者 auto scale 失效的方面去想,是一个很隐蔽的 bug。

1
2
3
4
5
resources:
limits:
memory: 110Gi
requests:
memory: 110Gi

Kubernetes FailedScheduling 故障排查
https://garychow-lgtm.github.io/zh-CN/2024/06/25/Kubernetes-FailedScheduling-Debug/
作者
Gary Chow (Yimin Cao)
发布于
2024年6月25日
许可协议