Inferensys

Glossary

Image Pull Policy

A Kubernetes configuration rule that dictates when the kubelet should pull a specified container image from a registry, such as Always, IfNotPresent, or Never.
Governance lead reviewing model governance framework on laptop, policy documents visible, executive office setup.
KUBERNETES CONFIGURATION

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.

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.

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.

Image Pull Policy

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.

02

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.
03

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 ErrImageNeverPull if the image is not manually cached on the node.
04

Defaulting Logic

Kubernetes dynamically sets the pull policy based on the tag format when the field is omitted from the spec.

  • :latest tag: The kubelet defaults to Always.
  • 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.
05

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 :latest tag with a specific digest and change the policy to IfNotPresent.
  • Validation: A policy agent (e.g., OPA/Gatekeeper) can reject any pod that specifies Always in a production namespace to prevent registry dependency.
  • Sovereign AI Integration: Combined with Binary Authorization, admission controllers ensure that only signed images with a Never or IfNotPresent policy are executed, closing the gap between policy declaration and runtime enforcement.
06

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: Always can 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 if IfNotPresent is expected.
IMAGE PULL POLICY

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.
Prasad Kumkar

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.