kubernetes imagePullPolicy:Always is not pulling image automatically

Viewed 3476

I want that every time I create a new image with the tag latest Kubernetes automatically pull the new image. I added imagePullPolicy: Always in pod spec but it doesn't update the old image with new image.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: node
  namespace: dev
  labels:
    app: my-node-app
spec:
  replicas: 2
  selector:
    matchLabels:
      app: my-node-app
  template:
    metadata:
      labels:
        app: my-node-app
    spec:
      hostNetwork: true
      securityContext:
        fsGroup: 1000
      containers:
      - name: node
        imagePullPolicy: Always
        image: gcr.io/my-repo/my-node-app:latest
        ports:
        - containerPort: 3000
        envFrom:
          - configMapRef:
              name: my-configmap
        resources:
          requests:
            cpu: 100m
            memory: 128Mi
          limits:
            cpu: 2
            memory: 8Gi
      restartPolicy: Always
3 Answers

imagePullPolicy is only taken into account by Kubernetes when a POD is created or re-started. It is NOT taken into account while a POD is running, which means it does NOT check for image updates at any time while a POD is running.

Even if another POD with the same image would be scheduled onto the same Kubernetes node, the already running POD is not affected, even though Kubernetes does a pull and then uses the new image for the new POD.

If you want the desired functionality, you will have to implement your own solution. You could do this by implementing a sidecar that regularly checks the Docker Repository for changes to the given tag. When it detects such a change, it could trigger a restart of the POD, which would then force the image to be re-pulled.

A restart of the POD can either be triggered by simply exiting the sidecar or by utilizing the Kubernetes API inside the sidecar. The latter solution however gets more complicated as you will also need service accounts and RBAC rules to get proper permissions inside the sidecar container. It also has security implications you'd have to give the whole POD escalated permissions.

Setting imagePullPolicy: Always does not mean an image will be pulled automatically without any trigger.

I would recommend to use tagged image with semvar. Since you are using deployment you can perform rolling update of the pod which will pull new image and rollout the change across all the replica pod one by one in a graceful way without causing any downtime.

Let's say initially the image is gcr.io/my-repo/my-node-app:v1 and you want to update it to v2

kubectl set image deployment/node nginx=gcr.io/my-repo/my-node-app:v2 --record

Check the rollout history

kubectl rollout history deployment.v1.apps/node

In case of any issue rollback to previous version

kubectl rollout undo deployment.v1.apps/node

Also if you want to be more advanced you could do GitOps using FluxCD which supports triggering a rollout automatically whenever a new version of an image is pushed to a container registry.

Kubernetes will pull image only upon Pod creation which means it does not check for image updates while a POD is in running state. I would recommend to use Semantic Versioning for the image tag and use a CI/CD pipeline which build, tag, and push to your registry. Then use a CD tool such as keel to re-create your pods in the last step of the pipeline.

Related