Accelerates Kubernetes image pull

Accelerates Kubernetes image pull

When the Kubernetes pod starts, it will pull the image specified by the user. Once this process takes too long, the pod will be in the pending state for a long time, so that the service cannot be provided quickly.

The process of image pulling is shown in the following figure:

There are three kinds of imagePullPolicy image pull strategies for Pod:

• IfNotPresent : only pulls if the image doesn't exist locally.
• Always : kubelet will compare the digest of the image, if the local cache is already cached, the local cache will be used directly, otherwise it will be pulled from the image repository.
• Never : Only use the local mirror, if it does not exist, it will fail directly.

Note: The digest of each image must be unique, but the tag can be overwritten.

---

From the image pull process, we can speed up image pull from the following three aspects:

1. Reduce image size:
   Use smaller base images, remove useless dependencies, reduce image layers, use multi-stage builds, and more.
   Recommended to use docker-slim
2. Speed up network transfers between mirror repositories and k8s nodes.
3. Active cache mirroring:
   Pre-pulled pre-pulled images so that the local cache can be used directly in the future. For example, daemonset can be used to periodically synchronize the images in the warehouse to the local k8s node.

---

Digression 1: How long is the local image cache? Will it cause disk usage issues?

The locally cached image will definitely occupy the disk space of the node, that is to say, the more images cached, the larger the disk space occupied, and the cached image always exists by default, and there is no TTL mechanism (such as how long it will automatically expire and delete after ).

However, the GC mechanism of k8s will automatically clean up the mirror. When the disk usage of the node reaches the high percentage threshold of HighThresholdPercent (default 85%), garbage collection will be triggered. At this time, the kubelet will delete the oldest mirror that is no longer used according to the usage until the disk usage reaches LowThresholdPercent (default 80%) .

Digression 2: Is the number of mirror layers really less the better?

We often see some articles that use fewer RUN commands in the Dockerfile to reduce the number of layers of the image and then reduce the size of the image. It is true that the fewer the layers, the smaller the image, but in some scenarios, the gain outweighs the gain. First of all, if your RUN command is very large, once you modify a small part of it, the layer can only be restarted when it is built, and no cache can be used; secondly, the image layer is in the process of uploading and downloading. can be concurrent, and a single large layer cannot be concurrently transmitted.