发生了什么?
- Pod Scheduler 由于资源不足而失败。实际上,节点有足够的资源。
- 缓存未命中匹配,当我转储调度器缓存信息时
I0329 17:52:21.473968 1 comparer.go:64] "Cache mismatch" missedPods=[000669f9-8b26-4cd8-98ac-30206645690c 000aa9e5-782b-418e-a2fd-88e158e91e36 001daca0-f738-4830-a60b-7e231b7e0e3b 00374447-d517-4c98-aadc-f1f6d28e07b2 003a063a-9d3e-41a0-8356-7d3158e5ca3f 003d060c-6582-4e11-8ff5-c1d36500451a 0045d507-2feb-4104-a480-050e8a02ba25 0055f20d-30c2-471a-8b11-d87959a1b0bd 00620471-945d-4205-aa73-d4743c5b83f5 00790d14-8e52-41f8-9f49-96674bef0797 (there are hundreds of pods )]
你期望会发生什么?
- Pod 调度成功
如何尽可能精确地重现它(最小化)?
- 正确更新调度器缓存信息
是否需要了解其他信息?
- 无响应*
Kubernetes版本
$ kubectl version
# paste output here
调度器版本:1.27.X
云提供商
commity
操作系统版本
# On Linux:
$ cat /etc/os-release
# paste output here
$ uname -a
# paste output here
# On Windows:
C:\> wmic os get Caption, Version, BuildNumber, OSArchitecture
# paste output here
安装工具
容器运行时(CRI)和版本(如果适用)
相关插件(CNI,CSI,...)和版本(如果适用)
5条答案
按热度按时间vdgimpew1#
这个问题目前正在等待分类。
如果SIG或子项目确定这是一个相关的问题,他们将通过应用
triage/accepted
标签并提供进一步的指导来接受它。组织成员可以通过在评论中写入
/triage accepted
来添加triage/accepted
标签。有关使用PR评论与我互动的说明,请查看here。如果您对我的行为有任何问题或建议,请针对kubernetes/test-infra仓库提出一个问题。
9ceoxa922#
/sig scheduling
beq87vna3#
缓存丢失是因为在调度pod时,该pod已被删除。
6qqygrtg4#
/assign
4jb9z9bj5#
你好,
我有一些问题。
你提到这个问题是在调度过程中删除了一个pod时发生的。你是在什么时候执行缓存转储的?考虑到mismatch中有数百个pod,它是在删除之后的某个时间吗?
你只是删除了一个pod吗?