K3s镜像拉取失败源于其独立containerd运行时与宿主机docker隔离，需检查/var/lib/rancher/k3s/agent/containerd镜像库、config.toml镜像加速配置、sandbox镜像拉取及dns/TLS校验。
这说明镜像拉取能力本身没问题，问题出在 K3s 的运行时上下文或配置层面。K3s 默认用 containerd 作为容器运行时，它和 Docker 是两套独立的镜像存储与网络栈，即使宿主机上 docker pull 或 crictl pull 成功，也不代表 K3s 能复用或正确访问这些镜像。
检查 containerd 是否真正加载了镜像
K3s 管理自己的 containerd 实例，其镜像库路径是独立的（通常为 /var/lib/rancher/k3s/agent/containerd），和宿主机 Docker 的 /var/lib/docker 完全隔离。
- 确认当前 K3s 使用的 containerd 是否看到目标镜像：
sudo crictl -r unix:///run/k3s/containerd/containerd.sock images - 如果没列出，说明镜像没被 K3s 的 containerd 加载 —— 即使你用
crictl pull拉过，也得指定正确的 socket（默认 K3s 不走系统级 containerd） - 手动导入镜像（如已下载 tar 包）：
sudo ctr -n k8s.io i import nginx.tar
确认 K3s 使用的 registry 配置是否生效
K3s 启动时会自动生成 containerd 的配置文件：/var/lib/rancher/k3s/agent/etc/containerd/config.toml。若未显式配置镜像加速器，它默认直连 docker.io，极易超时。
- 检查该 config.toml 中是否包含
registry.mirrors或registry.configs段落 - 常见有效配置（以阿里云镜像为例）：
[plugins.”io.containerd.grpc.v1.cri”.registry.mirrors.”docker.io”]
endpoint = [“https://registry.cn-hangzhou.aliyuncs.com”] - 修改后必须重启 K3s：
sudo systemctl restart k3s
排查 sandbox 镜像拉取失败（常见于 pause 镜像）
K3s 启动 Pod 前必须先拉取 sandbox 镜像（如 rancher/mirrored-pause:3.6），这个步骤失败会导致所有 Pod 卡在 ContainerCreating，且错误日志常不提示具体镜像名。
- 查看 K3s 日志定位实际失败镜像：
sudo journalctl -u k3s -n 100 --no-pager | grep -i "failed.*pull|sandbox" - 手动拉取并重打标签（关键一步）：
sudo crictl pull registry.cn-hangzhou.aliyuncs.com/google_containers/pause:3.6sudo ctr -n k8s.io i tag registry.cn-hangzhou.aliyuncs.com/google_containers/pause:3.6 k8s.gcr.io/pause:3.6 - 若使用私有仓库，还需确保
ctr已登录：sudo ctr -n k8s.io auth login registry.example.com -u user -p pass
验证 DNS 和 TLS 握手是否被干扰
K3s 的 containerd 在拉取镜像时使用自己的 DNS 解析和证书校验逻辑，和宿主机可能不同。
- 测试 containerd 是否能解析镜像域名：
sudo nslookup docker.io $(cat /var/lib/rancher/k3s/agent/etc/containerd/resolv.conf 2>/dev/NULL | head -1 | cut -d' ' -f2) - 检查是否因证书问题失败（尤其拉 gcr.io、quay.io）：
curl -v https://k8s.gcr.io/v2/ 2>&1 | grep -i "ssl|certificate" - 若需信任自签名 CA，需将证书放入：
/var/lib/rancher/k3s/agent/etc/containerd/certs.d/k8s.gcr.io/ca.crt