Introduction

When a Containerized Application is deployed to a Kubernetes cluster, the K8s control plane schedules the Pod to a worker node in the cluster. The Node agent (Kubelet) running in the worker node, co-ordinates with the container runtime (e.g. containerd) installed in the node, and pulls the necessary container images from the Image Registry. Depending upon the size of the image and the network bandwidth available, it takes time to pull all the images to the node. So, in any containerized application, we should be cognizant of the delay introduced due to fetching the images from the registry. Traditional applications that run as processes (e.g. managed by systemd), however, do not suffer from this delay because all necessary files are already installed in the machine.
Imagine your Containerized Application experiences a sudden surge in traffic, and it needs to immediately scale out horizontally (i.e. additional instances need to be created). If you had configured Horizontal Pod Autoscaler (HPA), K8s control plane creates additional replicas of Pods. However these Pods won’t be available for handling the increased traffic, until the required images are pulled and the containers are up and running. Or assume your Application needs to process high-speed real-time data. Such applications have stringent requirements on how rapidly they can be started-up and scaled, because of the very nature of the purpose it fulfils. In short, there are several use cases where the delay introduced due to pulling the images from the registry is not acceptable. Moreover, the network connectivity between the cluster and the image registry could suffer from poor bandwidth or the connectivity could be totally lost. There are scenarios, especially in Edge computing, where Applications have to gracefully tolerate intermittent network connectivity.

Use Cases

• Applications that require rapid start-up. For e.g. an application performing real-time data processing needs to scale rapidly due to a burst in data volume.
• Serverless Functions since they need to react immediately to incoming events.
• IoT applications that run on Edge devices, because the network connectivity between the edge device and image registry would be intermittent.
• If images need to be pulled from a private registry and everyone cannot be granted access to pull images from this registry, then the images can be made available on the nodes of the cluster.
• If a cluster administrator or operator needs to roll-out upgrades to an application and wants to verify before-hand if the new images can be pulled successfully.

reading
https://itnext.io/kube-fledged-cache-container-images-in-kubernetes-7880a00bab91