1. 容器运行时治理概述
1.1 什么是容器运行时
容器运行时（Container Runtime）是负责在宿主机上创建、运行、监控和销毁容器的软件组件。它是容器化架构中最底层的执行引擎，直接与操作系统内核交互，通过 Linux Namespace 和 Cgroups 实现资源隔离与限制。
根据容器生态的分层模型，运行时通常分为两类：
| 类型 | 代表实现 | 核心职责 |
|---|---|---|
| 低级运行时 | runc、crun、runsc (gVisor) | 直接调用内核 syscall 创建容器进程，管理 cgroups 和 namespace |
| 高级运行时 | containerd、CRI-O、Docker Engine | 实现 CRI 接口，管理镜像拉取、存储、网络挂载，调用低级运行时 |
关键认知： Kubernetes 通过 CRI（Container Runtime Interface）与高级运行时通信，高级运行时再委托低级运行时完成容器进程的创建。Prometheus 的容量预警需要覆盖从 Kubelet → CRI shim → 运行时 → 内核 cgroups 的完整链路。
1.2 运行时治理的目标与挑战
容器运行时治理是指对运行时的配置、性能、安全、容量和生命周期进行系统化管理，确保容器能够稳定、高效、安全地运行。其核心目标包括：
- 稳定性保障： 防止运行时 OOM、死锁、hang 住等故障导致批量容器异常退出。
- 资源效率： 在满足容器 SLA 的前提下，最大化宿主机资源利用率，减少碎片化。
- 安全合规： 限制容器对宿主机内核的访问权限，防止逃逸攻击。
- 容量可预测： 通过监控和预警提前发现资源瓶颈，避免突发性容量耗尽。
实际治理中面临的主要挑战：
- 多租户资源争抢： 同一宿主机上不同业务容器共享 CPU、内存、磁盘 IO，缺乏有效隔离时容易相互干扰。
- cgroups 层级复杂： 现代容器运行时（如 containerd）使用 systemd cgroup 驱动，层级深、命名长，监控指标采集路径不直观。
- 运行时自身开销： 运行时进程（如 containerd-shim）本身也消耗资源，在大规模节点上不可忽略。
- 突发流量与毛刺： 容器级别的资源使用波动剧烈，传统固定阈值预警容易产生大量误报。
实践建议： 运行时治理不应只关注容器进程本身，还要覆盖运行时守护进程、镜像存储目录（/var/lib/containerd）、日志驱动（journald）以及宿主机内核参数（如 vm.overcommit_memory）。这些组件共同构成容器的"运行环境容量"。
1.3 容量预警在治理中的定位
容量预警是运行时治理的"前哨"能力，它通过 Prometheus 持续采集运行时相关指标，在资源使用量接近或超过安全水位时主动告警，为运维人员争取处置时间。容量预警在整体治理框架中处于以下位置：
容量预警在治理中的具体价值体现在三个层面：
| 治理层面 | 容量预警的作用 | 典型场景 |
|---|---|---|
| 预防层 | 在资源耗尽前发出预警，避免容器 OOM Kill 或节点磁盘满 | 容器内存使用率 > 85% 持续 5 分钟 |
| 诊断层 | 通过历史趋势定位容量瓶颈，辅助扩缩容决策 | 节点 CPU 预留不足导致 throttling 加剧 |
| 反馈层 | 将预警数据反哺给调度器和自动扩缩容组件 | 基于容器内存增长速率触发 HPA 扩容 |
常见误区： 容量预警不等于简单的"资源使用率 > 阈值"。运行时治理要求预警规则必须考虑 cgroups 层级、容器重启策略、宿主机预留资源（kube-reserved、system-reserved）以及运行时自身的 overhead。忽略这些因素会导致预警要么漏报，要么过度告警。
1.4 运行时容量预警的指标体系
基于 Prometheus 的容量预警需要覆盖以下关键指标域：
- 容器级别： container_memory_working_set_bytes、container_cpu_cfs_throttled_seconds_total、container_fs_usage_bytes
- 节点级别： node_memory_MemAvailable_bytes、node_cpu_seconds_total、node_filesystem_avail_bytes
- 运行时级别： containerd_grpc_requests_total、containerd_cri_container_stats（通过 cAdvisor 或 eBPF 暴露）
- cgroups 控制组： 通过 /sys/fs/cgroup 暴露的 memory.current、cpu.stat、io.stat
设计原则： 容量预警规则应遵循"分层聚合、逐级收敛"的策略。先检测容器级异常，再聚合到 Pod 级，最后收敛到节点级。避免直接从节点级指标下钻到具体容器，减少告警风暴。