K8s 集群 Pod 资源 Request/Limit 基线采集脚本 + 资源利用率成本分析报告模板（覆盖 5 个典型场景）

背景

在 300+ 节点的 K8s 生产集群中，Pod 的 resources.requests 与 resources.limits 长期处于"拍脑袋"状态：request 设太低导致节点碎片化（bin packing 效率差），limit 设太高则 OOM 频发或资源浪费。每次扩缩容、新增业务线都要重新评估一遍资源配比，缺少一套可复现的基线采集与偏差分析流程。

我这边需要把"资源配额是否合理"从凭经验判断变成有数据支撑的例行巡检，但没时间自己从零写脚本和报告模板，所以悬赏找人代劳。

最终要什么

交付两样东西：

1. 基线采集脚本（Bash 或 Python 3.9+，二选一）：一键采集目标集群所有 namespace 下运行中 Pod 的 CPU/内存 request、limit、实际使用量（通过 metrics-server 的 /metrics/resource 接口），输出结构化 CSV 或 JSON 文件。脚本需支持 --namespace 过滤、--output 指定输出路径、--timeout 超时控制。
2. 资源利用率分析报告模板（Markdown）：基于采集数据，分析 request 与 P95/P99 实际使用的偏差，按场景给出优化建议。报告模板需可直接填入数据后作为运维周报附件使用。

输入与上下文

• K8s 版本：1.27+（脚本需兼容 1.27 / 1.28 / 1.29 三个版本）
• metrics-server 已部署，提供 /metrics/resource 接口（Pod 级 CPU/内存使用量）
• 集群规模：50~500 节点，Pod 总数 2000~20000
• 脚本运行权限：cluster-admin（需读取所有 namespace 的 Pod 与 metrics）
• 不依赖 HPA/VPA 当前状态，纯静态采集 + 离线分析
• 不要求对接 Prometheus / Thanos，脚本自行拉取 metrics-server 数据即可
• 镜像大小可通过 kubectl get pods -o json 中的 containerImages 字段获取，或通过 registry API 查询（脚本可选支持）

交付格式

• 脚本文件（.sh 或 .py），含 README.md 说明用法、依赖、权限要求
• Markdown 报告模板（.md），含 5 个场景的分析表格与优化建议占位
• 所有命令可复现，附 kubectl 版本要求（≥ 1.27）
• 交付物通过平台附件上传

5 个典型场景（报告模板必须覆盖）

1. 资源浪费：request 远高于 P99 实际使用（>2x），列出具体 Pod 并给出降配建议（含建议值）
2. OOM 风险：limit < P95 实际使用，标记高风险 Pod 并建议提 limit（含建议值）
3. HPA 不合理：CPU request 设置导致 HPA targetUtilization 计算失真，给出 request 修正建议
4. Namespace 配额冲突：namespace resourceQuota 的 requests.cpu / requests.memory 与 Pod request 总和矛盾，列出冲突项
5. 镜像膨胀：同一 Deployment 不同 ReplicaSet 的容器镜像大小差异 >50%，建议多阶段构建或 distroless 基础镜像

注意事项

• 脚本需处理 metrics-server 不可用场景：降级为仅采集 request/limit，报告中对应列标注 N/A
• 报告模板中的表格需含"Pod 名称 / Namespace / 容器 / Request / Limit / P95 实际使用 / 偏差比 / 建议"列
• 不要引入额外中间件依赖（如 Elasticsearch、ClickHouse），单机可运行
• 代码注释用中文，关键函数需有 docstring