kubernetes资源浪费需用真实运行时数据优化，kube-capacity查现状、krr给精准建议、kube-score防配置退化，三者形成“查→荐→防”闭环。
直接看结论：Kubernetes资源浪费不是靠“猜”或“拍脑袋”能解决的，必须用真实运行时数据反推Requests/Limits配置——而kube-capacity、krr、kube-score这三个Go写的CLI工具，刚好覆盖“查现状→给建议→防倒退”的闭环，缺一不可。
查集群真实用量：用 kube-capacity 快速定位“白吃型”Pod
它本质是把kubectl top和kubectl describe的输出逻辑做了聚合，不用写超长custom-columns命令就能一眼看出谁在空占资源。
- 默认输出按CPU/MEM利用率排序，
--sort=cpu-used或--sort=mem-used可快速翻到最“安静”的Pod - 加
--containers参数会拆到容器级，避免因多容器部署导致的request/limit误判 - 常见坑：不加
--all-namespaces时，默认只查default命名空间，容易漏掉kube-system里那些“申请1核只用20m”的系统组件 - 注意
kube-capacity显示的Used值来自metrics-server，如果该组件没部署或采集延迟高，数值会为空或滞后
生成精准配置建议：krr 为什么比 VPA 更适合落地
krr的推荐不是基于瞬时快照，而是分析Prometheus中最近14天的container_cpu_usage_seconds_total和container_memory_usage_bytes，所以不会被突发流量带偏。
- 执行
krr recommend --strategy=all会同时给出CPU和内存建议，但要注意：它默认只推荐requests，limits需手动同步设置（否则可能触发OOMKilled） - 输出中的
CRITICAL级别建议通常对应实际使用量长期低于request 30%的Pod，这类可以直接砍掉一半request再观察 - 容易忽略的一点：
krr需要Prometheus有至少7天以上历史数据才能出稳定建议；若刚接入监控，先跑krr recommend --duration=3d过渡 - 它不修改任何YAML，只输出建议——这点比VPA安全，尤其适合CI/CD阶段做预检
防止改完又退化：用 kube-score 在提交前卡住低质量配置
它不看实际用量，只检查YAML是否符合最佳实践规则，比如resources字段缺失、securityContext未启用、livenessProbe和readinessProbe配置不合理等。
- 运行
kube-score score *.yaml后，重点盯WARNING和CRITICAL项，尤其是标红的resources-requests-and-limits规则 - CI中可加
--scorecard=scorecard.yaml自定义阈值，例如把resources-requests-and-limits设为CRITICAL，让流水线在发现无requests的Deployment时直接失败 - 常见误用：把它当成“资源优化工具”——它不分析用量，也不推荐数值，只做合规性检查。想调优还得靠
krr或kube-capacity - 规则集可扩展，但默认已覆盖CNCF官方
Kubernetes Security Best Practices中90%以上的硬性要求
真正难的不是选哪个工具，而是让三者形成工作流：开发改完YAML → kube-score过一遍 → 提交到Git → CI触发krr分析历史用量 → 把建议写回PR评论 → 运维确认后合并。中间任何一环断开，浪费就会悄悄回来。
