An Image Pull Policy is a Kubernetes configuration rule that dictates precisely when the kubelet should download a specified container image from a registry. It governs the conditions under which a node fetches an image to ensure the correct version of a workload is running, balancing deployment speed against image freshness.
Glossary
Image Pull Policy

What is Image Pull Policy?
An Image Pull Policy is a configuration rule that dictates when the kubelet should download a container image from a registry.
The three standard policies are Always, IfNotPresent, and Never. Always forces the kubelet to pull the image on every pod start, guaranteeing the latest tag is used. IfNotPresent pulls only if the image is not cached locally, optimizing for speed. Never requires the image to exist locally, used in air-gapped or pre-seeded environments.
Core Policy Values
The imagePullPolicy field in a Kubernetes Pod specification is a critical control point for container runtime behavior, directly impacting deployment determinism, registry authentication, and node storage consumption. Understanding the three core values is essential for enforcing supply chain security in sovereign AI infrastructure.
IfNotPresent
The kubelet pulls the image only if it does not already exist locally on the node's filesystem.
- Mechanism: Checks the local container runtime image store by tag. If the tag is found, the local copy is used without contacting the registry.
- Use Case: The default policy for images with a specific tag (e.g.,
:v1.2.3). Essential for cost control and operational stability. - Sovereign AI Impact: Minimizes external bandwidth consumption. Ideal for air-gapped registries where images are pre-loaded; ensures nodes use the pre-seeded artifact.
- Caveat: If a tag is mutated upstream, the node will not detect the change, leading to potential configuration drift.
Never
The kubelet assumes the image exists locally and makes zero outbound network requests to any registry.
- Mechanism: The container runtime immediately attempts to start the container using only the local image store. If the image is absent, the container fails to start.
- Use Case: Enforces strict pre-staging requirements. Used in high-security disconnected environments where any external communication is forbidden.
- Sovereign AI Impact: The strongest enforcement of data residency and network isolation. Requires a mandatory sidecar process to pre-populate nodes with golden images via physical media or a one-way data diode.
- Failure Mode: Results in
ErrImageNeverPullif the image is not manually cached on the node.
Defaulting Logic
Kubernetes dynamically sets the pull policy based on the tag format when the field is omitted from the spec.
:latesttag: The kubelet defaults toAlways.- Specific tag or digest: The kubelet defaults to
IfNotPresent. - Sovereign Best Practice: Never rely on defaults. Explicitly declare the policy to avoid ambiguity. Always deploy using an image digest (SHA256) rather than a mutable tag to guarantee cryptographic identity, rendering the pull policy a secondary safety net.
Admission Control Enforcement
To prevent misconfiguration at scale, admission controllers can mutate or reject pods based on their pull policy.
- Mutation: A webhook can silently overwrite a
:latesttag with a specific digest and change the policy toIfNotPresent. - Validation: A policy agent (e.g., OPA/Gatekeeper) can reject any pod that specifies
Alwaysin a production namespace to prevent registry dependency. - Sovereign AI Integration: Combined with Binary Authorization, admission controllers ensure that only signed images with a
NeverorIfNotPresentpolicy are executed, closing the gap between policy declaration and runtime enforcement.
Interaction with Image Caching
The pull policy directly dictates the effectiveness of local registry mirrors and node-level caching.
IfNotPresent: Maximizes cache hits. The node acts as a persistent warm cache, reducing load on the central sovereign registry.Always: Bypasses the node cache but can still hit a local pull-through cache if the registry endpoint is configured as a mirror.- Disk Pressure:
Alwayscan lead to image accumulation. The kubelet's garbage collection thresholds trigger based on disk usage, potentially evicting unused images regardless of the pull policy, which can cause latency spikes ifIfNotPresentis expected.
Frequently Asked Questions
A deep dive into the Kubernetes Image Pull Policy, a critical configuration that dictates when the kubelet fetches container images from a registry. Understanding these policies is essential for deterministic deployments, bandwidth management, and security enforcement in sovereign AI infrastructure.
An Image Pull Policy is a Kubernetes configuration rule, set at the container level, that dictates when the kubelet should attempt to download a specified container image from a registry. It is a core mechanism for controlling deployment determinism and network egress. The kubelet evaluates the policy against the local image cache on the node. If the policy conditions are met, the kubelet authenticates to the registry (using configured imagePullSecrets), checks the remote manifest, and downloads any missing or updated filesystem layers. The three standard policies are:
Always: The kubelet queries the registry on every pod creation and downloads the latest image digest associated with the tag.IfNotPresent: The kubelet pulls the image only if it is not already cached locally on the node.Never: The kubelet assumes the image exists locally and never contacts a registry; the pod will fail if the image is missing.
Enabling Efficiency, Speed & Accuracy
Intelligent Analysis, Decision & Execution
We build AI systems for teams that need search across company data, workflow automation across tools, or AI features inside products and internal software.
Talk to Us
Search across company data
Give teams answers from docs, tickets, runbooks, and product data with sources and permissions.
Useful when people spend too long searching or get different answers from different systems.

Automate internal workflows
Use AI to route work, draft outputs, trigger actions, and keep approvals and logs in place.
Useful when repetitive work moves across multiple tools and teams.

Add AI to products and internal tools
Build assistants, guided actions, or decision support into the software your team or customers already use.
Useful when AI needs to be part of the product, not a separate tool.
Related Terms
Understanding image pull policy requires familiarity with the broader container image lifecycle, from build-time integrity to runtime enforcement.
Image Digest
A unique, content-addressable SHA256 hash that immutably identifies a specific container image manifest or layer. Unlike mutable tags, a digest guarantees cryptographic verification of integrity.
- Pinning deployments to a digest ensures the kubelet always pulls the exact same bytes
- Works with
IfNotPresentto avoid unnecessary registry calls while maintaining immutability - Example:
myapp@sha256:abc123...
Content Trust
A security mechanism using digital signatures to ensure only authorized, untampered container images are pulled and executed. Integrates directly with pull policy enforcement.
- Docker Content Trust uses Notary and The Update Framework (TUF)
- When enabled, the kubelet verifies signatures before honoring any pull policy
- Prevents supply chain attacks even if a registry is compromised
Image Pull Secret
A Kubernetes secret object containing registry credentials used by the kubelet to authenticate to a private container registry.
- Required when pulling from private registries regardless of pull policy setting
- Can be attached at the pod, service account, or namespace level
- Without valid credentials,
AlwaysandIfNotPresentpolicies will fail withImagePullBackOff
Admission Controller
A Kubernetes-native plugin that intercepts authenticated API requests and can mutate or validate objects before persistence. Critical for enforcing image pull policies at scale.
- Can mutate pod specs to enforce
imagePullPolicy: Alwaysfor specific namespaces - Validating admission controllers can reject pods using the
:latesttag - Integrates with Binary Authorization for deploy-time signature verification
Image Tagging Strategy
A systematic convention for assigning mutable or immutable tags to container images, directly influencing pull policy behavior.
- Semantic versioning (
v1.2.3): Works withIfNotPresentfor reproducible builds - Git commit SHA: Immutable tags ideal for
IfNotPresentwith digest verification :latesttag: RequiresimagePullPolicy: Alwaysto avoid stale cached images, but introduces non-determinism
Registry Mirror
A local, read-only replica of an upstream container registry serving as a pull-through cache. Reduces external bandwidth consumption and latency in air-gapped or bandwidth-constrained environments.
- Kubelet pull policies operate against the mirror transparently
IfNotPresenthits the local mirror first, drastically reducing pull latency- Essential for air-gapped deployments where
Alwayswould fail without a local source

About the author
Prasad Kumkar
CEO & MD, Inference Systems
Prasad Kumkar is the CEO & MD of Inference Systems and writes about AI systems architecture, LLM infrastructure, model serving, evaluation, and production deployment. Over 5+ years, he has worked across computer vision models, L5 autonomous vehicle systems, and LLM research, with a focus on taking complex AI ideas into real-world engineering systems.
His work and writing cover AI systems, large language models, AI agents, multimodal systems, autonomous systems, inference optimization, RAG, evaluation, and production AI engineering.
Partnered with leading AI, data, and software stack.
How We Work
Custom AI workflows for your Business
One-fit-all AI don't work for modern businesses. At Inferensys, we aim to understand your business & custom requirements; which we use to define most efficient agentic workflows, the data, and the tools for your business.
01
Review the use case
We understand the task, the users, and where AI can actually help.
Read more02
Pick the right approach
We define what needs search, automation, or product integration.
Read more03
Build the first useful version
We implement the part that proves the value first.
Read more04
Improve from there
We add the checks and visibility needed to keep it useful.
Read moreThe first call is a practical review of your use case and the right next step.
Talk to Us