关于 Pod 的 Memory 资源分配的疑问

This topic created in 1115 days ago, the information mentioned may be changed or developed.

看了一些 K8S 的教程，对于 K8S 资源分配的基础有点疑问，所以想请教几个问题解决一下我心中的疑问：

已知：

CPU 资源被称作可压缩资源，而内存这样的资源则被称作不可压缩资源。

当可压缩资源不足时，Pod 只会“饥饿”，但不会退出。
当不可压缩资源不足时，Pod 就会因为 OOM 被内核杀掉。

具体到使用场景，我的问题是：

某个 Pod 的 request memory 8G ，limit memory 12G 。假如该 Pod 被调度到一个剩余内存量为 10G 的节点上，在运行时该 Pod 占用的内存最大不会超过 10G ，否则会被 OOM Killed ，对吗？（还是说会被驱逐到其他节点并重启？）那这种情况下，其实 limit 这个字段所能发挥的调度灵活性还是有限的，所以集群的资源还是充足比较好，也不算浪费因为毕竟提高了服务的质量，对吗
我使用三台 4G 的主机作为 K8S 的 worker 节点，但是我现在有个 Pod 需要 request limit 为 8G ，那这个时候该 Pod 是没法运行在该 K8S 系统上对吗？这个应该可以做实验，不过还是想听听大佬们的指点 qaq
关于 request/limit 有没有一套固定的判断设置流程呢？

9 replies • 2023-05-23 17:06:22 +08:00

iyear

May 23, 2023

试着回答一下，有错误请纠正：

目前的资源限制是基于 container 的，所以基于 pod 的资源限制这个说法有点怪，pod 的资源限制是所有 container 资源限制总和。基于 pod 的资源限制 kep 还在 review： https://github.com/kubernetes/enhancements/pull/1592

1. 不是很确定。应该是驱逐，到了节点内存压力会打污点然后被驱逐，如果内存足够但是超出 limit 是被 oomkilled ，然后会不断被尝试重启 pod ？

2. scheduler 不会调度，pod 一直 pending

3. 官方文档，再细节就看代码和测试样例了

rrfeng

May 23, 2023

1. pod 申请内存到 10G 前什么都不会发生，超过 10G 会发生内存申请失败，之后的行为取决于你的程序。系统内核也会做出一些反应：例如 OOM kill 掉某个进程（不一定是你的 Pod ）。k8s 不会对该行为产生任何反应。

2. 没法运行，无法调度。

3. request：确保你的程序能正常服务的最小值（包括高负载下，运行一段时间后，不是指极限最小值）。limit：你不想你的程序异常干死了别的程序吧，给他加个限制。

eephee

May 23, 2023

@iyear
确实，是 resources 是 containerSpec 下面的东西，我没注意到这一点 :thumb_up:

iyear

May 23, 2023

@rrfeng #2 在节点内存压力的时候不会把 pod 驱逐走么

rbaloatiw

May 23, 2023 via Android

@rrfeng 1. 的情况下应该会触发 node pressure eviction, 但 evict 的不一定是这个 pod

rrfeng

May 23, 2023 via Android

@iyear
@rbaloatiw
是的，忘记这点了。内存低于一定程度之后，kubelet 会启动 evit 流程

szkoda

May 23, 2023

问题一：

大概率被 oom 或驱逐，但也有可能逃过一劫，害别人被杀掉，内存释放后自己安然无恙。

1. 先触发了 kubelet 的驱逐，kubelet 按照 qos 顺序决定驱逐谁，你这个 pod 是 Burstable ，但可能有倒霉 pod 也有问题，被先杀掉，逃过一劫，内存恢复

2. kubelet 来不及反应(默认检测周期 10s)，直接打爆了机器，系统按照 oom score 决定杀掉谁，因为 k8s 会更改进程 score ，和 1 情况一样，不一定杀哪个进程。

3. pod 先达到自己的 limit ，被 oom 掉：不存在这个情况，因为你的 limit 是 12G ，达不到。

szkoda

May 23, 2023

"limit 这个字段所能发挥的调度灵活性还是有限的" : 感觉这句话有点问题，limit 不参与调度，只是超卖比例。

"该 Pod 被调度到一个剩余内存量为 10G 的节点上"：这句话也有点问题，一个 k8s 集群是一个整体，节点内存都是动态变化的，为什么会存在这种定死内存的东西，有非 k8s 管理的进程或容器在上边跑？

2. 做不到，最小调度单元是 pod ，不可能分身成 n 个进程到 n 台机器，你让他咋跑呢？

3. 官方文档，但 k8s 这种 request 配置调度比较基础，也存在一些问题比如碎片化，所以社区也有很多自定义 scheduler

eephee

May 23, 2023

感谢大佬们，我大概明白了，k8S 对这个情况的处理还是挺细的