🚨 Kubernetes Error Guide: 'Error syncing pod' failed to StartContainer Kubelet

Exact Error Message

The kubelet emits this when it tries to bring a pod to its desired state and one of the container operations fails. The pod stays out of Running and the kubelet retries on a backoff:

E0628 13:22:51.004812  1798 pod_workers.go:1300] "Error syncing pod, skipping" err="failed to \"StartContainer\" for \"app\" with CrashLoopBackOff: \"back-off 40s restarting failed container=app pod=web-6c9d_default(2f1a...)\"" pod="default/web-6c9d" podUID="2f1a..."

Other variants name a different lifecycle step inside the same Error syncing pod wrapper:

E0628 13:25:10.778210  1798 pod_workers.go:1300] "Error syncing pod, skipping" err="failed to \"CreatePodSandbox\" for \"web-6c9d\" with CreatePodSandboxError: ... failed to set up sandbox container ... network: plugin not initialized"

The pattern is constant: Error syncing pod, skipping followed by failed to "<Step>", where <Step> is the specific lifecycle action (StartContainer, CreatePodSandbox, KillPodSandbox, EnsureSecretExists) that failed.

What the Error Means

The kubelet runs a pod sync loop: for each pod it owns, it compares the desired spec against actual runtime state and performs the operations needed to converge them — create the sandbox, pull images, set up volumes, start each container, run probes. Each step is a named action in the kubelet’s pod_workers.

Error syncing pod, skipping is the generic wrapper logged whenever any step in that sequence returns an error. The kubelet aborts this sync iteration (“skipping”), backs off, and retries later. The truly diagnostic part is the inner failed to "<Step>" clause and the reason after it — that is what tells you which phase broke and why.

So this error is not a root cause by itself; it is the kubelet announcing that pod reconciliation failed at a specific stage. StartContainer failures usually mean the container exited or the image/command is wrong; CreatePodSandbox failures point to CNI/networking; volume/secret steps point to mounts and config. Read the inner clause and route accordingly.

Common Causes

• StartContainer → CrashLoopBackOff — the container starts then exits non-zero (bad command, missing config, app error).
• StartContainer → image/exec error — wrong entrypoint, missing binary, or no such file or directory.
• CreatePodSandbox — CNI plugin not initialized, IPAM exhausted, or network config errors.
• Volume mount failures — MountVolume.SetUp failed for missing PVC, Secret, or ConfigMap.
• EnsureSecretExists/config — referenced Secret/ConfigMap does not exist yet.
• Image pull failures — ErrImagePull/ImagePullBackOff bubbling up as a sync error.
• Runtime errors — containerd/CRI returning errors (out of disk, hung shim).

How to Reproduce the Error

Create a pod whose container immediately exits with a non-zero code; the kubelet will repeatedly fail StartContainer:

apiVersion: v1
kind: Pod
metadata:
  name: bad-exit
spec:
  containers:
    - name: app
      image: busybox:1.36
      command: ["sh", "-c", "echo starting; exit 1"]

kubectl apply -f bad-exit.yaml
kubectl get pod bad-exit

NAME       READY   STATUS             RESTARTS      AGE
bad-exit   0/1     CrashLoopBackOff   3 (25s ago)   72s

journalctl -u kubelet --no-pager | grep 'Error syncing pod'

The kubelet log shows Error syncing pod, skipping ... failed to "StartContainer" ... with CrashLoopBackOff.

Diagnostic Commands

# Pod status, restart count, and the high-level reason
kubectl get pod <POD> -o wide
kubectl describe pod <POD> | grep -A12 'Events'

# Container state and last termination — exit code and reason live here
kubectl get pod <POD> -o jsonpath='{.status.containerStatuses[*].state}{"\n"}{.status.containerStatuses[*].lastState}'

# Application logs from the current and previous (crashed) container
kubectl logs <POD> --previous --tail=50

# Kubelet view of the failing sync step
journalctl -u kubelet --no-pager | grep -iE 'Error syncing pod|failed to "Start|CreatePodSandbox|MountVolume'

# Node-level pressure that can break sync (disk, runtime)
journalctl -u containerd --no-pager | tail -40

Start with the inner failed to "<Step>" clause in describe/kubelet logs, then jump to the matching source: kubectl logs --previous for StartContainer, CNI logs for CreatePodSandbox, and PVC/Secret existence for mount failures.

Step-by-Step Resolution

1. Read the failing step. Extract the failed to "<Step>" clause. Everything downstream depends on which phase broke — do not guess.

2. For StartContainer (CrashLoopBackOff). The container is starting and exiting. Get the exit code from lastState.terminated and the app logs:

kubectl logs <POD> --previous --tail=50
kubectl get pod <POD> -o jsonpath='{.status.containerStatuses[0].lastState.terminated.exitCode}'

Fix the command, missing env/config, or application bug. Exit code 137 = OOMKilled (raise memory limits); 127 = command not found.

3. For StartContainer exec errors. no such file or directory means a wrong command/entrypoint or an image that lacks the binary. Correct the command or image.

4. For CreatePodSandbox. This is networking. Verify the CNI plugin is installed and ready (/etc/cni/net.d, CNI daemonset running) and that the node has free pod IPs. Restart the CNI agent if it failed to initialize.

5. For volume/secret/config steps. MountVolume.SetUp failed or EnsureSecretExists means a referenced PVC/Secret/ConfigMap is missing or unbound. Create the object or fix the reference; check PVC binding for volume cases.

6. For runtime/disk errors. If containerd reports no space left or hung shims, free disk on the node and ensure the runtime is healthy before the kubelet can complete sync.

Prevention and Best Practices

• Set memory limits deliberately and watch for exit code 137; OOMKills are a top StartContainer failure.
• Validate image entrypoints and commands in CI so exec errors never reach the cluster.
• Create Secrets/ConfigMaps/PVCs before (or atomically with) the workloads that reference them.
• Monitor CNI daemonset health and pod-IP exhaustion to prevent CreatePodSandbox failures.
• Alert on rising pod restart counts and Error syncing pod log rate per node.
• Keep node disk and the container runtime healthy so sync steps are not blocked by infrastructure. More in our Kubernetes & Helm guides.

Related Errors

• PLEG is not healthy — runtime stalls that also break pod sync.
• node not ready — node-level failures that prevent any successful sync.
• Evicted: the node was low on resource — resource pressure that interrupts running pods.

Frequently Asked Questions

Is Error syncing pod a root cause? No. It is a generic wrapper the kubelet logs whenever any pod lifecycle step fails. The actionable detail is the inner failed to "<Step>" clause and the reason after it — read that, not the wrapper.

Why does the kubelet say “skipping”? “Skipping” means it abandoned this sync iteration after the error and will retry on a backoff. The pod is not abandoned permanently; the kubelet keeps attempting to reconcile it until it succeeds or the spec changes.

My pod shows CrashLoopBackOff but the app logs look fine — why? Check the previous container with kubectl logs --previous and the exit code in lastState.terminated. A clean current log can mean the container restarted; the failure is in the prior instance, often an exit during startup or a liveness-probe kill.

What does failed to "CreatePodSandbox" mean specifically? The kubelet could not set up the pod’s network namespace via CNI. Causes are an uninitialized/crashed CNI plugin, exhausted pod IP ranges, or bad CNI config — all distinct from container startup problems.

How is this different from a scheduling failure? A sync failure happens after the pod is assigned to a node — the kubelet owns it and is trying to run it. A scheduling failure (FailedScheduling) happens before assignment and shows no node. Different phase, different fix.