Kubernetes - Images

---

---

In Kubernetes, container images are the fundamental units for deploying applications. Each container within a Pod runs a specific image, which includes the application code and its dependencies.

Defining Container Images

When configuring a Pod, we specify the image to use for each container. The image name follows the same syntax as the Docker command does and we can pull images from public registries like Docker Hub or from private registries.

Here's an example Pod configuration:

apiVersion: v1
kind: Pod
metadata:
  name: tesing-for-image-pull 
  labels:
    app: image-test             
spec:
  containers:
    - name: neo4j-server         
      image: neo4j:5.14          
      imagePullPolicy: Always    
      command: ["echo", "SUCCESS"] 
      resources:                 
        requests:
          memory: "128Mi"
          cpu: "250m"
        limits:
          memory: "256Mi"
          cpu: "500m"
      ports:                     
        - containerPort: 7474    
  restartPolicy: Never           

Explanation of Configuration

• metadata.name – We've named this Pod tesing-for-image-pull to easily track its creation and logs.
• containers.name – The container is called neo4j-server, simulating a real service.
• image – We're using neo4j:5.14, which is a valid and stable version tag from Docker Hub.
• imagePullPolicy: Always – This ensures the image is freshly pulled every time, useful in CI/CD or development.
• Command – With this, when we create the container and if everything goes fine, it will display a message when we will access the container.
• resources – This specifies CPU and memory requests/limits to help the scheduler and avoid overuse.
• ports – Even though this test doesn't expose Neo4j, we demonstrate how to define ports (optional).
• restartPolicy: Never – Since we're using this as a test container, we don't want it to restart on completion.

Understanding imagePullPolicy

The imagePullPolicy field dictates when Kubernetes pulls the specified image:

• Always: Kubernetes pulls the image every time the Pod starts, ensuring the latest version is used.
• IfNotPresent: Kubernetes pulls the image only if it's not already present on the node.
• Never: Kubernetes never pulls the image; it must be present locally on the node.

By default, if we omit the imagePullPolicy:

• If the image tag is :latest or no tag is specified, Kubernetes sets imagePullPolicy to Always.
• If a specific tag is provided (e.g., nginx:1.21.6), Kubernetes sets imagePullPolicy to IfNotPresent.

It's important to note that relying on the :latest tag can lead to unpredictability, as the image it points to can change over time. For consistent deployments, we should specify exact image tags or digests.

Pulling Images and Creating Pods

Create and Verify the Pod

Apply the manifest:

$ kubectl apply -f neo4j-image-pod.yaml

Output

pod/tesing-for-image-pull created

Check the Pod's status:

$ kubectl get pod tesing-for-image-pull

Output

NAME                    READY   STATUS      RESTARTS   AGE
tesing-for-image-pull   0/1     Completed   0          2m23s

View the logs:

$ kubectl logs tesing-for-image-pull

Output

SUCCESS

Best Practices

• Specify Exact Image Versions: Avoid using the :latest tag in production. Instead, specify exact versions to ensure consistency across deployments.
• Use imagePullPolicy: Always for Critical Updates: For applications where it's crucial to always use the latest image (e.g., during development or for critical updates), set imagePullPolicy to Always. This ensures Kubernetes checks the registry for the latest image each time the Pod starts.
• Leverage Image Digests for Immutable Deployments: Using image digests (e.g., nginx@sha256:...) ensures that the exact image version is used, providing immutability and preventing unexpected changes.
• Monitor for Image Pull Errors: Be aware of statuses like ImagePullBackOff or ErrImagePull, which indicate issues with pulling the image. These can result from incorrect image names, missing images, or authentication problems with private registries.

Conclusion

Managing container images effectively is vital for reliable and secure Kubernetes deployments. By adhering to best practices—such as specifying exact image versions, understanding and setting appropriate imagePullPolicy values, and monitoring for image pull errors—we can ensure our applications run consistently and securely across our clusters.