-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve k3s airgap boot time for large number/size of images #9242
Comments
My recommendation for this in the past has been as follows:
The above is probably what I'll recommend when the distributed registry mirror from #8977 is available. The best option when using a VERY large set of images is still to use a real registry. |
I'm not convinced that K3s itself needs to have native support for staged and/or parallel import, given the options described above. Can you make a case for why this needs to be built in to k3s, given that the user has other options and can customize the import logic for their specific needs once containerd has been started? |
My only arguments would be ease of use for the operator. Also, I am not sure that ctr supports importing |
Something like this should work, assuming you have the
|
I think I will close this as unplanned at the moment, given the above workaround. but we can reevaluate in the future. |
Is your feature request related to a problem? Please describe.
K3s loads images from the
agent/images
folder synchronously. As documented in rancher/rke2#773, it can be very slow to reboot/start k3s to get a functional control plane and data plane. The image load blocks until all img "sources" are loadedDescribe the solution you'd like
Provide a way to order the loading of system images(k3s, user provided) followed by other app images. Unblock k3s start and let all other images load in the background with a configurable number of goroutines. While this will not solve the problem when a giant image bundle is used but would help in cases where the bundle can be split and the chunks are loaded in a user-defined order with lazy-loading support. A simpler implementation that allows specifying the parallelization and an order based on file names would suffice to begin with.
Describe alternatives you've considered
Additional context
We are loading a 30GB zst compressed image bundle at k3s boot. The start takes >10mins. Splitting into multiple smaller bundles is not very helpful as the loading is not concurrent.
The text was updated successfully, but these errors were encountered: