Проблема staleness в Kubernetes controllers приводит к некорректным решениям. В v1.36 добавлены механизмы, которые делают поведение контроллеров предсказуемее.
Когда контроллер начинает действовать на основе устаревшего состояния, это приводит к некорректным решениям.В Kubernetes controllers это связано с локальным кешем, который заполняется через watch API server. Такой кеш ускоряет обработку, но вводит риск рассинхронизации. В результате контроллер может принять неверное решение, пропустить нужное действие или отреагировать с задержкой. Особенно это заметно после рестарта контроллера или при недоступности API server, когда кеш отстаёт от реального состояния кластера.
В Kubernetes v1.36 выбрано прагматичное решение: не устранять кеш, а добавить механизм проверки его актуальности. В client-go появился AtomicFIFO — расширение очереди, которое обрабатывает события атомарно, особенно при batch-операциях (например, initial list). Это убирает состояние, при котором события приходят в разном порядке и ломают консистентность кеша. Дополнительно введена функция LastStoreSyncResourceVersion(), которая позволяет явно понять, какую версию ресурса видел кеш. Компромисс здесь очевиден: добавляется дополнительная проверка перед действием, что может замедлить реакцию, но снижает риск некорректных операций.
На уровне реализации kube-controller-manager использует эту возможность через feature gates вида StaleControllerConsistency. При включении контроллер перед действием сравнивает resource version в кеше с той, которую он сам записал в API server. Если кеш отстаёт, действие не выполняется. Это поведение реализует принцип read-your-own-writes без необходимости синхронных запросов к API. В client-go также добавлен ConsistencyStore — структура, которая отслеживает версии ресурсов и помогает informer’ам определить, догнал ли кеш актуальное состояние. Например, ReplicaSet controller отслеживает версии как самого ReplicaSet, так и связанных Pod’ов, чтобы избежать действий на устаревших данных.
Отдельный слой — наблюдаемость (observability). В kube-controller-manager добавлена метрика stale_sync_skips_total, которая показывает, сколько раз контроллер пропустил синхронизацию из-за устаревшего кеша. Также client-go публикует store_resource_version для каждого informer’а. Это даёт возможность сравнить состояние кеша с API server и диагностировать lag. Метрики включены по умолчанию, но остаются в alpha-статусе. Это сигнал, что интерфейс и семантика могут измениться.
Результат — более предсказуемое поведение контроллеров в условиях гонок и высокой конкуренции, особенно для Pod-ориентированных контроллеров. При этом точных метрик улучшения не приводится. Важно другое: система начинает явно различать “нет действия потому что не нужно” и “нет действия потому что кеш устарел”. Это снижает класс трудноуловимых ошибок, которые раньше проявлялись только в продакшене.
Дальнейшее развитие ожидаемо смещается в сторону controller-runtime, чтобы сделать эти гарантии стандартом для всех кастомных контроллеров. Это логичный шаг: проблема staleness не уникальна для встроенных компонентов, а является системным свойством архитектуры с кешем и eventual consistency.