#架构

#Overview

Tekton Pruner 是一个 Kubernetes controller 系统，自动管理 Tekton PipelineRun 和 TaskRun 资源的生命周期。它遵循 Kubernetes operator 模式，实现事件驱动和周期性调和，以执行可配置的基于时间（TTL）和基于历史的修剪策略。

#架构原则

#1. Controller 模式实现

• 调和循环：多个 controller 监视并响应资源变化
• 事件驱动处理：controller 响应 Kubernetes 事件（ConfigMaps、PipelineRuns、TaskRuns）
• 基于 ConfigMap 的配置：声明式策略规范

#2. 分层配置模型

• 三级层次结构：全局 → 命名空间 → 资源选择器
• 基于优先级的解析：更具体的配置覆盖通用默认值
• 灵活的执行模式：可配置的粒度（全局、命名空间、资源）

#3. 职责分离

• TTL 处理器：基于时间的清理逻辑
• 历史限制器：基于数量的保留逻辑
• 选择器匹配器：资源识别与匹配
• 验证 Webhook：准入时配置验证

#4. Kubernetes 原生设计

• Controller Runtime：利用 controller-runtime 框架
• 基于注解的状态：TTL 值存储在资源注解中
• 最小 RBAC 权限：仅需 list、get、watch、delete、patch 权限
• 命名空间隔离：每个命名空间配置独立

#组件交互

#Controller 职责

#核心逻辑组件

#设计决策

#为什么采用事件驱动 + ConfigMap 触发的 GC？

• 事件驱动（PipelineRun/TaskRun）：即时更新注解并执行历史限制
• ConfigMap 触发的 GC：配置变更时执行全集群扫描进行 TTL 清理
• 高效设计：避免持续轮询，仅在策略变更时清理

#为什么采用分层配置？

• 灵活性：支持单租户（全局）或多租户（命名空间）
• 委托管理：命名空间所有者控制自己的保留策略
• 集中默认：平台团队设置合理的默认值

#为什么分开 TTL 和历史限制？

• 独立关注点：基于时间和基于数量的保留需求不同
• 组合使用：两者可同时应用（以最短保留期为准）
• 语义清晰：每种机制有独立的配置和行为

#为什么用注解存储 TTL 状态？

• 可审计性：TTL 值在资源元数据中可见
• 调试方便：用户可检查资源上的计算 TTL
• 幂等性：避免每次调和时重复计算