image pulling time and optimizations

[anakrish]

We observed the following based on our experiments:

• It takes about 15 seconds to 1 minutes to pull 1GB of image data into a kata-cc pod
• Multiple pull operations on the same node gets throttled by some registries (e.g dockerhub)

In a typical Kubernetes workflow, multiple pods that run on the same node would share images, improving pod startup time. This sharing is currently not possible with image-rs.

image-rs devel plan mentions:

Step3: Advanced features
Develop a snapshotter to support container image on demand pull/decrypt, for image layer caching or sharing, it is TBD depends on the security model.

 Define on demand pull/decrypt required manifest standard
 Snapshotter: support on demand pull
 Image layer sharing between containers (TBD)

1. Is the above devel plan still good?
2. Are there already efforts to write a snapshotter to cache image layers?
3. Are there other thoughts about optimizing image pull?

[arronwy]

Hi @anakrish , currently we are working on optimizing image pull with stream mode(async read) support, this will also reduce the memoy consumption during image pulling but it will require some API change in oci-distribution and ocicrypt-rs crate.

Next we may need support on demand pull. For image layer sharing support between pods, we may need save encrypted image layers in host, then we will support on demand decrypt in guest.

[anakrish]

For image-caching on host, were you thinking of

• Using a containerd remote snapshotter to pull and cache images on the host and have image-rs look up the cache
• Or have image-rs pull the image but cache it on the host

[c3d]

Here is a design proposal on how to do image caching on the host at the block level. https://docs.google.com/presentation/d/1ie4i6p17VEm5klQchjAVisMUQYFCO8rIQsT3GvGWHS4/edit#slide=id.g12878630eea_0_382

[anakrish]

@arronwy You mention

Next we may need support on demand pull. For image layer sharing support between pods, we may need save encrypted image layers in host, then we will support on demand decrypt in guest.

Can you describe how you are planning to approach on demand pull and layer sharing?