Hello I am looking into doing an air gapped install of k3s containers coredns localpath provisioner etc but want to generate the containers tarball using custom containers Is it possible to generate our own tarball that ctr with import the containers of on boot up rather than one of the <https rancher com docs k3s latest en installation airgap prepare the images directory and k3s binary|releases as explained in the docs> Is there documentation on the expected format of the tarball It looks like there is a manifest and registries file a part of the released airgap images Do I need to create both a registry yaml file along with the tarball

Hello I am looking into doing an air gapped install of k3s c rancher-users #k3s

Title

tall-jewelry-68687

06/17/2022, 6:31 PM

Hello. I am looking into doing an air-gapped install of k3s containers (coredns, localpath provisioner, etc), but want to generate the containers tarball using custom containers. Is it possible to generate our own tarball that ctr with import the containers of on boot up rather than one of the releases as explained in the docs? Is there documentation on the expected format of the tarball? It looks like there is a manifest and registries file a part of the released airgap images. Do I need to create both a registry.yaml file along with the tarball?

creamy-pencil-82913

06/17/2022, 8:24 PM

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

tall-jewelry-68687

06/17/2022, 9:13 PM

Thats what i am looking for but when i try that the images seem to still be pulled from docker.io:

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

creamy-pencil-82913

06/17/2022, 9:14 PM

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

tall-jewelry-68687

06/17/2022, 9:17 PM

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

creamy-pencil-82913

06/17/2022, 9:18 PM

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)

tall-jewelry-68687

06/17/2022, 9:23 PM

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:

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!

3 Views

#k3s Join Slack