경량 드래곤플라이 배포: 데이터베이스 스택 불필요 P2P 배포

Posted on August 13, 2026 by Wenbo Qi (Gaius), Dragonfly Maintainer Dragonfly speeds up file and container image distribution using peer-to-peer (P2P) technology, but a standard installation deploys several components and dependencies. Beyond the Scheduler, Seed Client, and Client that move data, a traditional setup requires a Manager for dynamic configuration, backed by MySQL and Redis. While that architecture fits platform teams running Dragonfly across large multi-cluster fleets, it can be heavy for a single cluster focused primarily on resolving registry overload during image pulls.

Dragonfly supports a lightweight deployment model that removes the Manager, MySQL, and Redis. The Scheduler serves as the sole coordination component, allowing you to install the entire setup with a single Helm command. This post explains how the lightweight architecture operates and demonstrates how to run it in a local kind cluster. The Manager acts as Dragonfly’s control plane. It hosts the web console, exposes open APIs for integrations (such as registry-triggered preheating), manages relationships across multiple P2P clusters, and distributes dynamic configurations to Schedulers and Clients.

It persists state in MySQL and uses Redis for caching and asynchronous job distribution. These resources are essential at fleet scale. However, for a single cluster focused strictly on P2P distribution, the primary feature required is dynamic configuration. In practice, single-cluster dynamic configuration consists of YAML settings defining scheduling limits, blocklists, and endpoint details for Clients to discover Schedulers. Decoupling the Scheduler and Client from the Manager allows them to run autonomously without requiring a database backend when no Manager address is configured.

The lightweight deployment replaces the Manager control plane with two native Kubernetes primitives: a ConfigMap and a headless Service. addr is unset, the Scheduler and Client load dynamic configurations from a local /etc/dragonfly/dynconfig. yaml file, which the Helm chart mounts via a ConfigMap . If the file is not present, default values are generated on startup. The Scheduler’s dynconfig. yaml defines cluster-level scheduling parameters: The Scheduler and Client reload this configuration periodically (controlled by refreshInterval , which defaults to one minute).