This message was deleted.
# k3s
a
This message was deleted.
c
you can drop as many tarballs as you want in that directory and they’ll be imported automatically on startup
they’re just
docker save
format
docker save image1 image2 -o myimages.tar
you can then use sztd/gzip/bzip2 to compress the resulting tarball and k3s will still be able to read it
t
Thats what i am looking for but when i try that the images seem to still be pulled from docker.io:
Copy code
kagold@nuc-ubuntu2:~$ sudo $(which k3s) ctr images list | awk '{print $1}'
REF
<http://docker.io/rancher/local-path-provisioner:v0.0.21|docker.io/rancher/local-path-provisioner:v0.0.21>
<http://docker.io/rancher/local-path-provisioner@sha256:1da612c913ce0b4ab82e20844baa9dce1f7065e39412d6a0bb4de99c413f21bf|docker.io/rancher/local-path-provisioner@sha256:1da612c913ce0b4ab82e20844baa9dce1f7065e39412d6a0bb4de99c413f21bf>
<http://docker.io/rancher/mirrored-coredns-coredns:1.9.1|docker.io/rancher/mirrored-coredns-coredns:1.9.1>
<http://docker.io/rancher/mirrored-coredns-coredns@sha256:35e38f3165a19cb18c65d83334c13d61db6b24905f45640aa8c2d2a6f55ebcb0|docker.io/rancher/mirrored-coredns-coredns@sha256:35e38f3165a19cb18c65d83334c13d61db6b24905f45640aa8c2d2a6f55ebcb0>
<http://docker.io/rancher/mirrored-pause:3.6|docker.io/rancher/mirrored-pause:3.6>
<http://docker.io/rancher/mirrored-pause@sha256:74c4244427b7312c5b901fe0f67cbc53683d06f4f24c6faee65d4182bf0fa893|docker.io/rancher/mirrored-pause@sha256:74c4244427b7312c5b901fe0f67cbc53683d06f4f24c6faee65d4182bf0fa893>
sha256:6270bb605e12e581514ada5fd5b3216f727db55dc87d5889c790e4c760683fee
sha256:99376d8f35e0abb6ff9d66b50a7c81df6e6dfdb649becc5df84a691a7b4beca4
sha256:fb9b574e03c344e1619ced3ef0700acb2ab8ef1d39973cabd90b8371a46148be
While the tar-ed containers have an image address of myacr.io/local-path-provisioner:v0.0.21 and myacr.io/coredns:1.9.1
c
if it comes from a different registry it’s not the same image
<http://myacr.io/local-path-provisioner:v0.0.21|myacr.io/local-path-provisioner:v0.0.21>
is not the same image as
<http://docker.io/local-path-provisioner:v0.0.21|docker.io/local-path-provisioner:v0.0.21>
- why were you expecting it to use your image from an entirely different registry?
for the core k3s images at least you can set --system-default-registry=
<http://myacr.io|myacr.io>
and it will try to use images from that registry, instead of
<http://docker.io|docker.io>
. That is just for the core k3s images though.
I think you’re confusing registry mirror endpoints in registries.yaml with airgap tarballs
t
core meaning probably includes
coredns
but not
local-path-provisioner
? And yes, my original question is whether there is a merging of those concepts ... can i have mirrors with the airgap tarballs
c
if you use a mirror. it is still pulling it over the network
The endpoint configuration just tells containerd to pull it from that host, instead of
<http://registry-1.docker.io|registry-1.docker.io>
. The image is still considered to be named
<http://docker.io/whatever|docker.io/whatever>
though, and would need to be named such in Pod specs and image tarballs.
tarballs just preload the image into the node, so that it doesn’t need to be pulled from the registry over the network (using whatever endpoints you’ve configured for that registry)
t
right i was manually doing this with
ctr
but i was wondering if it was possible to have an experience similar to a k8s kubeadm config:
Copy code
kind: ClusterConfiguration
apiVersion: <http://kubeadm.k8s.io/v1beta2|kubeadm.k8s.io/v1beta2>
imageRepository: <http://mycr.io|mycr.io>
Which it sounds like
--system-default-registry
helps with. Then the local path provisioner can by deployed separately. I can give this a try
I see what you are saying that even if using a different container registry the entire image path is expected to be identical. Thanks for the help here!