For my day job I am doing work within Kubernetes for a client.
I am doing my development (ha!) via a local k3s installation and running Rancher so I can easily follow things as I install and destroy things.
But getting my newly created docker image into k3s was problematic.
Since this image should not be hosted via any public registry, and it is no where near ready for a private registry, I needed to figure out how to get this done.
Rabbit holes and a ton of failures ensued.
Examples I found via searching all revolved around a 2 step process.
docker save path/image:tag > image-tag.tar ; k3s ctr images import image-tag.tar
There were variations on this theme but none of them worked. Every k3s ctr images ls was empty of my image. No errors, no output from commands though each command took time to operate. My tar image looked fine. What is going on?!
Digging myself out I decided to try something a little different. I mean this is a UNIX-like system so pipes are cool. So, time to test a theory
Since docker save sends output to standard out (stdout) then maybe k3s ctr images import supported reading on standard in (stdin).
So, I tried the following:
docker save path/image:tag | k3s ctr images import -
Followed by:
k3s ctr images ls | grep path/image
Walla! It worked! Still zero status output but I was able to see my image. It was named a little weird as it was docker.io/path/image:tag though it all ending up being exactly what I wanted: local docker image into k3s so I can test.
To use a local image as I described above, you would need to update your deployment as such:
... image: repository: path/image tag: tag imagePullPolicy: Never ...
The imagePullPolicy: Never will cause Kubernetes to use it’s local collection of images and not look for an image from a remote repository.
While this has been useful for this use case it is, of course, probably 100x easier to just use a registry whether it is via Docker, Artifactory, or any other registry service. A system like minikube has a local registry built in.
My (ha!) comment
While I work in the SecDevOps world I am not really a standard programmer of any kind though I can read and debug most things pretty well. It’s that whole writing application code that throws me into the land of headaches and frustration. Don’t let it fool you, though. I can do things, really, I just burn a lot of energy to do so.