Kubernetes "pull QPS exceeded" / "context canceled" Image Pull - Fix in CI
By Daniel Zoghalchali·Latchkey
The kubelet aborted an in-progress image pull because it stopped making progress within its deadline (or the operation was canceled). On a large image over a congested link this is transient - the kubelet retries and the pull usually completes on a later attempt.
What this error means
Pod events show a pull that started then aborted with context canceled or a pull that makes no progress and is retried, before the image finally lands. It is intermittent - a re-pull (or simply waiting for the kubelet retry) succeeds.
A multi-gigabyte image pulled over a congested node network stalls long enough to trip the kubelet’s pull progress deadline, aborting that attempt.
Transient registry/network interruption
A momentary connection drop or registry slowdown cancels the in-flight pull; the next attempt usually proceeds normally.
How to fix it
Let the kubelet retry, and confirm progress
These aborts are transient. The kubelet retries pulls automatically; watch the events to confirm it ultimately succeeds.
Terminal
kubectl get events --field-selector involvedObject.name=<pod> --watch
Reduce pull time so it does not stall
Shrink images (multi-stage builds, slimmer bases) so pulls finish well within the deadline.
Pre-pull hot images (DaemonSet) or pin digests so cached layers are reused across nodes.
Serve images from a closer/internal registry or pull-through cache to cut transfer time.
How to prevent it
Keep images small so pulls complete quickly and reliably.
Use a nearby registry/mirror and pin digests for layer reuse.
Pre-pull large base images onto nodes to avoid per-pod transfer stalls.
Frequently asked questions
What causes "image pull "context canceled""?
A multi-gigabyte image pulled over a congested node network stalls long enough to trip the kubelet’s pull progress deadline, aborting that attempt.
How do I fix image pull "context canceled"?
These aborts are transient. The kubelet retries pulls automatically; watch the events to confirm it ultimately succeeds.
Can Latchkey fix this automatically?
Yes. Latchkey runs your GitHub Actions on managed runners that detect this failure, apply the fix, and retry the job automatically - self-healing is on by default.