# P16. Oakestra: иерархическая оркестрация edge-кластера

- **Версия и дата проверки:** 1.1, 07.09.2026.
- **Статус:** готово к назначению.

## Статья и исходные материалы

- **Основная статья:** Giovanni Bartolomeo и соавт. — [Oakestra: A Lightweight Hierarchical Orchestration Framework for Edge Computing](https://www.usenix.org/system/files/atc23-bartolomeo.pdf). USENIX ATC 2023.
- **Кратко о статье:** Edge-инфраструктура состоит из географически распределённых и неоднородных узлов, поэтому единый центральный оркестратор плохо масштабируется и не всегда видит локальные условия. Oakestra организует управление иерархически: верхний уровень координирует систему, а локальные уровни принимают решения в своих кластерах. В проекте иерархическая политика размещения сравнивается с централизованной на изменяющихся ресурсах и отказах.
- **Почему результат актуален:** проект продолжает развиваться после публикации и остаётся специализированной открытой платформой для edge orchestration. Проверяемый механизм охватывает распределённое размещение и управление при слабых узлах и нестабильных связях и выходит за пределы конкретного edge-приложения.
- **Артефакты и данные:** [oakestra/oakestra](https://github.com/oakestra/oakestra) под Apache-2.0, с оркестраторами, worker-компонентами, сетевым слоем и документацией локального развёртывания. Зафиксированные ревизии: `oakestra/oakestra@2d74107a14d8` (Apache-2.0).
- **Что уже предоставляет артефакт:** Oakestra предоставляет корневой и кластерный оркестраторы, worker-компоненты, сеть и локальное развёртывание. Их можно использовать как реализацию иерархического варианта.

## Обязательный результат

- **Проверяемый вопрос или утверждение:** делегирование решений по иерархии уменьшает нагрузку на центральный уровень и позволяет учитывать локальные ресурсы, сохраняя приемлемое время размещения сервисов.
- **Технический результат:** Развернуть корневой оркестратор, один кластерный оркестратор и 2–4 рабочих процесса или контейнера. Реализовать централизованный baseline, общий генератор запросов на размещение и автоматическую проверку ограничений CPU и памяти и фактического назначения сервисов.
- **Обязательное приращение команды:** Создать предусмотренные централизованный baseline, генератор запросов на размещение и независимую проверку ограничений и фактических назначений. Организовать одинаковые входы и измерения для сравнения двух вариантов на малом стенде.
- **Эксперимент:** на подготовленном стенде сравнить централизованную и иерархическую политику на серии размещений при ограничениях CPU и памяти, измеряя время решения, успешность размещения, служебный трафик и потребление ресурсов control plane.
- **Границы выводов:** сравнение проверяет механизм размещения при одном корневом и одном кластерном оркестраторе и 2–4 рабочих узлах; оно не оценивает масштабирование многоуровневой edge-топологии и нестабильность реальной сети.
- **Ресурсный профиль:** расширенно локально, Linux, Docker, CPU, желательно 16 ГБ памяти. При проблемах со сборкой полного сетевого слоя сохранить реальные компоненты планирования и заменить worker-узлы контролируемыми локальными агентами.

## Содержательные направления

- стенд и наблюдаемость управляющего уровня.
- политики размещения и инъекция ограничений.
- метрики масштабирования, отказов и новая политика.

## Возможное продолжение

Добавить задержку или разрыв связи между уровнями, неоднородность узлов, предпочтение локальности либо собственную политику повторного размещения после отказа.