这是一个创建于 338 天前的主题，其中的信息可能已经有所发展或是发生改变。
看了一些 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 有没有一套固定的判断设置流程呢？
 |
1
iyear 338 天前  1
试着回答一下，有错误请纠正：
目前的资源限制是基于 container 的，所以基于 pod 的资源限制这个说法有点怪，pod 的资源限制是所有 container 资源限制总和。基于 pod 的资源限制 kep 还在 review： https://github.com/kubernetes/enhancements/pull/1592 1. 不是很确定。应该是驱逐，到了节点内存压力会打污点然后被驱逐，如果内存足够但是超出 limit 是被 oomkilled ，然后会不断被尝试重启 pod ？ 2. scheduler 不会调度，pod 一直 pending 3. 官方文档，再细节就看代码和测试样例了 |
 |
2
rrfeng 338 天前 2
1. pod 申请内存到 10G 前什么都不会发生，超过 10G 会发生内存申请失败，之后的行为取决于你的程序。系统内核也会做出一些反应：例如 OOM kill 掉某个进程（不一定是你的 Pod ）。k8s 不会对该行为产生任何反应。
2. 没法运行，无法调度。 3. request：确保你的程序能正常服务的最小值（包括高负载下，运行一段时间后，不是指极限最小值）。limit：你不想你的程序异常干死了别的程序吧，给他加个限制。 |
 |
7
szkoda 338 天前 2
问题一：
大概率被 oom 或驱逐，但也有可能逃过一劫，害别人被杀掉，内存释放后自己安然无恙。 1. 先触发了 kubelet 的驱逐，kubelet 按照 qos 顺序决定驱逐谁，你这个 pod 是 Burstable ，但可能有倒霉 pod 也有问题，被先杀掉，逃过一劫，内存恢复 2. kubelet 来不及反应(默认检测周期 10s)，直接打爆了机器，系统按照 oom score 决定杀掉谁，因为 k8s 会更改进程 score ，和 1 情况一样，不一定杀哪个进程。 3. pod 先达到自己的 limit ，被 oom 掉：不存在这个情况，因为你的 limit 是 12G ，达不到。 |
|
8
szkoda 338 天前 2
"limit 这个字段所能发挥的调度灵活性还是有限的" : 感觉这句话有点问题，limit 不参与调度，只是超卖比例。
"该 Pod 被调度到一个剩余内存量为 10G 的节点上"：这句话也有点问题，一个 k8s 集群是一个整体，节点内存都是动态变化的，为什么会存在这种定死内存的东西，有非 k8s 管理的进程或容器在上边跑？ 2. 做不到，最小调度单元是 pod ，不可能分身成 n 个进程到 n 台机器，你让他咋跑呢？ 3. 官方文档，但 k8s 这种 request 配置调度比较基础，也存在一些问题比如碎片化，所以社区也有很多自定义 scheduler |
 |
9
eephee OP 感谢大佬们，我大概明白了，k8S 对这个情况的处理还是挺细的
|
Select Language