requests决定调度准入，limits触发cgroup硬限制；前者是“最低保障”，后者是“不可逾越上限”，二者协同形成资源弹性与安全边界的双重保障。
容器运行环境的资源限制与弹性机制不是对立关系，而是协同工作的两层保障：限制划出安全边界，弹性提供缓冲空间。真正稳定的生产环境，既不能只靠硬限压风险，也不能依赖软限放任增长。
内存限制必须分清硬限与软限
硬限（--memory）是不可逾越的红线，一旦突破，内核 OOM Killer 会强制终止容器进程。软限（--memory-reservation 或 cgroup v2 的 memory.low）则是一种“优先保底”策略——系统在内存紧张时，会优先回收未达 soft limit 的容器内存，而尽量保留已设 soft limit 的内存空间。
- 软限不阻止超额分配，只影响内核回收优先级
- 设置 soft limit 后，需配合 memory.high（软限之上的第一道硬防线），避免软限形同虚设
- 单容器场景建议：soft limit 设为业务常态内存的 1.2 倍，hard limit 设为峰值的 1.5 倍
CPU 配额与权重共同构成弹性调度基础
仅用 --cpus=0.5 这类绝对配额，在低负载时会造成 CPU 资源闲置；而仅用 --cpu-shares 这类相对权重，在高负载时又缺乏兜底保障。二者应组合使用：
- --cpus 提供最小可保障的计算能力（基于 cfs_quota/cfs_period 实现）
- --cpu-shares 在多容器争抢时决定超额部分的分配比例（默认 1024，值越大份额越高）
- 例如：核心服务设 --cpus=1 --cpu-shares=2048，辅助服务设 --cpus=0.2 --cpu-shares=512，既保底线，又控比例
IO 与进程数限制需匹配业务特征
磁盘 IO 和进程数常被忽视，但它们同样影响稳定性：
- --blkio-weight（10–1000）适用于数据库与日志服务共存场景，让 DB 容器获得更高 IO 优先级
- --pids-limit 可防 fork bomb 或异常线程泄漏，Web 应用通常设为 256–1024，批处理任务可适当放宽
- 注意：--device-read-bps 等绝对限值需结合存储类型（SSD/HDD）和实际吞吐量设定，避免误伤正常读写
Kubernetes 中的 requests/limits 是弹性落地的关键接口
Docker 的单机参数在集群中需升维为声明式契约。K8s 的 requests 对应软性保障，limits 对应硬性上限：
- requests 决定调度——只有节点空闲资源 ≥ requests 才能被调度过去
- limits 触发 cgroup 限制——超限后会被 kill 或 throttled
- QoS 分级（Guaranteed/Burstable/BestEffort）完全由这两者关系决定，直接影响驱逐优先级
