容器化资源优化核心在于配额与实际使用的匹配关系，需重点关注cpu节流率＞5%、oomkilled事件、request/limit比值及节点水位，结合prometheus、docker stats、kubectl top等工具分层监控与调优。
容器化平台的资源利用率监控与优化，核心在于“看得清、判得准、调得稳”。单纯看CPU或内存数字容易误判——比如某容器CPU使用率长期30%，但若其Request设为1核而实际只用0.2核，就是明显浪费；反之，另一容器使用率85%却没触发节流，说明Limit留有余量，未必需要扩容。关键不是绝对值，而是配额与实际使用的匹配关系。
明确关键指标与真实含义
监控不能只盯表面数字，要结合Kubernetes原语理解指标背后的行为：
- CPU节流率（container_cpu_cfs_throttled_periods_total）：比CPU使用率更重要。节流率＞5%说明容器被强制限频，即使使用率不高也会卡顿
- 内存OOMKilled事件：不是看“用了多少”，而是看“是否被杀过”。一旦发生，说明Memory Limit设置过低或存在泄漏
- Request/Limit比值：Request是调度依据，Limit是硬上限。两者差值过大（如Limit是Request的3倍）往往意味着资源预留过度
- 节点水位（Node Allocatable vs Capacity）：注意Kubelet保留资源（如system-reserved），真正可调度容量通常比总容量低5–10%
用好原生工具链，避免重复造轮子
Rancher、K8s原生生态已提供足够成熟的采集与可视化能力，无需额外部署复杂中间件：
- Rancher项目级监控默认启用Prometheus+Grafana，直接打开“Cluster Explorer → Monitoring → Dashboards”，选择“Node Metrics”或“Workload Metrics”即可查看节点/容器维度的CPU、内存、网络、磁盘IO趋势
- 命令行快速筛查：
docker stats --format "table {{.Name}}\t{{.CPUPerc}}\t{{.MemPerc}}\t{{.MemUsage}}" --no-stream适用于单机调试；kubectl top pods -n <ns></ns>获取实时资源占用，配合--sort-by=cpu或--sort-by=memory排序 - 通过
kubectl describe pod <pod-name></pod-name>检查Events字段，第一时间发现OOMKilled、FailedScheduling等关键异常
分层优化策略：从容器到集群
优化需按粒度推进，避免“一刀切”调整：
- 容器层：对高节流或频繁OOM的Pod，先调高Request（保障调度优先级），再根据历史峰值适当收紧Limit；对长期低负载（如CPU平均＜10%且稳定）的服务，可将Request下调20–30%，同时观察响应延迟和错误率
- 工作负载层：StatefulSet类服务（如数据库）保持固定配额；Deployment类业务服务启用HPA，基于custom.metrics.k8s.io（如QPS、队列长度）而非单纯CPU扩缩
- 集群层：利用Rancher的Cluster Explorer → Nodes页面，识别长期闲置节点（CPU/Mem使用率持续＜20%超48小时），考虑驱逐+缩容；对混合节点池（如CPU密集型+内存密集型混部），用nodeSelector+Taint/Tolerate实现物理隔离
建立可持续的优化闭环
资源优化不是一次性动作，而是持续运营过程：
- 每周导出一次
kubectl get pods -A -o wide+kubectl top nodes结果，生成资源使用热力图，标记连续3次低效（Request使用率＜30%）或高危（节流率＞10%）对象 - 在CI/CD流水线中嵌入资源检查：新镜像部署前，自动比对历史版本的平均CPU/Mem Request使用率，波动超±25%则阻断发布并告警
- 为每个核心服务定义SLI（如“95%请求P95延迟＜200ms”），当资源调整后SLI恶化，立即回滚配额变更，避免为省资源牺牲体验
