Introduction

Forcing Kubernetes to use an updated image from a registry is mostly about rollout strategy, not about manually clearing node caches. If the image tag is reused, Kubernetes may keep running the old image unless a new pod is created and the pull policy allows a refresh. The clean solution is immutable image versioning plus an intentional rollout trigger.

Understand What Needs to Change

Kubernetes does not continuously poll registries for tag updates. A new image is normally picked up only when:

• a new pod is scheduled
• the kubelet decides to pull the image
• the pod spec points to the intended image reference

If none of those conditions change, the running container stays as it is.

Use Immutable Tags First

The strongest pattern is to publish a unique tag for each build.

1spec:
2  containers:
3    - name: app
4      image: my-registry/my-app:2026.03.07-abc123
5      imagePullPolicy: IfNotPresent

Then update the deployment:

kubectl set image deployment/my-app app=my-registry/my-app:2026.03.07-abc123

This creates a new rollout and removes ambiguity about which image version is expected.

Know the Role of imagePullPolicy

imagePullPolicy controls when the kubelet tries to pull an image.

• 'IfNotPresent pulls only if the image is not already cached'
• 'Always attempts a pull whenever a container starts'

Example:

1spec:
2  containers:
3    - name: app
4      image: my-registry/my-app:latest
5      imagePullPolicy: Always

If you insist on mutable tags such as latest, Always is required more often, but immutable tags are still the better design.

Force a New Rollout

If the image tag stayed the same and you need pods restarted, trigger a rollout restart.

kubectl rollout restart deployment/my-app

This recreates pods, which gives the kubelet a chance to pull again based on imagePullPolicy.

It does not solve underlying release hygiene, but it is useful operationally.

Verify What Was Actually Pulled

After rollout, inspect the running pod:

kubectl describe pod <pod-name>

Check:

• image name
• image pull policy
• image ID or digest if available

This tells you whether the new image was really fetched or whether the node reused a cached version.

Use Digests for Maximum Precision

For highest deployment certainty, deploy by digest instead of tag.

image: my-registry/my-app@sha256:abcd1234...

Digests are immutable by definition, so there is no confusion about tag reuse. This is the strongest answer when traceability and rollback accuracy matter.

Docker Side Refresh

Outside Kubernetes, local Docker can refresh by explicit pull:

docker pull my-registry/my-app:latest
docker run --pull=always my-registry/my-app:latest

That is relevant for local testing, but Kubernetes behavior is the main issue in most cluster questions.

CI and Deployment Pipeline Guidance

The reliable deployment flow is:

1. build image once
2. push unique tag and optionally digest
3. update manifest or Helm values to that tag
4. let Kubernetes roll out new pods

This is better than trying to force caches to behave around mutable tags after the fact.

Common Pitfalls

• Reusing latest and expecting Kubernetes to notice the registry update automatically.
• Setting IfNotPresent with mutable tags and assuming fresh images will appear.
• Restarting pods without checking the actual image reference and pull policy.
• Treating node cache cleanup as the primary deployment strategy.
• Not verifying the pulled image digest after rollout.

Summary

• Kubernetes refreshes images when new pods start and pull rules permit it.
• Immutable tags are the most reliable way to deploy updated images.
• 'imagePullPolicy: Always helps with mutable tags but is not the ideal long-term answer.'
• 'kubectl rollout restart can force pod recreation when needed.'
• Verify running image IDs or digests instead of assuming a tag change succeeded.