Kubernetes is a powerful container management platform that enables organizations to manage and deploy applications and services in a secure, automated way. Kubernetes images are the foundation of Kubernetes, which allow users to create and deploy applications without having to worry about the underlying system. Kubernetes image pull policies allow users to restrict access to certain images or sets of images for specific users or groups of users. This can help protect against unauthorized access to your application or service. To create a Kubernetes image pull policy, you first need to create an imagePullPolicy object. This object contains information about how you want your image pull policy to work. You can use this object in your kubeconfig file or in a custom controller on your cluster. The following example shows how you could create an image pull policy that restricts access to the ubuntu-14.04-x86_64 image for all users except those who have been authenticated with the kubeconfig file authentication method: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185
Kubernetes image pull policies control when Kubelet should fetch an updated image version. Pull policies are used when a new Pod is starting up. Kubelet will take the appropriate action indicated by the Pod’s policy.
The Default Behaviour
You don’t have to specify an image pull policy. When a Pod lacks a policy, Kubernetes will infer your intentions from the image’s tag. If you’ve supplied a specific tag (such as my-image:my-release), the image will only be pulled if the tag doesn’t already exist on the Kubelet node. This policy is called IfNotPresent.
When no tag is specified, or you’re using the latest tag, the image will always be pulled. Kubernetes will fetch the image’s manifest every time a new Pod starts. If the manifest indicates a change, the updated image will be pulled before the containers are created.
Kubernetes will never modify imagePullPolicy as a consequence of another action. Editing a Pod’s image will not trigger Kubernetes to re-evaluate the default pull policy. That means that if you start with my-image:latest but later update the Pod to my-image:my-release, the image pull policy will still be IfNotPresent. You should manually specify a new policy if one is desired.
Making Kubelet Always Pull
You’ll need to apply an image pull policy to force Kubelet to always attempt a pull. Set imagePullPolicy: Always on a Pod to enable this behaviour.
New image versions will be pulled whenever a Pod starts and the image’s manifest digest has changed. A locally cached version of the image will still be reused if the digest hasn’t changed. This avoids unnecessary downloads over the network. Docker digests are immutable references that uniquely identify images without a name or tag.
Forced pulls are useful when you want to distribute new versions of your image using the same tag. This might be the case when you tag images using the branch name they’ve been built from. Without the Always policy, Kubernetes would never pull your new image releases if the tag was already available locally.
Banning Automatic Pulls
All the policies which permit image pulls will fetch new versions of your locally cached tags. Use an image digest as your Pod’s image field if you want a container to stick with an exact image version each time it starts.
There are scenarios where you might not want to Kubernetes to pull images at all. Setting the Never policy will prevent Kubelet’s automatic pulls. This policy won’t check for updates at all – the registry’s manifest version will not be fetched.
You’ll need an alternative way of getting images to your nodes if you use Never. Each image will need to exist locally before you try to start your Pods. Otherwise, Kubernetes won’t be able to run the Pod’s containers.
This acts as a protection mechanism when you’re using a standalone image pull mechanism. You won’t want Kubernetes to inadvertently attempt an automatic fetch in the event a pull fails. It could lead to the loss of images that are already locally cached.
Pull Policies and Caching
Your selected pull policy shouldn’t significantly impact performance. As long as your image provider supports layer caching, Kubelet will only need to pull the genuinely new layers in each image.
The Always policy does add a network call each time you start a new Pod. It only needs to check the image digest so this should be practically instantaneous. If the digest doesn’t match the locally cached version, then the new image layers will be pulled from the registry. The most significant performance overhead is the actual network transfer of those layers, followed by their subsequent decompression.
Summary
Kubernetes supports several behaviour models for image pulls. Images are handled by Kubelet and will be fetched whenever a Pod starts. The default policy will pull the image if the tag doesn’t already exist locally. If the image is untagged, or has latest as its tag, the Always policy will be used instead.
Setting the imagePullPolicy in your Pod specs makes the selected policy explicit. This helps all contributors to understand the chosen behaviour, even if they’re unfamiliar with the Kubernetes defaults. It’s particularly important if you’re using latest or untagged images, where Kubernetes applies special handling that could be confusing.
Remember that image pull policies are always set per-Pod by default. If you want to use one policy for your entire cluster, you’ll need to use a configuration validation tool to scan your Pod manifests. kube-score is a static analysis tool for Kubernetes object manifests that includes an imagePullPolicy check in its default ruleset. Run kube-score score my-manifest.yaml as part of a CI pipeline to prevent the use of manifests that lack a defined policy.
