关键在于构建三层防线：Docker设内存CPU硬限（-m与--memory-swap配平、--cpus）、Kubernetes协同配置resources.limits并设requests、叠加--pids-limit与QoS分级，再经docker stats和inspect验证及P95压测。
要让宿主机在多容器高负载下依然绝对稳定，关键不是“尽量限制”，而是构建一层硬边界+弹性缓冲+主动防御的三层防线。Docker负责单容器级硬隔离，Kubernetes负责集群级调度与兜底，二者必须协同配置，缺一不可。
内存：必须设硬限，且禁用swap扩容
内存失控是宿主机卡死甚至崩溃的首要原因。Docker层必须用-m（或--memory）强制设定物理内存上限，同时配平--memory-swap：
-
--memory=512m表示最多使用512MB物理内存 -
--memory-swap=512m表示不启用swap——这是关键，避免内存超支后疯狂换页拖垮整机 - 若需保留一点缓冲空间，可设
--memory-swap=768m（即额外256MB swap），但绝不能设为无限（默认值）或远高于物理内存
Kubernetes中对应写在resources.limits.memory，值需与Docker一致；requests.memory则按应用P95实测值上浮20%设定，确保调度器能预留足够资源。
CPU：用--cpus做硬配额，别依赖--cpu-shares
--cpu-shares只是争抢时的权重比例，空闲时容器仍可吃满全部CPU。生产环境必须用--cpus：
-
--cpus=1.2表示该容器在任何负载下最多占用1.2个逻辑CPU的时间片，底层直接映射cgroups的cpu.cfs_quota_us / cpu.cfs_period_us - 宿主机4核，就不要给单个Web服务配
--cpus=3.0；常规API服务建议0.5–1.0，计算任务可放宽至2.0，但总和须留至少1核余量给系统进程 - Kubernetes中写为
resources.limits.cpu: "1.0"，单位是vCPU，支持小数
进程与OOM：加--pids-limit，配合QoS分级保命
CPU和内存限制挡不住fork炸弹或连接数爆炸。Docker需叠加--pids-limit：
- Nginx/Envoy类代理服务建议
--pids-limit=200 - Go/Python微服务按线程池或goroutine上限设，如
--pids-limit=100
Kubernetes通过QoS等级自动保障关键Pod：
- Guaranteed（request==limit）：最高优先级，OOM时最后被杀
- Burstable（request<limit）：中等优先级，内存压力大时可能被驱逐
- BestEffort（无request/limit）：最低优先级，OOM第一候选
务必避免BestEffort，所有生产Pod至少设requests。
验证与压测：不验证=没设限
参数写进去不等于生效。上线前必须验证：
- 运行中执行
docker stats 容器名，确认MEM USAGE / LIMIT和CPU %是否贴近设定值 - 用
docker inspect 容器名查HostConfig.Memory和NanoCpus字段，确认cgroups已真实挂载 - 对每个服务做72小时压测，按P95内存/CPU峰值上浮20%设限，避免一刀切过严导致功能异常
