这次整理一份用于ECS、Kubernetes和containerd节点的8月镜像源清单。
8月3日，我在独立测试环境检查了9个Registry /v2/入口，并对Docker Hub、GHCR、K8s、Quay和MCR五类具体镜像完成了Bearer Token与manifest请求。测试并非在阿里云ECS上完成，当前环境也没有启动Docker daemon，因此本文不比较速度；在目标地域和实际worker节点上仍要执行crictl pull或ctr images pull。
一、8月镜像源清单
| 原始来源 | 国内访问入口 | 8月3日验证层级 | ECS/K8s常见场景 |
|---|---|---|---|
| Docker Hub | docker.1ms.run |
端点 + manifest通过 | 基础镜像、业务容器 |
| GHCR | ghcr.1ms.run |
端点 + manifest通过 | GitHub项目、AI服务 |
| Kubernetes | k8s.1ms.run |
端点 + manifest通过 | pause、集群组件 |
| Quay | quay.1ms.run |
端点 + manifest通过 | Prometheus、Operator |
| MCR | mcr.1ms.run |
端点 + manifest通过 | Playwright、Microsoft工具 |
| NVIDIA NGC | nvcr.1ms.run |
Registry端点响应通过 | GPU节点、CUDA环境 |
| Elastic | elastic.1ms.run |
Registry端点响应通过 | Elastic Stack |
| Docker Hub备用 | docker.m.daocloud.io |
Registry端点响应通过 | Docker Hub备用 |
| DaoCloud多源路径 | m.daocloud.io |
Registry端点响应通过 | 需要完整上游路径 |
本轮通过manifest验证的镜像是：
docker.1ms.run/library/busybox:1.36.1
ghcr.1ms.run/open-webui/open-webui:main
k8s.1ms.run/pause:3.10
quay.1ms.run/prometheus/prometheus:v3.0.0
mcr.1ms.run/playwright/mcp:latest
NVCR、Elastic与两个DaoCloud入口本轮只完成Registry端点检查，实际业务镜像需要单独复验。
二、先确认ECS节点使用什么运行时
在Kubernetes环境执行：
kubectl get node NODE_NAME \
-o jsonpath='{.status.nodeInfo.containerRuntimeVersion}'
echo
如果返回containerd，就不要只修改/etc/docker/daemon.json。
节点侧先保存环境信息：
uname -m
sudo crictl info
sudo containerd config dump > /tmp/containerd-config.txt
getent hosts k8s.1ms.run
还要记录ECS地域、VPC出口、NAT、代理和失败节点。control-plane或运维机能访问，不代表实际worker节点能够访问。
三、containerd按来源配置
containerd版本和发行版不同，常见配置位置包括：
/etc/containerd/config.toml
/etc/containerd/certs.d/<registry>/hosts.toml
如果使用hosts.toml，应为不同原始Registry建立各自目录与入口，不要把Docker Hub、GHCR、Quay和K8s混成一个mirror。
以Docker Hub为例，常见结构是：
server = "https://registry-1.docker.io"
[host."https://docker.1ms.run"]
capabilities = ["pull", "resolve"]
修改后检查：
sudo systemctl restart containerd
sudo systemctl status containerd --no-pager
sudo crictl pull docker.1ms.run/library/busybox:1.36.1
不同版本是否启用config_path、是否读取certs.d，应以containerd config dump的实际输出为准。
四、逐类验证镜像
在目标节点执行：
sudo crictl pull k8s.1ms.run/pause:3.10
sudo crictl pull quay.1ms.run/prometheus/prometheus:v3.0.0
sudo crictl pull ghcr.1ms.run/open-webui/open-webui:main
需要直接使用ctr时：
sudo ctr -n k8s.io images pull \
k8s.1ms.run/pause:3.10
同一集群有AMD64与ARM64节点时，要分别拉取。manifest list存在，不代表每个业务镜像都包含两种架构。
五、Registry端点如何判断
在失败节点执行：
curl -I --connect-timeout 5 --max-time 15 \
https://k8s.1ms.run/v2/
如果同时出现：
401 Unauthorized
Docker-Distribution-Api-Version: registry/2.0
WWW-Authenticate: Bearer ...
更像Registry v2正常认证挑战。后续还要继续确认Token realm、manifest、镜像层和containerd凭据。
所以镜像源验证至少分四层：
节点DNS/TCP/TLS
→ Registry v2与认证挑战
→ Token、manifest、tag和架构
→ config与layers真实下载
六、ImagePullBackOff是补充排查入口
如果Pod已经进入ImagePullBackOff，先看事件：
kubectl describe pod POD_NAME -n NAMESPACE
kubectl get events -n NAMESPACE \
--sort-by=.lastTimestamp | tail -n 30
sudo journalctl -u containerd --since "15 min ago"
| 原始错误 | 优先检查 |
|---|---|
401或403 |
imagePullSecrets、Token、repository权限 |
429 |
NAT共享出口、扩容并发、重试频率 |
| timeout | 节点DNS、TLS、代理、VPC与NAT |
manifest unknown |
镜像名、tag、来源 |
no matching manifest |
节点CPU架构 |
ImagePullBackOff只是汇总状态，不应取代前面的镜像源清单与逐源验证。
七、维护窗口前的清单
- 在每个节点检查Registry v2响应。
- 分别验证Docker Hub、K8s、Quay和业务实际来源。
- 预拉
pause与关键业务基础镜像。 - 核对AMD64/ARM64 manifest。
- 检查containerd配置在所有节点一致。
- 固定关键镜像tag或digest。
- 将生产关键镜像同步到内部仓库。
- 保存测试日期、地域、节点与错误原文。
截至2026年8月3日，表中9个入口都有规范Registry v2响应，5个具体manifest完成验证。用于ECS与containerd时，最终结论应来自实际worker节点，而不是运维机上的一次docker pull。
