解读

面试官想知道你是否能把“Docker 镜像”与“边缘场景”结合起来，给出可落地、可量化、可灰度、可回滚的完整方案。1000 节点、10 GB 镜像、公网带宽参差不齐、磁盘 IO 有限，是典型的大规模边缘冷启动场景。核心矛盾是“镜像太大、节点太多、带宽太贵、时间窗口短”。必须证明你熟悉 Dragonfly 的 P2P 调度原理，又能兼顾镜像分层、回源策略、预热、限速、安全、观测与应急。

知识点

1. Dragonfly 架构：Manager、Scheduler、Seed Peer、Peer 四层；基于 Piece 的 P2P 调度；支持 Docker Distribution、Harbor、Nexus 回源。
2. 镜像分层与可复用性：10 GB 镜像通常由基础层 + 业务层构成，只要基础层哈希一致即可复用，不必全量传输。
3. Piece 大小与并发：默认 4 MB，可动态调优；Piece 命中率高则回源流量指数级下降。
4. 预热策略：提前把镜像转为 Seed，利用夜间低峰窗口推送到超级节点，白天边缘节点只需 P2P 补齐差异层。
5. 限速与 QoS：支持基于网卡带宽 80% 上限的动态限速，防止打满边缘 20 Mbps 家用宽带。
6. 安全：Manager 与 Peer 之间双向 mTLS + JWT 令牌；镜像层摘要校验防止中间人篡改。
7. 观测：Prometheus 暴露 dragonfly_peer_task_total、dragonfly_seed_peer_download_bytes 等指标；Grafana 大盘需包含“回源率”与“P2P 效率”双曲线。
8. 回滚：若新镜像异常，通过 Harbor 保留旧版本 Tag，边缘节点原地 docker image prune -a 回退，无需重新拉取。

答案

“我会把 10 GB 镜像拆成三步：预热、灰度、全量，全程用 Dragonfly 做 P2P 加速，目标60 分钟内完成 1000 节点冷启动，回源流量 <5%。

第一步，预热。提前一天在 Harbor 推送新镜像，触发 Jenkins 调用‘dfget seed-peer’把镜像层转成 Seed；Seed Peer 部署在省会 IDC 机房 10 Gbps 专线节点，磁盘用 NVMe RAID0，确保单 Seed 可提供 2 Gbps 持续出流。
第二步，灰度。选 5% 节点（50 台）做灰度，Dragonfly Scheduler 开启自适应负载均衡，灰度过程观测‘piece hit ratio’≥95%、‘per-node download time’≤8 分钟即达标；若未达标，调小 piece 到 2 MB、提高并发度到 6。
第三步，全量。灰度通过后，通过 Ansible 批量修改边缘节点/etc/dragonfly/dfget.yaml，打开动态限速 80% 带宽上限；同时把 Scheduler 的‘peer TTL’从 30 min 调到 120 min，让更多节点成为二级种子，进一步摊薄回源。
最后，观测与应急。Prometheus 采集到‘seed_peer_download_bytes’突增即说明回源异常，5 分钟内可触发 Harbor 回滚并关闭 Scheduler 新任务分发，保证业务不受损。”

拓展思考

1. 如果 1000 节点里 30% 是弱网 4G/5G 场景，Dragonfly 的网络类型标签（network-location）如何与 Scheduler 协同，实现高延迟节点优先走本地缓存？
2. 当镜像里包含私有基础层（mcr.microsoft.com/dotnet/aspnet:6.0）且 Harbor 无法缓存时，如何通过双 Harbor 级联 + Dragonfly 回源白名单解决跨域拉取限速？
3. 在边缘 K3s 集群中，如何结合Containerd 的 snapshotter 插件实现按需拉取（lazy pulling），把 10 GB 镜像首屏启动时间压缩到 90 秒以内？