Closed devbiu closed 11 months ago
There are no sig labels on this issue. Please add an appropriate label by using one of the following commands:
/sig <group-name>
/wg <group-name>
/committee <group-name>
Please see the group list for a listing of the SIGs, working groups, and committees available.
This issue is currently awaiting triage.
If a SIG or subproject determines this is a relevant issue, they will accept it by applying the triage/accepted
label and provide further guidance.
The triage/accepted
label can be added by org members by writing /triage accepted
in a comment.
/kind support /transfer registry.k8s.io
note there are number of similar issues. it's not a kubeadm bug, but a problem with your internet or registry.k8s.io https://github.com/kubernetes/registry.k8s.io/issues https://github.com/kubernetes/registry.k8s.io/issues/262
It looks like your local DNS server is refusing requests?
It looks like your local DNS server is refusing requests?
because the local network cannot connect to the Internet
So I imported the required image in advance so that it cannot be downloaded remotely
and using image pull policy IfNotPresent
So should I no longer pull images from remote locations?
So I imported the required image in advance so that it cannot be downloaded remotely
did you import them in the k8s.io namespace?
So I imported the required image in advance so that it cannot be downloaded remotely
did you import them in the k8s.io namespace?
This is okay for me I mistakenly understood that the runtime of kubadm is docker, but the actual runtime is containerd. So after I imported the image into the k8s namespace k8s.io through ctr, modified its tag through the command as follows
I re-executed
kubeadm init --v=5
and was able to find the image.
Thank you for your answer
What puzzles me is why the runtime is containerd instead of docker. As far as I know, lower versions of kubernetes import the image into docker instead of ctr. Can you explain it to me?
What puzzles me is why the runtime is containerd instead of docker. As far as I know, lower versions of kubernetes import the image into docker instead of ctr. Can you explain it to me?
docker is no longer supported by default by kubeadm and core kubernetes. there is a new container runtime "shim" called cri-dockerd that is needed.
if you used kubeadm config images pull ...
, then kubeadm would use crictl
to download the images in the container runtime it found. probably in your case it only found the containerd socket.
closing as not a bug /close
@neolit123: Closing this issue.
@neolit123: Closing this issue.
What happened?
download kubernetes-1.24.17.tar.gz to local environment use commond
compile kubeadm config images list view require images as follow
because only the tag in the docker is 1.24.17 image, use the tag command to modify the tag of the image
enable corresponding images and tags
subsequent execution commond
alter still asks me to pull images
What did you expect to happen?
kubernetes install success
How can we reproduce it (as minimally and precisely as possible)?
Anything else we need to know?
No response
Kubernetes version
Cloud provider
OS version
Install tools
Container runtime (CRI) and version (if applicable)
Related plugins (CNI, CSI, ...) and versions (if applicable)