Draft: Use a pipeline to load images into kind #9902
Conversation
This fixes the issue when kind runs in podman instead of docker See: kubernetes-sigs/kind#2038 Fix: GoogleContainerTools#9901
|
I may be mistaken, but care may want to be considered when dealing with large images (eg: 10GB+). On WSL2 at least, I recall a similar issue with a tool That ended up requiring sufficient RAM if the VM disk image was large enough that it was problematic (it also involved implicit tar archive/unarchive of the VHDX file IIRC), which caused the operation to fail depending on the system memory available. Meanwhile manually doing the commands individually without a pipe was successful as actual disk was usable. |
|
The implementation of |
Sorry? I don't see piping there, just support for it. Here I'm not that familiar with Go, so I may be mistaken but it looks like this PR is not writing the tar to disk, just piping the export into a reader. IIRC, if the operation doesn't block on the export itself completing and can instead maintain a smaller buffer during the operation to stream the export/import in smaller chunks, then memory overhead shouldn't balloon like I've observed with other tools like ContextImport/export separately (required if using docker save localhost/example -o example.tar
kind load image-archive example.tarWhat you proposed at kind load image-archive -n kind-cluster <(podman save "$TAG" --format oci-archive)That creates a temporary file descriptor, but I can't recall if that has that same implications that cmd /c "wsl --export ""$wsl_distro"" - | wsl --import wslcompact ""$tmp_folder"" -" Using an actual pipe operator I'm pretty sure that would run into the same piping issue, and so should the approach in Go then if the whole image is buffered into memory vs read from disk. |
|
Podman desktop is also writing the image to the disk first: https://github.com/podman-desktop/podman-desktop/blob/main/extensions/kind/src/image-handler.ts#L80. Maybe this is the saver approach, since two tools already are using this concept. Piping itself should not increase the memory usage, but I don't know, how this works, if you mix the systems where the image is coming from with the target system. E.g. if the image is loaded from docker (and therefore the docker wsl-vm) targeting a kind cluster running in podman (and therefore the podman wsl-vm) |
This fixes the issue when kind runs in podman instead of docker
See: kubernetes-sigs/kind#2038
Fixes: #9901
Description
Because
kind load docker-imagedoesn't work if kind is running with podman and the image to load is created with podman as well, the concept to load the image has to be changed. This problem is described in kubernetes-sigs/kind#2038. An "easy fix" for this is to save the image with the corresponding container engine as a docker-image to stdout and pass it tokind image-load /dev/stdin. By usinglocalDockerlike the builder does, podman can be selected by settingDOCKER_HOSTto a podman-socket.This implementation is more like a proof of concept than anything else. As everyone easily can see, I'm not a go-developer ;-)
This was tested as in "works on my machine". My machine at the moment:
systemctls--user podman.socketis enabled and startedDOCKER_HOST=unix:///var/run/user/$(id -u)/podman/podman.sockUser facing changes (remove if N/A)
If implemented correctly, nothing changes for docker users
Follow-up Work (remove if N/A)
Do a real implementation ;-)