In our latest Short Take video, RX-M instructor Valentin Hristev explores Kubernetes imagePullPolicy, describing how the Kubernetes kubelet interacts with the container runtime and demoing image pull policy behaviors using the policies: “Always“, “IfNotPresent“, and “Never“.
Video Transcript
Hello everyone and welcome back to another RX-M Cloud Native Short Take. My name is Valentin Hristev and today I’ll be talking about Kubernetes image pull policy. Let’s jump in! So here we have a Kubernetes cluster. Inside that cluster we have a control plane and a data plane. Inside the control plane are all the components needed to run Kubernetes. Inside the data plane are all the components needed for a service to run. Here we have a worker; inside the worker node we have the kubelet, and the kubelet is our captain of the ship.
From the Kubernetes point of view, when you create a pod the kubelet is going to instruct the container runtime to create a container inside that pod but before we can create the container we need to have an image. So the container runtime is going to query the registry and pull that image. For example this can be Docker Hub. After the image is pulled we’re going to create a container. So let’s go to our demo so that we can see how the image pulling works.
Here I prepare for you a single Kubernetes cluster–a single node. Here I prepare for you a pod. So as you can see the name of the pod is server. Here is the sleep command, this is the image: busybox:1.36.1 and now we’re going to put the imagePullPolicy. I’m going to use Always. There are three different image pull policies: Always is going to always pull the image and is checking the digest. Never is never going to pull the image so it needs to be cached on the worker node to use it, IfNotPresent is when it’s going to check the image is on the work node or not and it’s going to use it–if it’s not there it’s going to pull it. So let’s start with Always.
So here we have the pod. I’m going to apply that pod but before I hit the enter I will open another two sessions to this worker node; over here I’m going to use the journal so I can watch for the kubelet service logs and the containerd logs. Now I’m following the logs and as we discussed the kubelet is going to instruct containerd to pull the image. Let’s see what is going to happen when we create the pod. When I create the pod as you can see, we’re going to zoom in here to the containerd logs and search for pull. Here it is. So, from this message you can see that containerd is pulling that image which is busybox:1.36.1. All right, so now–oops, let me just follow the logs again. Now I’m going to copy this pod and I’m going to change the name to server-2. Zoom in and I’m going to change the name of the pod but I’m going to use the same image so we’re going to change the policy to IfNotPresent. I’m going to apply that and I’m going to watch what is going to happen. So, because we didn’t change the tag it is going to check if that the image is on the system and if it’s not on the system it is going to pull it. So let’s check if it’s on the system. As you can see we have an image which is 1.36.1. So let’s see what is going to happen when we apply the pod-2.yaml. Zoom in to the containerd logs and as you can see there are no logs indicating that it pulled that image. If we come over here we can see our server-2 pod is running. This is because it’s using the same image and the image is already on the node.
So let’s copy that pod-2.yaml to pod-3.yaml. The only thing I’m going to do is change the version of the image. Now this image is not on our worker node so let’s see what is going to happen. So I’m going to close the kubelet logs because they’re not so important for this demo. So over here I’m going to kubectl apply -f pod-3.yaml and over here I’m going to watch the logs. I need to change the name and apply it again. So here is the image pull. Now we can see that if the image is not on the worker node it’s going to pull it.
All right, for the last demo we will use Never. Let’s zoom in, change the name to server-4, use 1.35.0 and Never. So now I’m going to use sudo crictl images | grep busy to see what kind of images I have on my computer–on the worker node. We have 1.36.0 and 1.36.1. So those two images are on the computer and in the pod-4.yaml we are using 1.35.0. So let’s see what is going to happen when we try to create the pod with kubectl apply -f pod-4.yaml.
Now as you can see pod server-4 is in the situation with ErrIamageNeverPull If we get the events we can see that it failed to pull the image and the policy is to never pull it. As you can see the container image busybox 1.35.0 is not present with pool policy to never. So now what we can do here–as you can see it’s never going to be pulled–is to pull it ourselves. So I can grab the name of the image and I can say crictl pull and pull the image myself. So now I’m pulling the image; when I see the pods–very soon the container runtime is going to realize, “oh this image is right now on the computer let me create this pod”–and here it is! The pod is created after a couple of seconds because the image is on the worker node. This is how the imagePullPolicy works.
If you want to learn more you can jump on our website rx-m.com and you can check out our courses. We have more than 200 courses. You can use our Custom Course Builder; so inside the Course Builder you can build your own course. For example it can be one day to 5 days and you can say, oh the first day I want to learn more about Deployments, Application Configuration, Namespaces, and day two I want to jump on Microservices or Kafka or Helm. So you can basically build your own course.
Thank you for watching and see you next time!