容器资源消耗需从宿主机、运行时、镜像、应用四层叠加分析；盲目设limit易致CPU节流、OOM Killed、调度失败，应分层归因、动态适配、闭环验证。
容器环境的系统资源消耗不是单纯看容器里跑的应用，而是要从宿主机、运行时、镜像、应用四层叠加来看。盲目设 limit 或一刀切调参，反而容易引发 CPU 节流、OOM Killed、调度失败等问题。关键在于分层归因、动态适配、闭环验证。
宿主机与运行时基础开销
Docker 守护进程本身占用 50–100MB 内存，频繁拉镜像或启停容器时会临时升高；containerd/runc 等运行时组件轻量但不可忽略。Alpine 镜像启动后基础内存约 5–10MB，而 Ubuntu/Debian 镜像动辄 50–100MB；Java 应用镜像若含完整 JDK，仅基础镜像就占 100–200MB，再加 JVM 堆（如 -Xmx256m）和元空间，总内存可能突破 400MB。这些“隐性成本”常被 requests 配置遗漏，导致调度器误判节点容量。
建议：
- 生产环境优先选用 distroless 或 Alpine 基础镜像，避免带 shell 和包管理器的冗余组件
- 通过
docker stats或 cAdvisor 查看容器 RSS（实际物理内存），而非仅依赖 JVM 的 heap usage - 对 Java 容器，启用
-XX:+UseContainerSupport（JDK8u191+/JDK10+ 默认开启），让 JVM 主动读取 cgroup memory.limit_in_bytes，避免堆内存超限触发 OOM Killer
CPU 与内存的配额逻辑与常见误区
容器不“独占” CPU 核心，而是共享时间片。--cpus="1.5" 表示最多使用 1.5 个逻辑核的等效时间，不是绑定物理核；--cpu-shares=512 是相对权重，在争抢时生效，不设 limit 时无法限制绝对用量。内存方面，--memory="512m" 是硬上限，超限即被 OOM Killer 终止；--memory-swap="1g" 则允许最多 512MB 内存 + 512MB swap，但 swap 在容器中通常禁用，应设为 --memory-swap="512m"（即禁止 swap）。
典型问题：
- requests 过低 → 调度器把多个高负载 Pod 打包到同一节点，引发节流（cfs_throttled_periods 高）
- limits 过高 → 占用大量可调度资源却长期空闲，造成 CPU 碎片化（集群利用率低但频繁 pending）
- 未设 requests → Pod 属于 Best-Effort QoS，易被优先驱逐，且无法参与 CPU 权重分配
基于监控的动态调优闭环
静态配置难以应对业务波动。应建立“采集→分析→调优→验证”闭环：
- 用 Prometheus 抓取
container_cpu_cfs_throttled_periods_total（节流次数）、container_memory_usage_bytes（RSS）、kube_pod_container_resource_limits等指标 - 定义健康基线：CPU 节流率持续 >5%、内存 RSS 占 limit >85%、OOMKilled 事件频发，均为调优信号
- 对 Burstable 类服务（如 Web API），先调高 requests 至历史 P95 使用量的 1.2 倍，再将 limits 设为 requests 的 1.5–2 倍；对 Guaranteed 类（如数据库代理），确保 requests == limits
- 结合 HPA（按 CPU/memory utilization）与 VPA（自动调 requests/limits），但 VPA 不适用于有状态服务，需人工复核
镜像与 JVM 层的协同优化
镜像体积大不仅拖慢部署，也增加内存加载压力；JVM 参数不匹配容器限制，是 Java OOM 的主因之一。
- 采用多阶段构建：Maven/Gradle 构建阶段用 full-jdk 镜像，运行阶段 COPY jar 到 jre-slim 或 distroless，体积减少 60–75%
- JVM 启动参数必加：
-XX:+UseContainerSupport -XX:MaxRAMPercentage=75.0（替代过时的 -Xmx），让堆自动适配容器内存限制 - 关闭不必要的 JVM 特性：如 -XX:+UseCompressedOops（小堆下收益有限）、-XX:+TieredStopAtLevel=1（禁用 C2 编译器降低启动内存）
- 对 GC，G1 仍是主流选择，但需调
-XX:MaxGCPauseMillis=200避免长停顿影响 SLA
