向Azure Container Registry推送Docker镜像速度不稳定，寻求优化方案

我之前帮团队排查过几乎一模一样的问题，这种白天/夜间的性能差异大概率和网络带宽竞争或者ACR的区域负载有关，给你几个实际验证有效的解决思路：

• 检查构建代理与ACR的区域一致性
  很多人容易忽略这点：如果你的Azure VM代理和ACR不在同一个Azure区域，跨区域传输会受骨干网负载影响，白天UTC时段全球流量高峰时延迟会暴增。建议把代理VM迁移到和ACR相同的区域，或者直接用Azure DevOps托管的同区域代理，这样能彻底避免跨区域的网络瓶颈。

• 优化镜像推送的分层策略
  Docker镜像推送是分层传输的，冗余分层或全新分层过多会放大网络拥堵的影响：

  • 用docker build --cache-from参数复用ACR中已有的镜像分层，减少需要推送的新内容
  • 清理镜像内的冗余文件（比如构建依赖、临时安装包），缩小镜像总大小
  • 启用ACR的分层缓存功能（标准层支持），让重复分层的推送速度大幅提升

• 调整ACR的网络访问配置
  标准层ACR默认走公网访问，白天公网拥堵会直接影响推送速度：

  • 如果代理VM在Azure VNet内，给ACR配置专用端点，让镜像推送流量走Azure内部VNet，避开公网干扰
  • 给ACR设置IP允许列表，只开放代理VM的IP访问，减少无关流量的影响

• 监控定位性能瓶颈
  用Azure Monitor给ACR和代理VM加针对性监控：

  • 查看ACR的PushImageLatency、RegistryWriteBytes指标，确认是不是ACR本身在白天负载过高
  • 监控代理VM的NetworkOut带宽使用率，看是否存在同集群内的资源竞争
  • 在流水线中加入az acr check-health命令，记录每次推送前后的网络连通性数据，方便定位问题

• 考虑升级ACR层级
  标准层ACR的吞吐量是区域共享的，白天全球用户集中使用时可能会被限流。如果预算允许，升级到高级层，高级层支持预留吞吐量，能保证稳定的推送速度，同时支持更高的并发操作。

另外，社区里也有不少用户遇到过类似的UTC白天延迟问题，大多是跨区域网络或ACR共享带宽导致的，上面的方法应该能帮你缓解甚至解决问题。

内容的提问来源于stack exchange，提问作者rudolfdobias