这是一个创建于 1093 天前的主题，其中的信息可能已经有所发展或是发生改变。
- 我在尝试搭建 Kubernetes 集群的时候，使用 containerd 作为容器载体.
- 根据
kubeadm config images list的显示手动下载了镜像（ GFW 所赐）并导入了服务器。
[root@endpoint1 ~]# ctr image ls REF TYPE DIGEST SIZE PLATFORMS LABELS registry.k8s.io/coredns/coredns:v1.9.3 application/vnd.docker.distribution.manifest.v2+json sha256:df9ab8f5cf54a9ec2ad6c14dadb4bd6c37e4bc80d54f0110534c4237607d2ea2 46.7 MiB linux/amd64 - registry.k8s.io/etcd:3.5.4-0 application/vnd.docker.distribution.manifest.v2+json sha256:6344c08db05c32c3efa9f9e1a8ac4cd61446d8eaaaff9ed127a2aad38ba34710 286.9 MiB linux/amd64 - registry.k8s.io/kube-apiserver:v1.25.3 application/vnd.docker.distribution.manifest.v2+json sha256:6ddffaff171282cfca9d5d8a9f23716594f14a7a57ab7fd453a5396f303d0a4c 123.1 MiB linux/amd64 - registry.k8s.io/kube-controller-manager:v1.25.3 application/vnd.docker.distribution.manifest.v2+json sha256:ce0aa9ed14d4eab0fdb500b30d59f7f29e5cc9933daab07f914a7f1b15497c52 113.0 MiB linux/amd64 - registry.k8s.io/kube-proxy:v1.25.3 application/vnd.docker.distribution.manifest.v2+json sha256:1058c14a03c1cb679cf998a8ed316670259902f9c192c340e3a788d7023b9588 60.3 MiB linux/amd64 - registry.k8s.io/kube-scheduler:v1.25.3 application/vnd.docker.distribution.manifest.v2+json sha256:e6ed9660ce1de770ce17cb5bfdbe5172d3e015e8caea248f3fce1f2372413bc4 49.5 MiB linux/amd64 - registry.k8s.io/pause:3.8 application/vnd.docker.distribution.manifest.v2+json sha256:bc7a375f431244f9649999cd506fe6dc4b7f071ddc385c6bcb372288d4b773d4 697.9 KiB linux/amd64 - - 可是当我再次运行
kubeadm init的时候，却卡在了镜像的下载流程那里
failed to pull image "registry.k8s.io/kube-apiserver:v1.25.3": output: E1105 21:52:46.054074 9369 remote_image.go:242] "PullImage from image service failed" err="rpc error: code = Unknown desc = failed to pull and unpack image \"registry.k8s.io/kube-apiserver:v1.25.3\": failed to resolve reference \"registry.k8s.io/kube-apiserver:v1.25.3\": failed to do request: Head \"https://asia-northeast1-docker.pkg.dev/v2/k8s-artifacts-prod/images/kube-apiserver/manifests/v1.25.3\": dial tcp 74.125.203.82:443: i/o timeout" image="registry.k8s.io/kube-apiserver:v1.25.3" time="2022-11-05T21:52:46+08:00" level=fatal msg="pulling image: rpc error: code = Unknown desc = failed to pull and unpack image \"registry.k8s.io/kube-apiserver:v1.25.3\": failed to resolve reference \"registry.k8s.io/kube-apiserver:v1.25.3\": failed to do request: Head \"https://asia-northeast1-docker.pkg.dev/v2/k8s-artifacts-prod/images/kube-apiserver/manifests/v1.25.3\": dial tcp 74.125.203.82:443: i/o timeout" , error: exit status 1 - 请问这个要如何解决呢？我已经手动导入了镜像，但是 kubeadm 好像没有正确识别？
 | 1 singerll 2022-11-05 22:05:32 +08:00 via Android 好像镜像下载后需要自建镜像服务器的，也好像 init 时要改下配置文件，把镜像地址指过去。时间太久了记不清了。 |
 | 2 seers 2022-11-05 22:07:52 +08:00 我是换成国内源安装的，你可以试下 kubeadm init --image-repository='registry.cn-hangzhou.aliyuncs.com/google_containers' |
 | 3 whoisnian 2022-11-05 22:26:49 +08:00 |
| 4 whoisnian 2022-11-05 22:29:33 +08:00 |
 | 5 Blank10030 2022-11-05 22:40:39 +08:00 3 楼已经解答了。 |
 | 6 asilin 2022-11-05 22:56:49 +08:00 via Android 3 楼已经解答了。 |
 | 7 plko345 2022-11-06 09:10:46 +08:00 via Android 可以像 2 楼那样传参，或在 config 里指定源，kubeadm 有个子命令可以只 pull 镜像，然后像 3 楼那样查看镜像是否都在，也可以使用 nerdctl |
 | 8 zscself 2022-11-06 10:39:06 +08:00 可以尝试给 containerd 设置代理 ```bash sudo mkdir -p /etc/systemd/system/containerd.service.d/ sudo touch /etc/systemd/system/containerd.service.d/http-proxy.conf sudo vi /etc/systemd/system/containerd.service.d/http-proxy.conf ``` ``` # /etc/systemd/system/containerd.service.d/http-proxy.conf [Service] EnvirOnment="HTTP_PROXY=http://[IP]:[PORT]" EnvirOnment="HTTPS_PROXY=http://[IP]:[PORT]" ``` ```bash sudo systemctl daemon-reload sudo systemctl restart containerd.service ``` [reference]( https://github.com/containerd/containerd/issues/1990#issuecomment-403414959) |
| 9 zscself 2022-11-06 10:42:05 +08:00 @whoisnian 三楼的延伸阅读： https://kubernetes.io/blog/2018/05/24/kubernetes-containerd-integration-goes-ga/ 里面是这么说的： A containerd namespace mechanism is employed to guarantee that Kubelet and Docker Engine won't see or have access to containers and images created by each other. This makes sure they won't interfere with each other. This also means that: Users won't see Kubernetes created containers with the docker ps command. Please use crictl ps instead. And vice versa, users won't see Docker CLI created containers in Kubernetes or with crictl ps command. The crictl create and crictl runp commands are only for troubleshooting. Manually starting pod or container with crictl on production nodes is not recommended. Users won't see Kubernetes pulled images with the docker images command. Please use the crictl images command instead. And vice versa, Kubernetes won't see images created by docker pull, docker load or docker build commands. Please use the crictl pull command instead, and ctr cri load if you have to load an image. |
 | 10 cookgo OP 确实没注意 namespace 的问题，谢谢大家 |
Select Language