Would it make sense to pull the images required by kubeadm during image build using kubeadm config images pull as suggested by kubeadm?

Jan 22 12:47:26 metal-test-controlplane-flzbk kubeadm.sh[1624]: [preflight] Running pre-flight checks
Jan 22 12:47:26 metal-test-controlplane-flzbk kubeadm.sh[1624]: [preflight] Pulling images required for setting up a Kubernetes cluster
Jan 22 12:47:26 metal-test-controlplane-flzbk kubeadm.sh[1624]: [preflight] This might take a minute or two, depending on the speed of your internet connection
Jan 22 12:47:26 metal-test-controlplane-flzbk kubeadm.sh[1624]: [preflight] You can also perform this action in beforehand using 'kubeadm config images pull'

Would it make sense to pull the images required by kubeadm during image build using kubeadm config images pull as suggested by kubeadm?

Jan 22 12:47:26 metal-test-controlplane-flzbk kubeadm.sh[1624]: [preflight] Running pre-flight checks
Jan 22 12:47:26 metal-test-controlplane-flzbk kubeadm.sh[1624]: [preflight] Pulling images required for setting up a Kubernetes cluster
Jan 22 12:47:26 metal-test-controlplane-flzbk kubeadm.sh[1624]: [preflight] This might take a minute or two, depending on the speed of your internet connection
Jan 22 12:47:26 metal-test-controlplane-flzbk kubeadm.sh[1624]: [preflight] You can also perform this action in beforehand using 'kubeadm config images pull'

Would be surprised if this would work inside the docker build ?

We would need to download the tarballs listed by kubeadm:

# kubeadm config images list
registry.k8s.io/kube-apiserver:v1.30.9
registry.k8s.io/kube-controller-manager:v1.30.9
registry.k8s.io/kube-scheduler:v1.30.9
registry.k8s.io/kube-proxy:v1.30.9
registry.k8s.io/coredns/coredns:v1.11.3
registry.k8s.io/pause:3.9
registry.k8s.io/etcd:3.5.15-0

e.g. with crane pull <IMAGE> <TARBALL>

After that a systemd unit could initialize containerd's image store by importing these tarballs.

But perhaps it's to early to do this kind of cluster-startup-time optimization.

We would need to download the tarballs listed by kubeadm:

# kubeadm config images list
registry.k8s.io/kube-apiserver:v1.30.9
registry.k8s.io/kube-controller-manager:v1.30.9
registry.k8s.io/kube-scheduler:v1.30.9
registry.k8s.io/kube-proxy:v1.30.9
registry.k8s.io/coredns/coredns:v1.11.3
registry.k8s.io/pause:3.9
registry.k8s.io/etcd:3.5.15-0

e.g. with crane pull <IMAGE> <TARBALL>

After that a systemd unit could initialize containerd's image store by importing these tarballs.

But perhaps it's to early to do this kind of cluster-startup-time optimization.

And most of these images are only required by the control-plane nodes.
I would not put these into the image, instead relay on a caching image proxy somewhere in the infrastructure