Dragonfly 和 Kraken 是专为容器镜像设计的 P2P 分发系统，用于缓解 registry 压力、加速大规模集群镜像拉取；它们非 Docker 官方仓库，也非 CDN，且需客户端配置重写镜像地址或 DNS 重定向才能生效。
Dragonfly 和 Kraken 是什么，不是什么
它们都不是 Docker 官方镜像仓库，也不是传统 CDN；而是专为容器镜像设计的 P2P 分发系统，核心价值在缓解 registry 压力、加速大规模集群内的镜像拉取。如果你只有一两台机器，或用的是私有 registry + 本地缓存（比如 registry-mirror），加 Dragonfly/Kraken 反而引入额外运维负担和延迟。
怎么让 docker pull 走 Dragonfly 或 Kraken
必须改客户端配置，不是服务端装完就自动生效。关键在重写镜像地址（mirror rewrite）和拦截请求（proxy mode）：
- Dragonfly：需在客户端部署
dfdaemon，并配置registries.mirrors指向http://<dfdaemon-host>:65001</dfdaemon-host>，同时 registry 地址要改成dragonfly-registry.example.com这类别名（靠dfget的 registry proxy 拦截） - Kraken：更依赖客户端 DNS 或 hosts 重定向——把
registry.example.com解析到 Kraken 的origin服务（非 registry 本身），再由 Kraken 决定走 P2P 还是回源；不改 DNS 就完全不触发分发逻辑 - 两者都不支持直接
docker pull registry.example.com/image:tag就自动走 P2P；没做地址重写=走原生 HTTP，绕过所有 P2P 层
dfdaemon 启动失败常见报错和修复点
最常卡在 failed to start dfdaemon: failed to init storage: mkdir /var/lib/dragonfly/dfdaemon: permission denied ——这不是权限配置问题，而是 dfdaemon 默认以非 root 用户运行，但数据目录 /var/lib/dragonfly/dfdaemon 是 root 创建且未开放 group 写入。解决方式很具体：
- 手动创建目录：
sudo mkdir -p /var/lib/dragonfly/dfdaemon - 查
dfdaemon运行用户（默认dragonfly）：id -u dragonfly - 赋权：
sudo chown dragonfly:dragonfly /var/lib/dragonfly/dfdaemon，不能只chmod 777，会触发安全校验失败 - 若用 systemd，确认
User=dragonfly和Group=dragonfly与目录属主一致，否则启动时仍报错
Kraken 的 origin 和 peer 配置容易混淆
很多人以为 origin 就是原始 registry，其实它是 Kraken 自己的“源站代理”，必须能直连真实 registry（比如 https://registry-1.docker.io），而 peer 才是真正参与 P2P 上传下载的节点。典型错误是：
立即学习“Python免费学习笔记（深入）”；
- 把
origin.address配成内网 registry 地址，但该 registry 不支持GET /v2/直接响应（比如开了鉴权或反向代理拦截），导致所有 peer 拉取失败，错误日志里反复出现origin returned status code 401 -
peer.listen绑定127.0.0.1，外部 peer 无法连接，P2P 网络直接退化成单点下载 - 没开
peer.enableP2P（默认 false），即使所有配置都对，也纯走 origin 下载，毫无 P2P 行为
真实环境里，peer 节点间网络连通性、TLS 证书信任链、origin 的健康探测超时（origin.healthCheckTimeout）才是压测时突然掉速的根本原因，不是带宽或磁盘问题。
