核心是让每个容器“有边界地运行”，需在启动、编排、监控三层面同步落地：启动时用--cpus和--memory设硬上限；Compose中通过deploy.resources.limits统一声明；K8s中必须补全requests和limits，否则为BestEffort无约束。
核心是让每个容器“有边界地运行”，不设限的容器就像没装刹车的车，一个失控就可能连环撞毁整条服务链。关键在启动、编排、监控三个层面同步落地。
启动时强制绑定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强约束，不可突破
- 该配置在 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
- 务必在Deployment中补全 requests（调度依据）和 limits（运行约束），哪怕只是保守值如 memory: "128Mi"、cpu: "100m"
