Dragonfly спростила P2P-доставку образів у Kubernetes: без Manager, MySQL і Redis

Open-source проєкт Dragonfly описав полегшений варіант розгортання P2P-доставки контейнерних образів і файлів у Kubernetes. Повна схема зазвичай містить Manager, MySQL і Redis, що виправдано для кількох кластерів та централізованої платформи. Для одного кластера ця інфраструктура часто надмірна, тому новий рекомендований стартовий режим залишає лише Scheduler, Seed Client і Client.
Manager, MySQL і Redis прибрано; конфігурацію забезпечує ConfigMap, а discovery — headless Service.
Чим замінили Manager
У повній інсталяції Manager тримає web console, Open API, зв’язки між P2P-кластерами та динамічну конфігурацію. Полегшена схема залишає два потрібні механізми на стороні самого Kubernetes. Параметри scheduler і client монтуються як dynconfig.yaml із ConfigMap, а client знаходить scheduler через DNS-адресу headless Service.
Якщо адресу Manager не задано, компоненти переходять у автономний режим. Файл конфігурації перечитується періодично, за замовчуванням приблизно раз на хвилину, тому зміни ConfigMap застосовуються без перезапуску pod. Ті самі поля доступні через Helm values, що спрощує GitOps і перевірку змін у репозиторії.
Три варіанти розгортання
Базовий lightweight режим підтримує звичайні tasks, blocklist і preheat через dfctl, але не зберігає persistent task metadata. Додавання Redis повертає persistent tasks і persistent cache tasks. Повний Manager потрібний для web console, Open API, personal access tokens, централізованого preheat та керування кількома P2P-кластерами.
Helm chart тепер робить lightweight стартовим вибором. На тестовому kind-кластері підіймаються Scheduler, Seed Client і по одному Client на worker-вузол. Після цього containerd може спрямовувати image pulls через Dragonfly, а успішну P2P-доставку видно в локальних логах dfdaemon.
Preheat і завантаження моделей
Попереднє прогрівання контенту не вимагає Manager. Утиліта dfctl звертається безпосередньо до gRPC-інтерфейсу Scheduler і може наказати одному seed peer, усім seed peers або всім client завантажити OCI-образ чи звичайний файл. Це корисно перед великим rollout, коли сотні вузлів одночасно запитують однакові шари.
Для моделей, датасетів і build artifacts, які завантажує вже сам застосунок, проєкт пропонує dragonfly-injector. Mutating admission webhook додає до pod клієнтські утиліти та Unix socket dfdaemon без перебудови application image. Інжектор працює і в полегшеному режимі, але потребує cert-manager для TLS webhook.
Коли спрощення доречне
Режим добре підходить одному Kubernetes-кластеру, edge-середовищу або CI, де головна проблема — навантаження на registry та повторне завантаження великих артефактів. Він зменшує кількість stateful залежностей, резервних копій і точок відмови. За потреби Manager можна додати пізніше зміною Helm values, не відмовляючись від базових P2P-компонентів.
Обмеження й безпека
Відсутність Manager означає відсутність централізованої консолі, Open API та токенів доступу. Команда має самостійно захистити Scheduler endpoint, ConfigMap і namespace, контролювати registry credentials та спостерігати за cache hit rate. Теги latest з демонстрації не варто переносити в production: образи слід фіксувати за версією або digest, а Helm chart — тестувати на staging. P2P також не скасовує перевірку підписів, SBOM і політику довіри до джерела артефакту.
Автор першоджерела: Wenbo Qi (Gaius).
Ліцензія: Apache License 2.0. Матеріал перекладено, переказано й адаптовано українською мовою.