Лёгкое развёртывание Dragonfly без базы данных: P2P через ConfigMap и headless Service¶
8.0/10
Контекст¶
Стандартный Dragonfly использует Manager как control plane, а для хранения и кэширования — MySQL и Redis; для одного кластера, где нужен лишь P2P при скачивании образов, такой стек избыточен. Автор, мейнтейнер Dragonfly, описывает лёгкий режим, в котором Manager, MySQL и Redis не разворачиваются.
Суть¶
В этой модели Scheduler остаётся единственным координатором, а вместо Manager используются два нативных примитива Kubernetes: ConfigMap и headless Service. Когда manager.addr не задан, Scheduler и Client читают локальный /etc/dragonfly/dynconfig.yaml, смонтированный из ConfigMap, с параметрами планирования — лимитами, блоклистами и адресами для обнаружения. Конфигурация перечитывается по refreshInterval (по умолчанию минута), поэтому изменения доходят до подов без перезапуска. Для discovery клиент резолвит DNS-имя headless-сервиса, получает адреса всех Scheduler, проверяет их здоровье и автоматически подстраивается при масштабировании; при статических адресах можно использовать scheduler.addrs. В кластер ставятся только Scheduler, Seed Client и Client DaemonSet — без резервных копий БД и миграций. Автор приводит сравнение: лёгкий вариант не даёт постоянных задач, OpenAPI и веб-консоли; добавление Redis добавляет персистентность, а полный Manager — всё остальное. В статье есть воспроизводимый пример на kind: Helm-установка, проверка crictl pull и прехотинг через dfctl, а также опция dragonfly-injector для прямой P2P-загрузки артефактов из приложений. В конце честно указано, что Manager остаётся выбором для мультикластера, веб-интерфейса и интеграций.
Вывод¶
Вывод автора: лёгкое развёртывание — допустимый базовый вариант для одного кластера, edge или CI, так как сохраняет динамическую конфигурацию и P2P-доставку средствами Kubernetes; тяжёлая архитектура с Manager нужна только при превращении Dragonfly в централизованную платформу.