6.2 Container Image Anatomy: Layers, Tags, Digests & Pull Policy

Kubernetes and Cloud Native Associate KCNA

Track your progress as you read

Finished sections get a check mark.

1 Chapter 1: Introduction & Exam Overview

1.1 About the KCNA Exam & Certification Path 1.2 How to Use This Study Guide

2 Chapter 2: Kubernetes Fundamentals - Cluster Architecture & the API

2.1 Kubernetes Architecture & Control Plane Components 2.2 Worker Node Architecture & Node Components 2.3 Kubernetes API, Declarative Management & kubectl 2.4 Kubernetes Releases, API Versioning & Deprecation Policy

3 Chapter 3: Kubernetes Fundamentals - Workloads & Configuration

3.1 Core Workload Objects (Pods, Deployments & ReplicaSets) 3.2 Advanced Controllers (StatefulSets, DaemonSets, Jobs & CronJobs) 3.3 Namespaces, Labels, Selectors & Annotations 3.4 ConfigMaps, Secrets & Application Configuration 3.5 Pod & Container Lifecycle, Restart Policies & Graceful Termination

4 Chapter 4: Kubernetes Fundamentals - Scheduling & Autoscaling

4.1 Scheduling, Resource Management & Node Selection 4.2 Advanced Scheduling: Affinity, Topology Spread, Priority & Disruption Budgets 4.3 Autoscaling Workloads & Clusters (HPA, VPA, Cluster Autoscaler, KEDA)

5 Chapter 5: Kubernetes Fundamentals - Cluster Administration & Extensibility

5.1 Kubernetes Distributions, Installation Tools & Managed Services 5.2 Cluster Administration: Node Maintenance, Upgrades & etcd Backup 5.3 Extending Kubernetes: CRDs, Operators & the Controller Pattern

6 Chapter 6: Kubernetes Fundamentals - Containerization

6.1 Container Fundamentals, Runtimes & Registries 6.2 Container Image Anatomy: Layers, Tags, Digests & Pull Policy

7 Chapter 7: Container Orchestration - Networking & Service Discovery

7.1 Kubernetes Networking, Services & Ingress 7.2 Cluster DNS & Service Discovery with CoreDNS 7.3 NetworkPolicies, Zero-Trust Segmentation & the Gateway API

8 Chapter 8: Container Orchestration - Storage

8.1 Storage Concepts (PVs, PVCs, StorageClasses & CSI) 8.2 Volume Types, Snapshots & Stateful Storage Operations

9 Chapter 9: Container Orchestration - Security

9.1 Kubernetes Security & Access Control (RBAC & ServiceAccounts) 9.2 The 4C's of Cloud Native Security & Supply-Chain Trust 9.3 Service Mesh, mTLS & Zero-Trust Service Identity

10 Chapter 10: Container Orchestration - Troubleshooting

10.1 Container Troubleshooting & Health Probes 10.2 Cluster & Node-Level Troubleshooting

11 Chapter 11: Cloud Native Application Delivery

11.1 Cloud Native CI/CD Pipelines & Build Tooling 11.2 GitOps & Package Management (Helm, Kustomize, Argo CD & Flux) 11.3 Deployment Strategies & Release Management 11.4 Progressive Delivery Automation: Argo Rollouts, Flagger & Feature Flags 11.5 Application Debugging & Developer Workflows in Kubernetes 11.6 Platform Engineering & Developer Self-Service

12 Chapter 12: Cloud Native Architecture - Observability & Principles

12.1 Cloud Native Observability (Logging, Metrics & Tracing) 12.2 Cloud Native Principles & Architecture Patterns 12.3 Serverless, FaaS & Event-Driven Architecture

13 Chapter 13: Cloud Native Architecture - CNCF Ecosystem & Community

13.1 The CNCF Landscape, Governance & Project Lifecycle 13.2 Cloud Native Community, Collaboration & Contribution

6.2 Container Image Anatomy: Layers, Tags, Digests & Pull Policy

Key Takeaways Explain This Topic AI

A container image is an ordered stack of read-only filesystem layers plus a JSON configuration, described by a manifest and addressed by a content digest.

Tags are mutable pointers that can be moved to a different image at any time, whereas a sha256 digest immutably identifies exact content.

imagePullPolicy accepts IfNotPresent, Always, and Never; it defaults to Always when the tag is latest or absent and to IfNotPresent otherwise.

Private registries are accessed using an imagePullSecrets reference to a Secret of type kubernetes.io/dockerconfigjson.

A multi-architecture image is published as an index that maps each platform, such as linux/amd64 and linux/arm64, to a separate manifest.

Last updated: August 2026

6.2 Container Image Anatomy: Layers, Tags, Digests & Pull Policy

Quick Answer: A container image is a stack of read-only filesystem layers plus a JSON config describing entrypoint, environment, and user, tied together by a manifest and addressed by a sha256 digest . A tag ( nginx:1.27 ) is a mutable human label that can be repointed at any moment; a digest ( nginx@sha256:abc… ) is immutable. imagePullPolicy decides when the kubelet re-fetches an image, and imagePullSecrets supplies credentials for private registries.

Section 6.1 covered what a container is and which runtimes execute it. This section covers the artifact itself — the part that moves through your pipeline, sits in a registry, and gets pulled onto a node.

1. Layers and the Union Filesystem

An image is built one instruction at a time, and each filesystem-modifying instruction produces a layer — a tarball of the changes relative to the layer beneath it. ┌──────────────────────────────────────────┐ ← container writable layer (ephemeral)

• ├──────────────────────────────────────────┤
• │ L4 COPY app.jar /opt/app.jar 12 MB │ ← changes most often
• ├──────────────────────────────────────────┤
• │ L3 RUN pip install -r req.txt 88 MB │
• ├──────────────────────────────────────────┤
• │ L2 RUN apt-get install -y curl 9 MB │
• ├──────────────────────────────────────────┤
• │ L1 FROM debian:12-slim 74 MB │ ← changes rarely
• └──────────────────────────────────────────┘

The runtime presents these to the process as one merged filesystem using a union filesystem (usually overlayfs ). Three consequences follow directly, and all three are testable:

Layers are shared. Ten images built FROM debian:12-slim store that 74 MB layer once on the node. Pulling the tenth image downloads only its unique layers.

The container's writable layer is ephemeral. Anything written inside a running container that is not on a mounted volume dies with the container. This is the mechanical reason containers are called stateless.

Deleted files are not removed, only hidden. If layer 3 adds a private key and layer 4 deletes it, the key is still present in layer 3 and recoverable from the image. You cannot delete a secret out of an image by adding a later RUN rm — the only fix is not to add it, or to use a multi-stage build.

Ordering for Cache Hits

Because a changed layer invalidates every layer above it, dependency installation goes before source copy. Copying package.json / go.mod and installing dependencies first means a code-only change rebuilds one small layer instead of re-downloading the world.

• 2. Manifests, Digests, and the Image Reference
• A full image reference has four parts: registry.example.com / platform / api : 2.4.1
• └── registry host ──┘ └ repository ─┘ └ tag ┘

• registry.example.com/platform/api@sha256:9f2c…e41b
• └───── digest ─────┘

When no registry is given, clients default to Docker Hub ; when no tag is given they default to latest . Neither default is a good idea in a manifest.

Reference kind Mutable? Meaning

Tag api:2.4.1 Yes A named pointer. Anyone with push rights can move 2.4.1 to different content tomorrow.

Digest api@sha256:9f2c… No The content-addressable hash of the manifest. Different bytes ⇒ different digest, always.

Why latest is dangerous. latest is not a magic "newest" keyword — it is just the default tag string. Two nodes pulling myapp:latest an hour apart can legitimately run different code, and you have no record of which. Production manifests should pin an immutable version tag, and high-assurance pipelines pin the digest , which is also what makes image signing meaningful.

Multi-Architecture Images

A single tag can resolve to an image index (a manifest list) mapping platforms to distinct manifests: myapp:2.4.1 ──► index

• ├── linux/amd64 → sha256:aaa…
• ├── linux/arm64 → sha256:bbb…
• └── linux/s390x → sha256:ccc…

The node's container runtime selects the entry matching its own architecture. This is how one tag works across x86 servers, ARM edge devices, and Apple Silicon laptops — and why an image built only for amd64 fails on an ARM node with an exec format error .

• 3. How Kubernetes Pulls Images
• imagePullPolicy

Value Behaviour

IfNotPresent Pull only when the image is absent from the node's local store. Fast; the sensible production default with pinned tags.

Always Contact the registry on every Pod start to check the digest behind the tag. Correct when a mutable tag must be re-resolved; costs a registry round trip.

Never Never pull. The image must already be on the node — used in air-gapped clusters and by kind / minikube workflows that side-load images.

The default is conditional , and this is a classic exam item: if imagePullPolicy is omitted, Kubernetes uses Always when the tag is latest or no tag is given , and IfNotPresent for every other tag. The behaviour tries to protect you from stale latest images.

imagePullSecrets

Public images need no credentials. Private registries need a Secret of type kubernetes.io/dockerconfigjson , referenced from the Pod (or, better, attached to the ServiceAccount so every Pod using it inherits the credential): kubectl create secret docker-registry regcred \

--docker-server=registry.example.com \

--docker-username=ci-bot --docker-password="$TOKEN" spec:

imagePullSecrets:

- name: regcred

containers:

• name: api
• image: registry.example.com/platform/api:2.4.1
• imagePullPolicy: IfNotPresent

A missing or wrong imagePullSecrets produces ImagePullBackOff with an unauthorized or manifest unknown event — indistinguishable at a glance from a typo in the image name, which is why kubectl describe pod is always the next step.

4. Registry Operations

Concern Practice

Promotion Copy the same digest between dev , staging , and prod repositories. Never rebuild per environment — a rebuild is a different artifact.

Retention Garbage-collect untagged manifests on a schedule; layer storage grows relentlessly otherwise.

Scanning Scan on push and re-scan periodically — a clean image becomes vulnerable when a new CVE is disclosed against a package it already contains.

Signing Sign the digest with Cosign/Sigstore and verify at admission, so the cluster refuses unsigned images.

Caching Run a pull-through mirror to survive upstream registry outages and rate limits.

Air-gap Export images to a tarball, import into an internal registry, and rewrite references.

The OCI Distribution Specification standardises the registry HTTP API, which is why a Harbor, an ECR, and a Docker Hub all speak the same protocol to the same clients — and why registries can now store non-image OCI artifacts such as Helm charts and SBOMs alongside images.