# Workflow 临时 ConfigMap 不会自动回收

状态：已知，暂缓处理。数百个对象的规模通常属于低严重度；持续、无界增长仍需监控。

有 cluster 进入导出流程时，每个 `RUN_ID` 会产生三个临时 ConfigMap：

- `cluster-selection`：固化 backup 和 cluster-list object identity；
- `export-init`：保存 Export 初始化程序及其输入；
- `watermark-input`：保存 Watermark 程序和 Pack task 输入。

阶段 Job 的 `ttlSecondsAfterFinished` 只回收 Job 及其 Pod，不会回收这些 ConfigMap。E2E
回归会在已终止 workflow 上主动清理它们，但生产 CronJob 没有对应的回收动作。单轮资源可用
以下 selector 统一定位：

```text
cse.tidbcloud.com/workflow-name=<RUN_ID>
```

需要限定资源角色时使用：

```text
cse.tidbcloud.com/workflow-name=<RUN_ID>,cse.tidbcloud.com/resource-role in (cluster-selection,export-init,watermark-input)
```

### 风险判断

对象数量本身不是主要风险，聚合数据量、增长速率以及 LIST/WATCH 模式更重要：

- Kubernetes 限制单个 ConfigMap 的数据不超过 1 MiB；
- Kubernetes 文档在“至少数万个不同 ConfigMap-to-Pod mount”的量级讨论 immutable
  ConfigMap 对 API Server 的显著性能收益；
- Kubernetes 将超过 100 MB 的大型 collection response 列为可能产生负面性能影响的量级；
- 静态、低更新频率且不再被运行中 Pod 挂载的 ConfigMap，主要消耗 etcd 当前存储、API
  Server cache 和完整 LIST 的传输空间；
- EKS 应结合 `apiserver_storage_size_bytes`（或
  `apiserver_storage_db_total_size_in_bytes`）、`etcd_request_duration_seconds` 和
  `apiserver_request_duration_seconds` 判断 control plane 是否出现实际压力。

参考资料：

- [Kubernetes ConfigMap](https://kubernetes.io/docs/concepts/configuration/configmap/)
- [Kubernetes API concepts](https://kubernetes.io/docs/reference/using-api/api-concepts/)
- [etcd system limits](https://etcd.io/docs/v3.5/dev-guide/limit/)
- [Amazon EKS control-plane best practices](https://docs.aws.amazon.com/eks/latest/best-practices/control-plane.html)

### 重新处理该问题时的边界

不要为了保留一次性实现而把 Kubernetes owner-reference 布局或 GC 状态机耦合进 runner。
后续方案至少应满足：

- GC 是 best-effort 附属行为，失败不改变 Pack、Export、Watermark 和数据库推进的结果；
- Controller Job 删除重建时，尚未完成的 workflow checkpoint 继续可用于同一 `RUN_ID`；
- 资源归属的写入与校验由一个完整生命周期边界负责，runner 不决定 owner reference 放置位置；
- 类型边界应明确选择成熟 client 或窄的领域模型，避免逐步复制 Kubernetes API；
- 是否实施自动回收，应以 label 范围内的聚合字节数、增长预测和 EKS control-plane 指标为依据。