Introduction

If you want to see which container images are stored on a specific AKS node, the first thing to understand is that Kubernetes does not expose a direct kubectl get images view of node-local image caches. You need access to the node's container runtime, and on modern AKS that runtime is usually containerd, not Docker.

Understand What You Are Actually Listing

There are two related but different questions:

• Which images are referenced by running pods in the cluster?
• Which image layers are physically cached on one node?

The Kubernetes API can answer the first question. The node runtime answers the second. If you really mean local images on one node, you need to inspect that node.

First, List Images Used by Pods

Before going to the node, check whether the Kubernetes API already gives you enough information.

kubectl get pods -A \
  -o jsonpath='{range .items[*]}{range .spec.containers[*]}{.image}{"\n"}{end}{end}' \
  | sort -u

That lists images declared by pods across the cluster. It does not prove the image is cached locally on a given node, but it often answers the operational question people actually have.

If you want the images for pods currently scheduled on one node:

1NODE_NAME=aks-nodepool1-12345678-vmss000001
2
3kubectl get pods -A \
4  --field-selector spec.nodeName=$NODE_NAME \
5  -o jsonpath='{range .items[*]}{range .spec.containers[*]}{.image}{"\n"}{end}{end}' \
6  | sort -u

On AKS, Prefer crictl or ctr

Modern AKS clusters typically use containerd. That means Docker commands such as docker images may not exist on the node or may not describe the runtime you care about. The most direct runtime tools are:

• crictl images for a CRI-compatible listing
• ctr -n k8s.io images list for the containerd-native listing

If you have node access, those commands show what is cached locally.

Use kubectl debug to Reach the Node

Direct SSH access is often restricted or disabled in managed clusters. A more Kubernetes-native approach is kubectl debug node.

1NODE_NAME=aks-nodepool1-12345678-vmss000001
2
3kubectl debug node/$NODE_NAME -it \
4  --image=mcr.microsoft.com/cbl-mariner/base/core:2.0

Inside the debug container, enter the host filesystem if needed and query the runtime:

chroot /host crictl images

Or:

chroot /host ctr -n k8s.io images list

That gives you the image list from the node itself rather than from the control plane.

Example Output Filtering

If the node has many images, filter or format the result.

chroot /host crictl images | grep myregistry.example.com

Or show only repository names:

chroot /host ctr -n k8s.io images list | awk 'NR > 1 {print $1}'

Use that when you are checking whether a private image pull actually reached the node.

When kubectl debug Is Not Available

If cluster policy blocks ephemeral debug containers, a privileged DaemonSet can be used for node inspection. This is more invasive, so it should be a controlled troubleshooting step. A simplified manifest looks like this:

1apiVersion: apps/v1
2kind: DaemonSet
3metadata:
4  name: image-inspector
5  namespace: kube-system
6spec:
7  selector:
8    matchLabels:
9      app: image-inspector
10  template:
11    metadata:
12      labels:
13        app: image-inspector
14    spec:
15      hostPID: true
16      hostNetwork: true
17      containers:
18        - name: inspector
19          image: mcr.microsoft.com/cbl-mariner/base/core:2.0
20          command: ["sleep", "3600"]
21          securityContext:
22            privileged: true
23          volumeMounts:
24            - name: host
25              mountPath: /host
26      volumes:
27        - name: host
28          hostPath:
29            path: /

Once the pod is on the target node, kubectl exec into it and run chroot /host crictl images.

Why the Node Image Cache Matters

This check is useful when:

• A private registry pull succeeds on some nodes but fails on others.
• You are debugging image pull latency.
• You want to confirm that pre-pulled images exist before a rollout.
• Disk pressure or image garbage collection is suspected.

It is less useful when you only need to know what workloads are configured to run.

Common Pitfalls

Using docker images on AKS without confirming the node runtime. Modern AKS usually uses containerd. The Docker CLI may not be installed, and even if it is, it may not reflect the images managed by the actual container runtime.

Assuming the Kubernetes API tracks the local cache of every node. The API tracks workload specs and pod status, not the full runtime cache state on individual nodes.

Debugging the whole cluster when the issue is node-specific. Check the affected node directly rather than listing images cluster-wide.

Leaving debug pods or privileged DaemonSets running after troubleshooting. These carry elevated privileges. Remove them as soon as you have the information you need.

Confusing images referenced by pods with images already present on disk. A pod spec can reference an image that has not been pulled yet. The two are different questions that require different tools to answer.

Summary

Kubernetes does not provide a direct API to list cached images on one node. On AKS, inspect the node runtime with crictl or ctr, usually through kubectl debug node. Use the Kubernetes API first if you only need images referenced by running pods. Modern AKS clusters typically use containerd, not Docker. Always clean up any temporary debug access after the investigation.