# Controller 通过 kubectl 访问 Kubernetes

状态：已知，待重构。

生产 Controller 及其阶段辅助脚本对 Kubernetes 的读取、创建、更新和等待都通过 `kubectl`
子进程完成，范围包括 ConfigMap、StatefulSet、Job、Pod 和 backup discovery 所需的 Pod exec。
代码随后自行解析 JSON，并把退出码和 stderr 转换为 Controller 错误。这一结构
来自项目早期的 shell 脚本实现。

该边界让 Kubernetes 操作分散在 Controller、生成器和 task 汇总脚本中。继续扩展这些操作会
重复命令拼装、超时、JSON 校验和错误处理，也会让单元测试依赖命令替身而不是稳定的客户端
接口。

### 可重构边界

1. 为生产执行路径引入职责明确的 Kubernetes 访问层，集中负责读取源配置、固化 workflow
   ConfigMap、reconcile Job、读取 Pod 结果和执行 backup discovery。
2. 访问层使用官方 Python client，并保留当前的 namespace、label selector、请求超时、缺失
   Job 补建和已有资源复用语义。
3. 生成层只返回资源对象；资源创建、更新和字段归属由访问层统一处理。
4. Job 观察先保持当前轮询语义；客户端边界稳定后，可改为支持断线重连和重新 LIST 的 Watch，
   减少每十秒完整读取 Job 列表。

优先范围是生产 Controller 及其辅助脚本。E2E 和人工运维脚本是独立的命令行消费者，可在生产
路径迁移完成后另行评估。