Support loading container images from a secondary disk attached to a kubernetes node

[ganeshkumarashok]

What is the version of your Accelerated Container Image

No response

What would you like to be added?

Have the option to load container images which are pre-loaded on a secondary disk that is attached to the node.

Overlaybd needs to:

1. use container images pre-loaded in the secondary disk (format and paths to be determined),
2. provide the same on-demand image loading capabilities, based on network availability.

Why is this needed for Accelerated Container Image?

1. Very large container images that need most data to be loaded at the start (particularly for deep learning workloads):
   Workloads like inference with large language models need most of the container image loaded to memory, before serving traffic. In these cases, having the ability to attach a secondary disk to the node can speed up the process. If there are updates to the container image, then we still need to be able to only download the difference in content needed, and in an on-demand manner.

2. Air-gapped nodes:
   If there are networking restrictions in downloading from a remote registry because of security reasons, for instance, then being able to use container images attached from a secondary disk will be useful.

Are you willing to submit PRs to contribute to this feature?

• Yes, I am willing to implement it.

[BigVan]

Thanks, It's a good idea! And I also have some suggestions,

1. We can keep an individual directory to save these pre-load image blobs. The path can be set in the configure file of snapshotter (/etc/overlaybd-snapshotter/config.json)
2. It is unnecessary to manage the capacity of pre-load image blobs. All the pre-load blobs should be saved to their own snapshots directory('snapshots/snID/overlaybd.commit' ) on image pulling. Snapshotter can create a hard link to the related blob when preparing the snapshot directory. After preparing has been done, we can remove the blob from the pre-load directory.
3. Overlaybd won't do any on-demand I/O for the pre-load layer since overlaybd treats it as a local-saved layer. Ensuring the completeness of the layer data and making its sha256sum meet the expectations.