2026年8月ECS与containerd可用镜像源清单

这次整理一份用于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.1ghcr.1ms.run/open-webui/open-webui:maink8s.1ms.run/pause:3.10quay.1ms.run/prometheus/prometheus:v3.0.0mcr.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 -msudo crictl infosudo containerd config dump > /tmp/containerd-config.txtgetent hosts k8s.1ms.run

还要记录ECS地域、VPC出口、NAT、袋里和失败节点。control-plane或运维机能访问，不代表实际worker节点能够访问。

三、containerd按来源配置

containerd版本和发行版不同，常见配置位置包括：

/etc/containerd/config.toml/etc/containerd/certs.d//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 containerdsudo systemctl status containerd --no-pagersudo 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.10sudo crictl pull quay.1ms.run/prometheus/prometheus:v3.0.0sudo 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 UnauthorizedDocker-Distribution-Api-Version: registry/2.0WWW-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 NAMESPACEkubectl get events -n NAMESPACE --sort-by=.lastTimestamp | tail -n 30sudo 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。