The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →If Cilium pods are stuck in ErrImagePull or ImagePullBackOff, use the pod’s Events to identify what prevented the image from downloading before changing the DaemonSet. If no pod was created or it is Pending, investigate scheduling first: that is a different failure layer. The observations below will identify the relevant branch; without the pod events, cluster configuration and node details, the specific cause in Lab 3.1 cannot be determined.
First determine whether Cilium was scheduled
Check the DaemonSet’s desired, current and ready counts, then inspect its pods and node assignments:
As an Amazon Associate I earn from qualifying purchases.
kubectl -n kube-system get ds cilium
kubectl -n kube-system get pods -l k8s-app=cilium -o wideThe DaemonSet counts show whether Cilium has created and readied its expected instances. The pod listing shows which nodes have a pod and whether it is Pending, pulling an image, running or restarting. Cilium’s troubleshooting guide recommends listing the pods, sorting by restart count and examining logs for pods that are restarting: Cilium Kubernetes troubleshooting.
- No pod on a node, or a pod is Pending: check scheduling; an image pull cannot explain a pod that has not been assigned to a node.
ErrImagePullorImagePullBackOff: the kubelet tried and failed to retrieve an image. Use Events to find why.- The pod starts and then enters
CrashLoopBackOff: image retrieval succeeded far enough for the container to start. Check its logs and Cilium’s runtime prerequisites.
Read the pod Events before changing configuration
Describe the affected pod and record the exact image reference and event message:
#1 Best Overall
kubectl -n kube-system describe pod <cilium-pod>Kubernetes defines ImagePullBackOff as a container that could not start because Kubernetes could not pull its image. Invalid image references and missing credentials for a private registry are among the documented causes. Kubernetes increases the retry delay up to a maximum of 300 seconds (five minutes), so repeated attempts can appear spaced apart: Kubernetes: Images.
Events such as Failed to pull image, pull access denied, manifest unknown, a DNS timeout or a certificate error point toward different fixes. Google’s troubleshooting guidance groups common image-pull causes into authentication, network connectivity, missing images or tags, performance, CPU architecture and schema compatibility: Google Kubernetes Engine: Troubleshoot image pulls.
Match the event to the failing layer
- Access denied or authentication failure: verify that the node or pod has valid credentials for the registry and that the relevant
imagePullSecretsare present and usable. - Repository, tag or digest not found: compare the event’s full image reference with the intended registry, repository and release. Confirm that the referenced tag or digest exists.
- DNS, timeout or certificate errors: check registry name resolution, node egress and the registry’s TLS certificate trust from the affected node.
- Architecture or schema incompatibility: check the node’s CPU architecture and whether the published image manifest and format support the node’s container runtime.
- Slow or stalled retrieval: check node disk capacity, registry responsiveness and network performance before changing the image declaration.
Once the failure is clear, correct the smallest relevant input, then watch the pod’s Events and status to confirm that the next pull succeeds.
Recommended Free Tools
Check pull policy only when it fits the evidence
Kubernetes sets imagePullPolicy when an object is first created and does not automatically revise it if the image tag or digest changes later. A non-latest tag defaults to IfNotPresent; :latest defaults to Always; and an image specified by digest defaults to IfNotPresent. See Kubernetes image pull policy documentation.
Do not change the policy as a generic response to a failed pull: it will not correct bad credentials, an invalid reference, unreachable registry or incompatible image. Treat a policy change as a deliberate configuration choice. For reproducible deployments, an immutable digest avoids the ambiguity of a mutable tag.
If Cilium has no pod or it remains Pending
Inspect node readiness, DaemonSet selectors and placement rules before investigating the registry. A Cilium pod can be excluded by node selectors or affinity, blocked by a node taint without a matching toleration, or unable to fit because of resource requests. Use these commands to examine node labels and conditions:
kubectl get nodes --show-labels
kubectl describe node <node>Also inspect the DaemonSet’s tolerations, affinity, selectors and resource requests. If the Kubernetes API server is outside the cluster, Cilium documents that it must also run on master/control-plane nodes so API-server pod proxies can route to pod IPs. Depending on the cluster, that may require tolerations or static-pod placement: Cilium Kubernetes troubleshooting.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Scan for outdated or missing drivers - takes under a minute3Clear out junk files and repair common Windows errorsIf the container starts and then crashes
Read the container logs rather than repeatedly deleting the pod:
kubectl -n kube-system logs <cilium-pod> --all-containersCilium’s troubleshooting documentation shows a failure with CRIT kernel version: NOT OK and attributes it to a worker node running a kernel below the supported minimum. Compare the affected node’s kernel with the requirements for the Cilium release in use: Cilium Kubernetes troubleshooting.
For Cilium 1.20.2, the generic Helm installation instructions require a Kubernetes CNI and Linux kernel version 5.10 or later. The documented Helm command is:
helm install cilium cilium/cilium --version 1.20.2 --namespace kube-systemUse that version-specific prerequisite only if the cluster is installing Cilium 1.20.2; requirements and installation instructions can differ by release. The Cilium installation guide also documents the equivalent OCI chart option: Cilium Helm installation.
Free tools Windows power users keep installed
One-click scans. No signup required.
Confirm recovery and collect useful evidence
After applying the targeted correction, verify that the DaemonSet has all desired instances ready:
kubectl -n kube-system get ds cilium
kubectl -n kube-system get pods -l k8s-app=cilium -o wideThen check Cilium’s health using the method appropriate to the installation, such as cilium status or:
kubectl -n kube-system exec ds/cilium -- cilium-dbg statusIf the cause remains unclear, preserve the pod Events, exact image reference, node name and architecture, Cilium version, and relevant logs. Cilium documents a system-dump workflow, and Kubernetes provides general guidance for debugging pods: Cilium troubleshooting and system dumps and Kubernetes: Debug Pods.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
