Tekton 流水线资源优化器

要解决的问题

Tekton 的 Pipeline / Task 清单里，开发者通常会随手填一个 cpu / memory 的 request，甚至直接留空。等到流水线真正在集群里跑起来，就会出现两种典型症状：任务因为 Insufficient cpu 长时间 Pending，或者节点明明还有余量，却因为某个 Task 的 request 写得太保守而整体利用率偏低。当流水线数量变多，这种“拍脑袋”式配置会逐步放大调度压力，让 CI 整体吞吐难以预测。

技能如何工作

该技能面向已经运行过一段时间的 Tekton 集群，核心流程可以拆成三步：

1. 读取定义与运行结果：通过 Tekton Results API 拉取 PipelineRun 与 TaskRun 的历史记录，定位到每个 Task 实际执行过的资源请求与限制。
2. 采集真实用量：从 Prometheus 中获取对应 TaskRun 的 CPU / 内存时间序列，识别峰值、常态水位与偶发抖动，而不是只看平均值。
3. 生成建议补丁：把历史实际用量与清单中声明的 requests 做对比，输出可以直接回写到 YAML 的调整建议，例如把某个 Task 的 memory.request 从 512Mi 调到 768Mi，或把长期跑不满的 cpu.limit 下调，减少无谓的 cgroup 节流。

因为分析基于真实时序数据，它更关注“集群里到底跑成什么样”，而不是通用的最佳实践模板。

适用边界与注意点

• 仅分析能从 Results API 读到的 TaskRun，如果某个 Task 从未成功运行过，技能不会有有效样本。
• 依赖 Prometheus 中已有指标。若 Task 运行时间极短、抓取间隔过大，用量曲线可能不够精细，建议项也会偏保守。
• 输出的是建议补丁，不是自动 apply。合并前仍需人工确认，尤其是跨多个 Pipeline 共享的 Task。
• 不负责节点容量规划，也不评估 Cluster Autoscaler /节点池配置，只聚焦在单个 Task 的资源声明上。