多容器编排环境下如何通过 Docker Compose 处理资源预留策略教程

reservations 设置内存和 CPU 最小保障值，仅在资源紧张时起作用：空闲时容器可超用（不超 limits），紧张时优先保留该资源；它不锁定物理内存，只影响 cgroup 回收行为，需配合 limits 和禁用 swap 才完整生效。

直接在 docker-compose.yml 中用 deploy.resources.reservations 设置内存和 CPU 的最小保障值，就能实现资源预留。关键在于它不占用物理资源，只在系统紧张时起作用——既避免服务“饿死”，又不浪费空闲资源。

明确 reservations 的作用边界

预留（reservations）不是硬分配，而是调度器的承诺：

• 系统空闲时，容器可自由使用超出预留的资源（只要不超过 limits）
• 内存或 CPU 紧张时，Docker 会优先保留这部分资源给该服务，其他容器的非预留内存更可能被回收
• 它本身不阻止其他容器启动，也不锁定物理内存页，仅影响 cgroup 的 reclaim 行为

合理设定预留值的实操方法

预留值不能拍脑袋定，要结合实际运行数据：

• 先用 docker stats <container> 观察服务稳定运行时的 RSS 内存，取其 1.2–1.5 倍作为起点
• CPU 预留建议设为 limits.cpus 的 40%–60%，例如硬限 1.0 核，预留 0.4–0.6 核
• 内存预留通常设为硬限制的 50%–70%，比如 memory: 1G，则 reservations.memory: 512M–768M
• 切忌预留过高（如 >80%），否则会人为制造资源争抢，降低整体利用率

配置写法与生效前提

以下是一个典型配置示例（适用于 Compose v3.8+）：

version: '3.8'
services:
  api:
    image: my-api:latest
    deploy:
      resources:
        limits:
          cpus: '1.0'
          memory: 1G
        reservations:
          cpus: '0.4'
          memory: 512M

注意：该配置仅在 Docker Swarm 模式下（即使用 docker stack deploy）完全生效；若用 docker-compose up 启动，deploy 段会被忽略。非 Swarm 场景需改用容器运行时参数（如 --memory-reservation）或宿主机 cgroups 手动控制。

搭配硬限制与禁用 swap 才算完整

单独设预留不够，必须组合使用才能稳住关键服务：

• 必须设置 limits.memory，防止内存泄漏拖垮整机
• 显式设置 memory_swap 与 memory 相同（如都为 1G），彻底禁用 swap，避免 I/O 延迟引发超时
• 对数据库、配置中心等基础服务，可额外加 oom_score_adj: -500，降低被 OOM Killer 终止的概率