Voiceware: Containers · deep-dive

IfNotPresent Can Hide Image Changes During Testing

How pull policy interacts with mutable image tags and node caches.

Current. Current Voiceware engineering series based on reviewed Kubernetes, Helm, ArgoCD, container runtime, Celery, Redis, Nginx, audio/ESL and deployment repository evidence.

I want to go one layer deeper on how pull policy interacts with mutable image tags and node caches.

Mental model

source -> image build -> registry identity -> Helm value -> node runtime pull -> container start

What the repository proves

The first charts commonly used imagePullPolicy: IfNotPresent, which made image identity especially important during testing.

Failure scenarios

The main failure I am concerned with is: A node may keep an older cached image for a mutable tag, making two pods with the same manifest run different builds across time or nodes.

Trade-offs

At the core, the issue was this: A node may keep an older cached image for a mutable tag, making two pods with the same manifest run different builds across time or nodes. The useful lesson was simple: Pair pull policy with immutable image identity; do not use pull policy to compensate for weak release tagging.

What I check in practice

  • Do not pair mutable latest tags with assumptions about reproducibility.
  • Promote the same built artifact across environments.
  • Use an explicit registry/repository path.
  • Prefer immutable tags or digests for releases.
  • Verify the node can pull the artifact.

If I remember one thing from this deep dive, it is Pair pull policy with immutable image identity; do not use pull policy to compensate for weak release tagging. The tool is secondary. The contract between layers is what makes the system operable.

Quick navigationEsc