Я слышал, ты любишь оркестраторы. Поэтому мы построили оркестратор для оркестратора - чтобы управлять тысячами кластеров, пока они управляют твоими подами

Kubernetes отлично управляет контейнерами.
Но кто управляет тысячами Kubernetes-кластеров?

Пока у нас было до +/-2000 кластеров, монолитная система управления (vapi/salt) справлялась.
Инфраструктура была относительно предсказуемой, а массовые операции - редкими.

Перелом произошел позже.
Когда количество кластеров превысило +/-2000, и значительная их часть начала активно масштабироваться вверх и вниз, инфраструктура стала динамической.

Каждое autoscaling-событие генерировало новые операции:
- добавление и удаление нод,
- пересчет конфигураций,
- обновление статусов,
- reconcile-процессы,
- фоновую синхронизацию состояний.

Количество параллельных задач выросло кратно.
Очереди начали накапливаться.
Массовые операции стали триггерить падения монолита.
Проблемой стал не Kubernetes.
Проблемой стал оркестрационный слой над ним.

Мы полностью отказались от монолитной модели и построили KTL - распределенную систему оркестрации для Managed Kubernetes и платформ Kubernetes в целом.

В докладе разберем:
-где проходит архитектурный предел монолита при управлении тысячами кластеров;
-какие bottleneck’и проявляются при переходе к динамической инфраструктуре;
-как спроектировать отказоустойчивый оркестрационный слой;
-как безопасно управлять клиентскими кластерами через агентную модель;
-как реализовать контролируемые массовые операции с возможностью мгновенной отмены.

Это практический разбор эволюции платформы: от хрупкого централизованного инструмента - к выделенному распределенному слою управления.