After cluster creation auto load images to node

[nioshield]

What would you like to be added: After cluster creation auto load images to node, images name from config file

Why is this needed: In the internal environment, use a configuration file to install the cluster on different nodes . The configuration file describes the docker image to be imported after the cluster is successfully installed. For example

kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
name: test-cls
networking:
  podSubnet: "10.241.0.0/16"
  serviceSubnet: "10.109.0.0/16"
nodes:
- role: control-plane
  loadImages:
  - nicolaka/netshoot:latest
- role: worker
  loadImages:
  - postgres:10.23
  - nginx:latest

[aojea]

I don't know at what point we should be doing these kind of "after cluster creation" actions.

We already provide tooling to solve this problem easily

kind create cluster
kind load docker-image ...

[nioshield]

Thanks for your reply, I understand what you mean, but I have a lot of docker images to difference nodes, I need multiple command . such as:

kind load docker-image a b --nodes node1 node2
kind load docker-image c d --nodes node3 node4
kind load docker-image e f g --nodes node1 node3
....

Check whether these operations can be automatically performed after the cluster is created

[BenTheElder]

If you're doing a lot of images we recommend a local registry anyhow https://kind.sigs.k8s.io/docs/user/local-registry/

This functionality is readily scriptable with very simple logic without us extending the config file, so I don't think we should add this.

Also, kind load needs to be redesigned to better support sources like podman, and we should figure that out before adding more depending on it.

[christianh814]

Just +1ing the "This is easily scriptable" but with some caveats/wishlist

I use Kind as a library for my specific use case and I actually builtin the "loadImages" step in my tool

However, I did this by copying large parts of the existing logic...which has the limitation of assuming docker as the runtime and other messy things.

It would be nice if this was a method or part of the library I can call in my tool.

[BenTheElder]

[...] which has the limitation of assuming docker as the runtime and other messy things.

that sort of half-baked-ness is why:

It would be nice if this was a method or part of the library I can call in my tool.

that isn't the case yet.

there's a couple open threads discussing revamping the image loading, but nobody has fully fleshed that out yet, and most of the proposed PRs so far have made new bad assumptions like "all node providers will have image export and we'll just swap the existing command to use the node providers' implementation", which is both a breaking change and not very forward thinking (getting nodes running can be totally orthogonal from source images, which users may also want to do across providers e.g. if building kubernetes still requires docker+buildx but they prefer to run them with some other runtime).

IF we get this to a much more mature place, at that point we should look at what the importable API is as refined by the mature CLI usage.

When we started "kind load docker-image" it was a very simple bit of code to docker save and then pass that to the APIs that are already exported and reasonably robust to get those images into the nodes.