For my day job, I worked within Kubernetes for a client.
I am developing (ha!) via a local k3s installation and running Rancher to follow things as I install and destroy things quickly.
But getting my newly created docker image into k3s was problematic.
Since this image should not be hosted via any public registry and is nowhere 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 they needed to work. Every
k3s ctr images ls was empty of my image. Though each command took time to operate, there were no errors or output from the commands. My tar image looked fine. What is going on?!
Digging myself out, I decided to try something a little different. This is a UNIX-like system, so pipes are incredible. So, time to test a theory
docker save sends output to standard out (stdout), 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 -
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 ended 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 ...
imagePullPolicy: Never will cause Kubernetes to use its 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 probably 100x easier to use a registry 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 a standard programmer of any kind though I can read and debug most things pretty well. That whole writing application code throws me into the land of headaches and frustration. Don’t let it fool you, though. I can do things; I burn a lot of energy.