June 7, 2022
Set Kubernetes Image Pull Policies per Environment in CloudTruth
Written by: Michael Levan
When you deploy an application running inside a Kubernetes Pod, you’re deploying an application from a container image. That container image could be a Docker image or another tool, like Podman.
When you build the Kubernetes app and the container image is used, the container image gets pulled from a registry. However, you may not have to pull from a registry, which will save bandwidth costs and avoid rate limits. It can also speed up deployments depending on how large the container image is.
In this blog post, you’ll learn about how to set Kubernetes image pull policies in a Kubernetes Manifest using CloudTruth.
What is a Kubernetes Image Pull Policy?
Kubernetes Image pull policies look like the below code:
spec: containers: - name: nginxdeployment image: nginx:latest imagePullPolicy: IfNotPresent ports: - containerPort: 80
Line 5 is where is the
imagePullPolicy with a value of
IfNotPresent.There are three possible values for the
IfNotPresent will pull the container image if it doesn’t exist on the host/worker that’s deploying the Kubernetes application. If the image exists, for example, the
nginx:latest container image, Kubernetes won’t pull (download) the image.
Always means that no matter what, Kubernetes will go out to wherever the container registry is and pull the container image. Even if it’s already on the host/worker, Kubernetes will try to do a pull.
Never means that Kubernetes will never try to attempt to pull the container image, even if it doesn’t exist on the host/worker.
The default value for
Registry for Container Images
Dockerhub is arguably the most popular container image registry. It allows you to store any container image you want and then pull that container image via your Kubernetes Manifest to deploy your application. The problem is, Docker has now implemented rate limits outlined below:
- 100 image pulls for anonymous users
- 200 image pulls for authenticated users
- Unlimited image pulls for paid users
Although that might sound like a lot, it isn’t. In fact, many small and large organizations had to change their workflow because production-level deployments were failing due to the image pull rate. This is a problem for not only organizations, but end-users attempting to learn Docker and Kubernetes.
Because of that, it’s crucial to set image pull policies for your deployments. Think about it like this; if you have Dev, Staging, and Prod, that means you could only have about 33 container image pulls per 6-hour period. Many organizations do 33 deployments in 5-10 minutes in the Development environment alone.
How can you manage the policies for Dev, Staging, and Production? Instead of setting that policy per environment and having multiple Kubernetes Manifests, you can use CloudTruth.
Implementing Kubernetes Image Pull Policies with CloudTruth
Now that you understand why image pull policies are crucial to set in any environment, whether it’s your production or development environment, let’s learn how CloudTruth can solve the problem for you.
Taking a look at the example Kubernetes Manifest below, you can see on line 17 that a CloudTruth parameter is being used called
apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment spec: selector: matchLabels: app: nginxdeployment replicas: 2 template: metadata: labels: app: nginxdeployment spec: containers: - name: nginxdeployment image: nginx:latest imagePullPolicy: ports: - containerPort: 80
You can create a new parameter called
imagePollPolicy that you can use inside of your Kubernetes manifest
Then you can set the values for
imagePullPolicy based on the environment. For example, maybe you don’t want the Development stage taking up all of the pulls because your Dev teams deploy to Development several hundred times per day.
Once you push the Kubernetes Manifest to CloudTruth Templates, you’ll see that the value of
imagePullPolicy will change based on environment/stage. You don’t have to have multiple Kubernetes Manifests or a bunch of different environment variable files. Instead, you simply have one Kubernetes Manifest that contains any value you’d like per environment/stage.
If you’d like to dive deeper into CloudTruth and Kubernetes, check out one of the latest videos on templates for Kubernetes.