Option to install containerd separately (so images can be imported ahead of time)

[pfrydids]

Summary

I am trying to optimize a multipass launch . Being able to import images when building a custom machine image would mean that launching this image and then installing microk8s and configuring the resultant kubernetes instance would be much quicker.

Why is this important?

At the moment the packer machine image build pulls and saves container images and also downloads the microk8s snap.

This is image will be built infrequently.

The launch script for this image installs microk8s from the local snap file and then imports the local container images file. The importing of images is taking a lot of time (even using the --no-unpack flag).

Is it possible to move the importing of the images into the machine image build step i.e. installing containerd separately ?

Ideally I'd like to have a machine image with images already imported.

The machine image will be used for spinning up master and worker nodes in the cluster and therefore microk8s is installed as part of image launch. It would be better if I could install microk8s as part of the machine image build but that would result in a single node name being used and thus adding nodes would fail, or have a misunderstood something here?

Are you interested in contributing to this feature?

no

[ktsakalozos]

Hi @pfrydids, this is an interesting use-case. How would you import the images if containerd is installed separately?

Would it be possible that during the image build you would sideload [1] the image to the containerd of microk8s so that it is available next time you boot it?

[1] https://microk8s.io/docs/sideload

[pfrydids]

@ktsakalozos Side loading requires microk8s to have been installed. Installing microk8s as part of machine image build means that the node name has been chosen (by microk8s). A subsequent launch of that image results in a new node and the original node (created during machine image build) showing as unreachable. The presence of two nodes confuses microk8s (though it eventually reschedules pods to the new reachable node) and deleting the unreachable node though possible doesn't seem to expedite the rescheduling. The confusion manifests itself as an even longer boot time for pods on the cluster.

Though it possible to make the host name a static string and thus the node name chosen during image build the same as that chosen upon image launch it means that microk8s is being restricted to a single node as adding a node with the same name just doesn't work.

The command to import images into microk8s that I am using is

microk8s ctr image import --no-unpack $image

so the microk8s command is just a a thin wrapper around the containerd cli . If containerd were installed separately and if there was a microk8s install option to say 'use this external containerd' then the import could be moved into vm image build.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.