@spowelljr : Would avoid having to save + scp + load the image help anything, with your benchmarks ?

minikube image load image

crane pull image image.tar
minikube cp image.tar /tmp/image.tar
minikube ssh -- docker load -i /tmp/image.tar

vs

minikube image load image --pull

minikube ssh -- docker pull image

uld avoid having to save + scp + load the image help anything, with your benchmarks ?

minikube image load image

@afbjorklund would this be only useful for publicly available images ?

would this be only useful for publicly available images ?

You would have to run a registry somewhere, but it doesn't have to use docker hub or any other publicly available one.

The main difference is if you plan to do it more than once (e.g. for another cluster, later on). Then you might want to cache.

It's still a bit of a premature optimization, you might just deploy and let Kubernetes decide when it needs to pull things...

1. Just run, pull nothing, cache nothing -- this is the default
2. Just pull, don't cache on the host (artificial benchmark)
3. Full prepare, both pull and cache -- this is the default

If we want to optimize for startup time, then the best option would be to not load the entire image ahead-of-time.

Instead we should run a local registry, and optimize the required kubernetes images for chunk streaming:
https://github.com/containerd/stargz-snapshotter/blob/master/docs/ctr-remote.md#optimizing-an-image

ctr-remote image pull
ctr-remote image optimize
ctr-remote image push

That would allow the cluster to start up as quickly as posssible, and pull the rest of the image when it is needed.

https://github.com/containerd/stargz-snapshotter/blob/master/docs/overview.md

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: afbjorklund, medyagh

The full list of commands accepted by this bot can be found here.

The pull request process is described here