Pod

集群按 requests 做调度、却按 limits 强执行，所以只配一边的容器，留下的是半个契约。只配 requests 的 Pod 调度诚实、突发无上限，流量尖峰时饿死邻居；只配 limits 的 Pod 运行时被封顶、调度时却按零成本算，调度器把它密密塞，直到节点饱和。半个契约压力下一碰就碎；两个数字只有成对才成立。 把 requests 当订座、limits 当店规。订座决定哪台节点有位，店规决定客人闹起来怎么办。两个都按测量设，集群行为就可预测：装箱诚实、突发有笼、凌晨三点的惊喜稀少。订座只管进门那一刻，店规管的是之后每一次喧哗，缺了任何一边，另一边的承诺都会在压力下走样。 两个数字、两种职责 CPU 的 requests 承诺调度器在节点上预留的份额，limits 则是容器在 cgroup 开始节流前能顶到的上限。两者都要配：requests 决定落位，limits 决定天花板。CPU 可压缩，超 CPU limit 只是变慢——节流，不死；内存不可压缩，超内存 limit 进程被 OOM 杀，中间没有减速带。这个不对称决定一切合理的配额政策：CPU 上限可以远高于预订去吃突发，内存上限应该贴着实测工作集加余量。 不写自有带牙的默认，而且准入策略还可能改变最终结果。没有 CPU request 时，除非 LimitRange 或显式 limit 提供默认值，调度器会按零请求计算；Pod 可能被塞得过密，争用时拿不到稳定份额。没有内存 limit 时，进程可以一直长到节点承压，再由 kubelet 回收或驱逐工作负载。要检查准入后的 Pod，而不只是提交前的 YAML，因为命名空间默认值可能已经替你填好了数字。 ...