Kubernetes 集群初始化镜像下载代理请教

[cookgo]

• 我在尝试搭建 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 好像没有正确识别？

[singerll]

好像镜像下载后需要自建镜像服务器的，也好像 init 时要改下配置文件，把镜像地址指过去。时间太久了记不清了。

[seers]

我是换成国内源安装的，你可以试下
kubeadm init --image-repository='registry.cn-hangzhou.aliyuncs.com/google_containers'

[whoisnian]

印象 kubeadm 用 containerd 的时候会有一个单独的 namespace：
ctr namespaces ls
ctr --namespace k8s.io images ls

[whoisnian]

附一个之前搜到的 issue 地址
https://github.com/kubernetes-sigs/cri-tools/issues/546#issuecomment-646909445

[Blank10030]

3 楼已经解答了。

[asilin]

3 楼已经解答了。

[plko345]

可以像 2 楼那样传参，或在 config 里指定源，kubeadm 有个子命令可以只 pull 镜像，然后像 3 楼那样查看镜像是否都在，也可以使用 nerdctl

[zscself]

可以尝试给 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)

[zscself]

@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.

[cookgo]

确实没注意 namespace 的问题，谢谢大家🙏