可压缩资源与不可压缩资源的差异决定Pod是饥饿还是被杀死

调度本质是Node（资源提供者）和Pod（资源使用者）之间的撮合，Node能 提供计算、存储、网络三类资源，其中和调度关系最密切的处理器与内存 虽然同属计算资源，行为却截然不同。处理器是”可压缩资源”（Compressible Resource）：不够用时Pod只会陷入”饥饿状态”、运行变慢，但不会被系统 杀死，容器也不会被强制终止或限时退出——CPU时间片可以被压榨挤占，但 不会导致进程消失。内存是”不可压缩资源”（Incompressible Resource）： 一旦不足、或超过容器自己声明的上限，Pod就会因OOM（Out-Of-Memory）被 系统直接杀掉——内存无法像CPU那样”分片压榨着用”，超了就是超了。 Kubernetes给处理器的默认计量单位是”逻辑处理器个数”（可以是多核系统里 一个核心、一个vCPU或一条超线程，取决于宿主机/proc/cpuinfo如何解释， 不同硬件下”一个处理器”代表的真实算力并不相同；设置时可以直接写小数如 0.5，或用Millicore为单位如500m，1 Core=1000 Millicores）；内存用Byte 计量，支持Ei/Pi/Ti/Gi/Mi/Ki（二进制，如Mi=1024×1024字节）和E/P/T/G/M/K （十进制，如M=1000×1000字节）两套单位体系。理解这个”压缩性”差异，是 理解后续[[三级服务质量等级决定资源不足时先杀谁]]和整个驱逐机制设计 的前提——正是因为内存不足会直接杀进程，Kubernetes才需要一整套机制去 决定”资源紧张时先杀谁”。