Dragonfly 2.5 ships Kubernetes webhook injection, drops V1 preheat

Dragonfly v2.5.0 shipped on June 30, per the CNCF release post, and the headline for platform teams running it as a registry cache is on the Kubernetes side: a new admission webhook now injects the P2P client into pods without rebuilding container images. For fleets that pulled large model layers across the same node pool, that removes one base-image migration before turn-on.

What landed in 2.5

The release notes from Dragonfly maintainer Gaius Qi list a handful of moving parts:

• dfget gains an hf:// scheme that pulls Hugging Face and ModelScope repositories through the P2P mesh with Git LFS acceleration. Useful if a CI job fetches a fresh model on every run.
• dfdaemon can infer the upstream registry from the ns query parameter that containerd appends when configured as a registry mirror. The benefit is fewer per-registry config blocks to maintain.
• A download blocklist lets operators return PermissionDenied or FORBIDDEN on specific URLs as an emergency mitigation, without a redeploy.
• A new dfctl CLI manages the client's local storage, including tasks, persistent tasks and persistent cache tasks.
• Rate limits arrive on unary and streaming gRPC requests, alongside client-side bandwidth controls.

Where it bites you on upgrade

Two pieces of operational debt to absorb. The deprecated V1 preheat API endpoints are gone in 2.5; pipeline scripts still calling them stop working on upgrade. Health checks consolidate to /healthy, so probes wired to old paths need to move with that.

The project framing on the webhook is zero-rebuild rollout. The catch is operational: a mutating admission webhook is a runtime dependency at pod-creation time, and a webhook outage fans out across every workload that needs the injection. The CNCF post does not break out a migration path off V1 preheat; the release notes are the place to read before running the upgrade.