企业级多租户docker资源限制需硬限（limits）守底线、软预留（reservations）保体验，结合分层配额、节点标签隔离与统一监控实现真正租户隔离。
企业级多租户环境下，docker 容器资源限制不是“加几个参数”那么简单，而是需要兼顾隔离性、公平性、可预测性与运维可观测性。核心在于：用 硬限制（limits）守住底线，靠 软预留（reservations）保障体验，再通过 分层配额策略+统一监控实现租户间真正隔离。
按租户维度划分资源池，避免全局混跑
不推荐所有服务共用一台宿主机且仅靠单容器限制。应结合编排平台能力，实现物理或逻辑资源切片：
- 在 Docker Swarm 或 Kubernetes 中，为每个租户分配专属节点标签（如
tenant: finance），配合 placement constraints 隔离调度 - 使用
docker context或独立 Swarm manager 节点，为不同租户提供隔离的控制面 - 若用纯 Docker Engine，可通过
/etc/docker/daemon.json的default-ulimit统一收紧文件描述符、PID 数等内核资源上限，防止单租户耗尽全局资源
docker-compose.yml 中必须配置的四项关键限制
即使未用 Swarm，只要通过 docker-compose up --compatibility 或接入 Swarm mode，以下配置就生效：
-
memory：设
limits.memory防 OOM，建议不超过宿主机总内存的 70%；搭配reservations.memory确保启动时能分配到基础内存（如 128M），避免因瞬时争抢失败 -
cpus：用
limits.cpus（如'2.0'）做硬上限，比--cpu-shares更可靠；reservations.cpus设为最小保障值（如'0.25'），尤其对 Java/Node.js 等启动即占资源的服务很关键 -
pids-limit：在
ulimits下显式限制进程数（如pids: 200），防止 fork 炸弹或日志轮转失控导致系统僵死 -
device-read-bps / device-write-bps：对数据库类租户容器，限制磁盘 I/O（如
--device-read-bps=/dev/sda:10mb），避免慢查询拖垮整块 SSD
配额分级：基础服务 vs. 批处理任务需区别对待
同一租户内不同业务类型也应差异化管控：
- API 网关、用户服务等在线业务：侧重低延迟，设高
reservations+ 中等limits（如 CPU 预留 0.5 核，上限 1.5 核） - ETL、报表导出等离线任务：允许弹性伸缩但禁止霸占，设低
reservations+ 较高limits（如 CPU 预留 0.1 核，上限 3 核），并配合--cpu-quota=300000 --cpu-period=100000实现更精确的周期控速 - 临时调试容器（如
busybox）：强制启用--read-only+--tmpfs /tmp:rw,size=16m，禁用 swap（--memory-swap=0），从源头杜绝资源滥用可能
监控与告警必须绑定配额指标
光设限制不看效果等于没设。关键要看：
- 容器
memory.usage_in_bytes接近memory.limit_in_bytes（>90%）时触发告警——说明预留不足或存在泄漏 - 持续出现
cpu.stat.throttled_time > 0，代表 CPU 配额被频繁削峰，需检查是否限得太死或负载突增 - 用
cgroup原生接口或 Prometheus + cAdvisor 抓取container_cpu_cfs_throttled_periods_total和container_memory_working_set_bytes，纳入租户级 Dashboard
