关键在于从启动、编排、监控三个层面落实资源限制：启动时用--cpus和--memory强制设硬上限；编排时在docker-compose.yml deploy.resources中统一定义limits与reservations；监控时结合cAdvisor+Prometheus设置内存>90%、CPU>85%告警并自动响应。
关键在于从启动、编排、监控三个层面落实资源限制，让每个容器“有边界地运行”。不设限的容器就像没装刹车的车，一个失控就可能连环撞毁整条服务链。
启动时强制绑定CPU和内存上限
用 docker run 启动容器时，必须显式指定 --cpus 和 --memory，不能依赖默认值。例如：
- --cpus="1.2"：限制最多使用1.2个逻辑CPU核心（内核通过cfs_quota_us/cfs_period_us实现）
- --memory="1g"：硬性上限为1GB，超限即被OOM Killer终止
- --memory-swap="1g"：禁用swap，避免延迟累积和不可预测行为
注意：仅设 --memory-reservation 或留空参数，等同于放行——容器可抢占宿主机全部空闲内存。
在Compose中统一声明资源策略
微服务场景下，单靠命令行易遗漏。应在 docker-compose.yml 的 deploy.resources 下集中定义：
- limits 是硬边界（如 cpu: '0.8', memory: 768M），运行时受cgroups强约束
- reservations 是软保障（如 memory: 256M），供调度器预留资源，避免冷启动争抢
该配置在 docker compose up 时即生效，无需Swarm模式；若混用 mem_limit 等旧字段，可能被忽略或行为不一致。
配合监控与自动响应机制
光设限不够，得看得见、反应快。推荐组合：
- 用 cAdvisor + Prometheus 采集容器级 container_memory_usage_bytes 和 container_cpu_usage_seconds_total
- 对关键服务设置告警阈值：内存持续 > 90% 限时3分钟、CPU > 85% 持续5分钟
- 告警触发后，自动执行 docker kill --signal=SIGUSR2（触发应用优雅降级）或缩容副本
没有监控的限额，就像装了保险丝却不接报警器——烧断了才知道出事。
警惕K8s中未定义resources的“隐形炸弹”
在Kubernetes里，若Pod模板中完全没写 resources 字段，它会被打上 BestEffort QoS 标签：
- 调度器只看节点有没有空位，不预留任何资源
- 运行时无cgroups限制，可吃光节点所有内存和CPU
- 高密度部署下，一个日志刷屏或循环申请内存的Pod就能拖垮整个Node
务必在Deployment中补全 requests（调度依据）和 limits（运行约束），哪怕只是保守值如 memory: "128Mi", cpu: "100m"。
