V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
eephee
V2EX  ›  Kubernetes

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

  •  
  •   eephee · 2023-05-23 10:28:11 +08:00 · 1546 次点击
    这是一个创建于 582 天前的主题,其中的信息可能已经有所发展或是发生改变。

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

    已知:

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

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

    具体到使用场景,我的问题是:

    1. 某个 Pod 的 request memory 8G ,limit memory 12G 。假如该 Pod 被调度到一个剩余内存量为 10G 的节点上,在运行时该 Pod 占用的内存最大不会超过 10G ,否则会被 OOM Killed ,对吗?(还是说会被驱逐到其他节点并重启?)那这种情况下,其实 limit 这个字段所能发挥的调度灵活性还是有限的,所以集群的资源还是充足比较好,也不算浪费因为毕竟提高了服务的质量,对吗

    2. 我使用三台 4G 的主机作为 K8S 的 worker 节点,但是我现在有个 Pod 需要 request limit 为 8G ,那这个时候该 Pod 是没法运行在该 K8S 系统上对吗?这个应该可以做实验,不过还是想听听大佬们的指点 qaq

    3. 关于 request/limit 有没有一套固定的判断设置流程呢?

    9 条回复    2023-05-23 17:06:22 +08:00
    iyear
        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. 官方文档,再细节就看代码和测试样例了
    rrfeng
        2
    rrfeng  
       2023-05-23 11:27:42 +08:00   ❤️ 2
    1. pod 申请内存到 10G 前什么都不会发生,超过 10G 会发生内存申请失败,之后的行为取决于你的程序。系统内核也会做出一些反应:例如 OOM kill 掉某个进程(不一定是你的 Pod )。k8s 不会对该行为产生任何反应。

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

    3. request:确保你的程序能正常服务的最小值(包括高负载下,运行一段时间后,不是指极限最小值)。limit:你不想你的程序异常干死了别的程序吧,给他加个限制。
    eephee
        3
    eephee  
    OP
       2023-05-23 11:29:37 +08:00
    @iyear
    确实,是 resources 是 containerSpec 下面的东西,我没注意到这一点 :thumb_up:
    iyear
        4
    iyear  
       2023-05-23 11:37:51 +08:00
    @rrfeng #2 在节点内存压力的时候不会把 pod 驱逐走么
    rbaloatiw
        5
    rbaloatiw  
       2023-05-23 12:10:33 +08:00 via Android
    @rrfeng 1. 的情况下应该会触发 node pressure eviction, 但 evict 的不一定是这个 pod
    rrfeng
        6
    rrfeng  
       2023-05-23 12:42:29 +08:00 via Android
    @iyear
    @rbaloatiw
    是的,忘记这点了。内存低于一定程度之后,kubelet 会启动 evit 流程
    szkoda
        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 ,达不到。
    szkoda
        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
    eephee
        9
    eephee  
    OP
       2023-05-23 17:06:22 +08:00
    感谢大佬们,我大概明白了,k8S 对这个情况的处理还是挺细的
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1286 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 24ms · UTC 17:53 · PVG 01:53 · LAX 09:53 · JFK 12:53
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.