看了一些 K8S 的教程,对于 K8S 资源分配的基础有点疑问,所以想请教几个问题解决一下我心中的疑问:
已知:
CPU 资源被称作 可压缩资源,而内存这样的资源则被称作 不可压缩资源。
具体到使用场景,我的问题是:
某个 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 2023-05-23 11:08:16 +08:00 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 2023-05-23 11:27:42 +08:00 2
1. pod 申请内存到 10G 前什么都不会发生,超过 10G 会发生内存申请失败,之后的行为取决于你的程序。系统内核也会做出一些反应:例如 OOM kill 掉某个进程(不一定是你的 Pod )。k8s 不会对该行为产生任何反应。
2. 没法运行,无法调度。 3. request:确保你的程序能正常服务的最小值(包括高负载下,运行一段时间后,不是指极限最小值)。limit:你不想你的程序异常干死了别的程序吧,给他加个限制。 |
3
eephee OP @iyear
确实,是 resources 是 containerSpec 下面的东西,我没注意到这一点 :thumb_up: |
5
rbaloatiw 2023-05-23 12:10:33 +08:00 via Android
@rrfeng 1. 的情况下应该会触发 node pressure eviction, 但 evict 的不一定是这个 pod
|
6
rrfeng 2023-05-23 12:42:29 +08:00 via Android
|
7
szkoda 2023-05-23 16:29:24 +08:00 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 2023-05-23 16:43:13 +08:00 2
"limit 这个字段所能发挥的调度灵活性还是有限的" : 感觉这句话有点问题,limit 不参与调度,只是超卖比例。
"该 Pod 被调度到一个剩余内存量为 10G 的节点上":这句话也有点问题,一个 k8s 集群是一个整体,节点内存都是动态变化的,为什么会存在这种定死内存的东西,有非 k8s 管理的进程或容器在上边跑? 2. 做不到,最小调度单元是 pod ,不可能分身成 n 个进程到 n 台机器,你让他咋跑呢? 3. 官方文档,但 k8s 这种 request 配置调度比较基础,也存在一些问题比如碎片化,所以社区也有很多自定义 scheduler |
9
eephee OP 感谢大佬们,我大概明白了,k8S 对这个情况的处理还是挺细的
|