#Архитектура

#Обзор

Tekton Pruner — это система контроллеров Kubernetes, которая автоматически управляет жизненным циклом ресурсов Tekton PipelineRun и TaskRun. Она следует паттерну оператора Kubernetes, реализуя событийное и периодическое согласование для применения настраиваемых политик очистки на основе времени (TTL) и истории.

#Принципы архитектуры

#1. Реализация паттерна контроллера

• Циклы согласования: Несколько контроллеров отслеживают и реагируют на изменения ресурсов
• Событийная обработка: Контроллеры реагируют на события Kubernetes (ConfigMaps, PipelineRuns, TaskRuns)
• Конфигурация через ConfigMap: Декларативное задание политик

#2. Иерархическая модель конфигурации

• Трёхуровневая иерархия: Глобальная → Пространство имён → Селектор ресурсов
• Разрешение приоритетов: Более специфичные настройки переопределяют общие значения по умолчанию
• Гибкие режимы применения: Настраиваемая детализация (глобальная, пространство имён, ресурс)

#3. Разделение ответственности

• TTL Handler: Логика очистки по времени
• History Limiter: Логика удержания по количеству
• Selector Matcher: Идентификация и сопоставление ресурсов
• Validation Webhook: Валидация конфигурации при приёме

#4. Нативный дизайн для Kubernetes

• Controller Runtime: Использование фреймворка controller-runtime
• Состояние в аннотациях: Значения TTL хранятся в аннотациях ресурсов
• Минимальные права RBAC: Требуются только list, get, watch, delete, patch
• Изоляция по пространствам имён: Независимая конфигурация для каждого пространства имён

#Взаимодействие компонентов

#Обязанности контроллеров

#Основные компоненты логики

#Архитектурные решения

#Почему событийная обработка + GC по триггеру ConfigMap?

• Событийная обработка (PipelineRun/TaskRun): Немедленное обновление аннотаций и применение ограничений истории
• GC по триггеру ConfigMap: Полный скан кластера для очистки TTL при изменении конфигурации
• Эффективный дизайн: Избегает постоянного опроса, очищает только при изменении политик

#Почему иерархическая конфигурация?

• Гибкость: Поддержка single-tenant (глобальная) и multi-tenant (пространства имён)
• Делегирование: Владельцы пространств имён контролируют свои политики удержания
• Централизованные значения по умолчанию: Платформенные команды задают разумные fallback-настройки

#Почему разделение TTL и истории?

• Независимые задачи: Удержание по времени и по количеству — разные требования
• Совместное использование: Оба механизма могут применяться одновременно (выигрывает кратчайший срок)
• Чёткая семантика: Каждый механизм имеет отдельную конфигурацию и поведение

#Почему аннотации для состояния TTL?

• Аудируемость: Значение TTL видно в метаданных ресурса
• Отладка: Пользователи могут проверить вычисленный TTL на ресурсах
• Идемпотентность: Предотвращает повторные вычисления при каждом согласовании