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

看了一些 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 有没有一套固定的判断设置流程呢？

iyear

2023-05-23 11:08:16 +08:00

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

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

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

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

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

rrfeng

2023-05-23 11:27:42 +08:00

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

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

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

szkoda

2023-05-23 16:29:24 +08:00

问题一：

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

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

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

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

szkoda

2023-05-23 16:43:13 +08:00

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

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

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

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

这是一个专为移动设备优化的页面（即为了让你能够在 Google 搜索结果里秒开这个页面），如果你希望参与 V2EX 社区的讨论，你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/942158