📘 第25课：资源限制

生产部署

⚖️ 为什么要限制容器资源？

没有资源限制，一个失控的容器可以耗尽整台主机的CPU和内存，拖垮所有其他容器——"吵闹邻居"问题。

💻 CPU限制

# 限制CPU核心数 ✅
docker run -d --cpus=1.5 nginx        # 最多使用1.5个核心
docker run -d --cpus="0.5" nginx      # 最多使用0.5个核心

# 指定CPU核心亲和性 ✅
docker run -d --cpuset-cpus=0,2 nginx # 只使用第0和第2个核心

# CPU份额（相对权重，默认1024）
docker run -d --cpu-shares=512 nginx  # 空闲时仍可使用全部CPU

# Compose配置 ✅
services:
  api:
    deploy:
      resources:
        limits:
          cpus: "1.5"
        reservations:
          cpus: "0.5"

🧠 内存限制

# 限制内存 ✅
docker run -d -m 512m nginx           # 限制512MB内存
docker run -d -m 1g --memory-swap 2g nginx  # 1G内存+1G swap

# 禁止swap
docker run -d -m 512m --memory-swap 512m nginx  # swap=内存，即无swap

# Compose配置 ✅
services:
  api:
    deploy:
      resources:
        limits:
          memory: 512M
        reservations:
          memory: 256M

  db:
    deploy:
      resources:
        limits:
          memory: 2G
          cpus: "2.0"

📊 资源监控

# 实时资源使用 ✅
docker stats
docker stats --no-stream --format "table {{.Name}}\t{{.CPUPerc}}\t{{.MemUsage}}\t{{.MemPerc}}"

# 查看容器资源限制配置 ✅
docker inspect api --format='CPU: {{.HostConfig.NanoCpus}} Mem: {{.HostConfig.Memory}}'

🔄 OOM处理

# OOM Kill优先级（-1000到1000，越低越不容易被杀）✅
docker run -d --oom-score-adj=-500 important-app
docker run -d --oom-score-adj=1000 batch-job

# 禁止OOM Kill（极端情况）
docker run -d --oom-kill-disable=true -m 512m critical-app
⚠️ OOM Kill：当系统内存不足时，Linux内核的OOM Killer会根据oom_score选择进程杀死。容器内存超限不一定会被立即杀——只有系统整体内存不足时才触发OOM Killer。但设置了-m后，cgroups会在容器超限时限制分配。

📋 资源限制最佳实践

# 按服务类型设置合理限制 ✅
services:
  nginx:           # 反向代理：轻量
    deploy:
      resources:
        limits: { cpus: "0.5", memory: 128M }

  api:             # API服务：中等
    deploy:
      resources:
        limits: { cpus: "1.0", memory: 512M }

  db:              # 数据库：重量级
    deploy:
      resources:
        limits: { cpus: "2.0", memory: 2G }

  worker:          # 后台任务：弹性
    deploy:
      resources:
        limits: { cpus: "1.0", memory: 256M }
        reservations: { cpus: "0.25", memory: 64M }

❓ 常见问题

❓ 限制太小导致应用崩溃怎么办？观察实际使用量：docker stats记录高峰期的资源使用，然后设置限制为高峰值的1.5-2倍。也可以先设大再逐步缩小，找到稳定下限。
❓ --cpu-shares和--cpus有什么区别？--cpu-shares是相对权重，只在CPU竞争时生效，空闲时可用全部CPU。--cpus是绝对上限，无论如何都不能超过。生产环境用--cpus更可预测。

🏆 本课成就

📚 深度补充：资源限制进阶要点

【运维与部署阶段】生产环境注意事项

要点说明最佳实践
资源规划根据业务负载合理分配CPU/内存先压测再上线，设置requests和limits
监控告警设置关键指标阈值和告警规则Prometheus + AlertManager，5分钟P99延迟告警
备份策略定期备份关键数据和配置自动化备份脚本 + 异地存储 + 定期恢复演练
灰度发布新版本逐步放量降低风险金丝雀发布5%→20%→50%→100%
回滚预案部署前确认回滚方案和步骤保留前一版本镜像，数据库迁移向前兼容
文档更新配置变更必须同步更新文档GitOps管理配置，变更即文档
安全基线遵循CIS Docker Benchmark非root运行、只读FS、最小能力
日志规范结构化日志，统一格式JSON格式日志，包含traceId

常见误区与避坑指南

  1. 过度配置：不是所有服务都需要高可用，根据实际需求选择架构复杂度，避免过度工程
  2. 忽略日志：日志是排障的关键，确保日志格式统一、级别合理、采集完整
  3. 资源超卖：容器资源限制不是摆设，超卖会导致性能下降甚至OOM Kill
  4. 安全忽视：默认配置不等于安全配置，生产环境必须加固（非root、只读FS、最小能力）
  5. 监控缺失：没有监控等于盲飞，至少要有基础的健康检查和资源监控
  6. 手动运维：能自动化的绝不手动，手动操作容易出错且不可追溯
  7. 忽略网络策略：默认所有容器互通不安全，应按最小权限原则配置网络

进阶阅读与参考

Docker命令速查卡

# 容器生命周期
docker create/start/stop/restart/rm/pause/unpause
docker logs/top/stats/inspect/exec diff

# 镜像构建
docker build/pull/push/tag/rmi/images/history
docker save/load/import/manifest

# 网络与存储
docker network create/ls/inspect/connect/disconnect/rm/prune
docker volume create/ls/inspect/rm/prune

# Docker Compose
docker compose up/down/ps/logs/build/exec
docker compose config/stop/start/scale/top/cp

# 系统维护
docker system df/prune/info
docker builder prune
docker container/prune/image prune

# K8s常用命令
kubectl get/describe/logs/exec/apply/delete
kubectl rollout status/undo/history
kubectl scale/autoscale/set

本阶段知识脉络

运维与部署阶段知识体系： 核心概念 → 实操演练 → 最佳实践 → 故障排查 每一课都遵循：概念讲解 → 命令实操 → 代码示例 → 常见问题 → 练习巩固 确保学完即能上手，理论实践并重。

生产环境检查清单

类别检查项命令/方法
安全性容器非root运行docker exec <c> whoami
只读文件系统docker run --read-only
最小能力集docker inspect --format '{{.HostConfig.CapAdd}}'
可靠性健康检查配置docker inspect --format '{{.State.Health}}'
重启策略docker inspect --format '{{.HostConfig.RestartPolicy}}'
资源限制docker stats --no-stream
可观测性日志收集日志驱动+集中式平台
指标监控Prometheus+cAdvisor
链路追踪Jaeger/Zipkin
备份数据卷备份定期tar备份到远程存储
配置版本化GitOps管理所有配置

SRE关键指标（SLI/SLO）

指标定义典型SLO
可用性成功请求/总请求99.9%
延迟请求处理时间P99<200ms
错误率5xx响应比例<0.1%
吞吐量QPS/TPS根据业务设定
MTTR平均恢复时间<15分钟
MTBF平均故障间隔根据业务设定

实战案例：故障排查流程

# Step 1: 检查容器状态
docker ps -a                          # 查看所有容器
docker inspect <container>            # 查看详细配置

# Step 2: 查看日志
docker logs --tail 100 <container>    # 最近100行日志
docker logs --since 1h <container>    # 最近1小时

# Step 3: 进入容器排查
docker exec -it <container> sh        # 进入容器shell

# Step 4: 检查资源
docker stats --no-stream              # 资源使用概览
docker system df                      # 磁盘使用

# Step 5: 网络排查
docker network ls                     # 网络列表
docker exec <c> ping <target>        # 网络连通性
docker exec <c> nslookup <svc>       # DNS解析

# Step 6: 检查健康状态
docker inspect --format '{{.State.Health}}' <c>
docker inspect --format '{{.State.ExitCode}}' <c>
docker inspect --format '{{.State.OOMKilled}}' <c>

Dockerfile模板：多语言通用

# 通用最佳实践模板
FROM alpine:3.19 AS builder
# ... 构建步骤 ...

FROM alpine:3.19
RUN addgroup -S appgroup && adduser -S appuser -G appgroup
WORKDIR /app
COPY --from=builder /app/output .
USER appuser
HEALTHCHECK --interval=30s --timeout=3s --retries=3 \
  CMD wget -qO- http://localhost:8080/health || exit 1
EXPOSE 8080
CMD ["./app"]

Docker Compose健康检查模板

services:
  app:
    build: .
    healthcheck:
      test: ["CMD", "wget", "-qO-", "http://localhost:8080/health"]
      interval: 30s
      timeout: 5s
      retries: 3
      start_period: 30s
    restart: unless-stopped
    deploy:
      resources:
        limits:
          cpus: '1'
          memory: 512M
← 第24课 📂 目录 第26课 →