In a Kubernetes ecosystem, for a container to stay alive, it needs to run an image. These images are a snapshot of a system or application’s entire state saved up in a non-volatile file format. An image represents how an application and its dependencies are packaged in binary format. When administering a Kubernetes application, it is necessary to create one or more images and have them stored in a repository where they can be pulled when they need to be referred into a POD.
This article explores how Kubernetes images are managed and pulled, and the various applications of different image pull policies.
Container registry
A registry is an image repository for development, testing, and access control. With a container registry, software teams can perform security and vulnerability analysis on container images, improve functionality then deploy them to Kubernetes clusters. To use an image in a cluster, its name and registry are specified in the POD or Deployment configuration file. If a registry hostname is not provided, Kubernetes assumes the Default Docker Registry.
Different versions of the same image may be needed for different use cases. Tags are added to image names to identify various versions and help isolate the different usage environments. If a tag is not specified in the manifest file, Kubernetes will automatically use the image tagged latest.
Building a container from an image (example)
To pull an image from a container registry, the following two steps are required:
- Creating a Secret that contains the login credentials used to access the registry. PODs with this secret specified can pull images from the specified registry.
- The image is pulled from the cloud registry by specifying the image name and location in a POD Spec or Deployment YAML file.
For this demo, the article uses Google Cloud’s Container registry (GCR), but the procedure remains generally similar for other container registries. Let us explore the steps in detail.
Creating the secret
Quick Note: The article assumes that a GCR repository is set up and the cluster’s KUBECONFIG configuration file has been properly set up.
To create the Secrets file, one needs to create GCR credentials, and the process is outlined here. These keys can be downloaded in P12 or JSON format and could look similar to:
Kubernetes can use this JSON key to access the GCR repository when pulling application images. To enable this, we create a secret named darwin-secret. This is performed by running the command:
To enable Kubernetes to use this Secret for every new Pod, the secret is added to the default service account using imagePullSecrets as shown:
Pod configuration
Administrators may prefer to use the secret for one POD instead of an entire service account. In this case, the secret is specified in the pod spec file. The spec file will look something like this:
Image pull policy options
When creating the POD, one can specify the imagePullPolicy specification, which guides the Kubelet service on how to pull the specified image during an update. In the above example, it has been set to Always, which means Kubernetes should always pull the image from the registry when updating the container.
There are three image policy pull options for Kubernetes.
- If
imagePullPolicyis set toAlways, Kubernetes will always pull the image from the Repository. - With
IfNotPresent, Kubernetes will only pull the image when it does not already exist on the node. - While with
imagePullPolicyset toNever, Kubernetes will never pull the image.
In case the specification is not stated on the manifest file, Kubernetes will set the policy depending on the image’s tag. If the image is tagged latest, then Kubernetes will assume the imagePullPolicy to be Always. An image with no tag is assumed to be latest, and so its policy is set to Always. Otherwise, the orchestrator will default the imagePullPolicy to IfNotPresent.
Closing thoughts
This article has been a high-level guide for image management in Kubernetes. Some concepts studied include container registry and deploying a Docker container using images from a repository. The article also covers Image Pull Policies in-depth, including the various options available. The Kubernetes Image Pull Policy is crucial for running both public images hosted on Docker, Private Repositories, and clusters running on legacy images.
If you’re looking for an even easier way to run your Docker-image-based tasks, you can use Airplane. With Airplane, you can build and run any custom image and run Docker commands against that image. This allows you to take all your existing Docker images and deploy them onto Airplane’s secure, serverless platform so your team can get back to what they do best: building tools.
To run your Docker-image-based tasks easily, sign up for a free Airplane account or book a demo.
