Server-side sharded list and watch в Kubernetes меняет поведение контроллеров. Это попытка убрать системный потолок при работе с high-cardinality ресурсами.
Когда Kubernetes-кластеры вырастают до десятков тысяч нод, контроллеры упираются в масштабируемость не там, где её обычно ждут. Проблема возникает на уровне list/watch взаимодействия с API server. Каждый экземпляр горизонтально масштабируемого контроллера получает полный поток событий по ресурсам вроде Pods. Затем он тратит CPU, память и сеть на десериализацию, чтобы отбросить большую часть объектов. Горизонтальное масштабирование не снижает стоимость обработки на реплику. Оно просто умножает общий расход. Это классический случай, когда система масштабируется по количеству инстансов, но не по эффективности.
Решение в Kubernetes v1.36 — server-side sharded list and watch. Это альфа-функция, которая переносит фильтрацию на уровень API server. Вместо того чтобы каждый контроллер фильтровал поток локально, сервер отправляет только релевантные события. Каждая реплика контроллера получает свой сегмент данных, определённый через shardSelector. Это снижает лишний трафик и убирает дублирующую работу. Компромисс здесь очевиден: усложняется логика взаимодействия с API, и появляется зависимость от новой функции, которая пока в alpha-стадии.
На уровне реализации добавляется поле shardSelector в ListOptions. Клиент задаёт диапазон хеша через shardRange(). API server вычисляет детерминированный 64-битный FNV-1a хеш по выбранному полю и возвращает только те объекты, которые попадают в диапазон [start, end). Это работает как для list-ответов, так и для watch-потоков. Важно, что хеш-функция детерминирована между всеми экземплярами API server, поэтому поведение остаётся консистентным в распределённой конфигурации.
Поддерживаются конкретные поля: object.metadata.uid и object.metadata.namespace. Это ограничение влияет на стратегию шардирования. Контроллеры, использующие informers, могут внедрить shardSelector через WithTweakListOptions. В простом случае, например с двумя репликами, пространство хеша делится пополам. При необходимости можно задать несколько диапазонов с помощью логического OR, чтобы покрывать несмежные сегменты.
Есть важная деталь: API server явно сигнализирует, применён ли шард. В ответе появляется поле shardInfo. Если его нет, значит сервер проигнорировал shardSelector, и клиент получил полный набор данных. В таком сценарии контроллер должен быть готов вернуться к client-side фильтрации. Это критично для обратной совместимости и стабильности.
С точки зрения результата, основной эффект — снижение нагрузки на сеть и CPU за счёт уменьшения объёма данных, проходящих через каждый контроллер. Конкретные метрики в исходных данных не приведены, но архитектурный выигрыш очевиден: уменьшается дублирование работы и нагрузка на API server. Однако остаётся вопрос зрелости решения, так как функция находится в alpha и требует включения feature gate ShardedListAndWatch.
В индустрии подобный подход давно обсуждается как более корректная модель масштабирования наблюдателей (watchers). Kubernetes делает прагматичный шаг в эту сторону, перенося фильтрацию ближе к источнику данных. Это не устраняет все ограничения, но убирает один из наиболее затратных узких мест.