Kubernetes CrashLoopBackOff? Step-by-Step Fix with Real Example (2026 Guide)

I pulled a MongoDB Docker image on my Mac, tagged it, pushed it to Azure Container Registry (ACR), and watched the pod crash the moment Kubernetes tried to run it on an Ubuntu node. If you've seen exec format error buried inside your pod logs, you've hit the same wall. Here's exactly what happened and how I fixed it.

But before dig more into fix, lets understand what is the issue exactly and why it occur?

What is CrashloopBackOff?

CrashLoopBackOff is one of the most common Kubernetes pod states that tells you: "The container started, crashed immediately, Kubernetes restarted it, it crashed again — and now I'm backing off before trying again."

Kubernetes applies an exponential backoff delay (10s → 20s → 40s → ... up to 5 minutes) between restart attempts. The CrashLoopBackOff status is not the root cause itself — it is a symptom. The actual reason is always buried in the pod logs or events.

Common cause	Typical log signal
Architecture mismatch (this post)	exec format error
Missing env variable / secret	connection refused / nil pointer
OOMKilled (out of memory)	OOMKilled, exit code 137
Application startup crash	Application-specific error in logs
Wrong entrypoint / CMD	no such file or directory

What was the cause? Why i faced this isse?

I faced this issue because of Architecture mismatch, I use Apple MacBook (M1) it run on arm64  architecture by default. My nodes for k8s cluster was Ubuntu Linux run on amd64 architecture. Pushing an arm64 image to ACR and deploying it causesCrashLoopBackOffimmediately.

When an arm64 binary tries to execute on an amd64 CPU, the kernel simply cannot decode the instruction set and throws:

exec format error

This error means: "I tried to execute this binary but it's compiled for a different CPU architecture." Kubernetes sees the container exit immediately (exit code 1 or 132) and enters the crash loop.

Real Example : what i faced?

So instead directly dig into issue lets see my project. I was working on a chat app project its a 3 tier project with 1. Frontend 2.Backend 3.DB
I was using MongoDB for the project. I wrote the statefulset manifest for the DB

apiVersion: apps/v1

kind: StatefulSet

metadata:

name: mongodb-statefulset

labels:

app: DB

namespace: mongodb

spec:

replicas: 1

serviceName: mongodb-clusterip-service

selector:

matchLabels:

app: DB

template:

metadata:

labels:

app: DB

spec:

containers:

- name: mongodb

image: chatappacr.azurecr.io/mongo:1.0

env:

- name: MONGO_INITDB_ROOT_PASSWORD

valueFrom:

secretKeyRef:

name: mongodb-secret

key: MONGO_INITDB_ROOT_PASSWORD

- name: MONGO_INITDB_ROOT_USERNAME

valueFrom:

configMapKeyRef:

key: MONGO_INITDB_ROOT_USERNAME

name: mongodb-configmap

volumeMounts:

- name: mongodb-storage

mountPath: /data/db

ports:

- containerPort: 27017

resources:

requests:

cpu: 250m

memory: 512Mi

limits:

cpu: 500m

memory: 1Gi

volumes:

- name: mongodb-storage

persistentVolumeClaim:

claimName: pvc-azure-disk 

When i apply this manifest using:

kubectl apply -f mongodb-statefulset.yml

The pod is not in as expected running state. I checked pod using below command:

kubectl get pod -n mongodb

How to debug theCrashloopBackoff?

step1 :  Check the logs first

Use kubectl log command and see the logs for the pod

kubectl logs <podName> -n <namespace name>

i got the issue 
on log issueis exec /usr/local/bin/docker-entrypoint.sh: exec format error

CrashloopBackoff Step-by-step fix

The fix is to build (or pull) the image explicitly targeting linux/amd64, then push that to ACR.

Docker Buildx makes this straightforward, even from a Mac.:

fix 1: Pull the correct platform image explicitly

Use --platform to force Docker to pull the amd64 variant from the multi-arch manifest:

docker pull --platform linux/amd64 mongo:7.0

fix2: Alternative: build your own image with Buildx targeting amd64

If you're building a custom image (not just retagging an official one), use docker buildx build to cross-compile and push in one command:

docker buildx build \
  --platform linux/amd64,linux/arm64 \
  --tag myregistry.azurecr.io/myapp:1.0 \
  --push .

Restart the Kubernetes deployment

Verifyig the fix

get the pod details:

kubectl get pod -n mongodb

and you will see the issue is fixed.

Pro tip: The official MongoDB Docker Hub image supports multi-arch. Using --platform linux/amd64 at pull or build time is a one-liner fix that eliminates this class of error permanently for your team.

FAQ

Why doesn't Docker warn me when I push an arm64 image?

Docker treats image pushing as architecture-agnostic — it just pushes whatever is tagged. ACR also accepts any image regardless of architecture. The mismatch only surfaces at runtime when the kernel tries to execute the binary.

Does this affect EKS or GKE, not just AKS?

Yes. Any Kubernetes cluster running on standard amd64 (x86-64) nodes — whether AKS, EKS, GKE, or self-managed — will fail to run arm64 images with the same exec format error.

What if I need to run an arm64 image on AKS?

AKS supports arm64 node pools using Azure's Ampere Altra-based virtual machines (Dpsv5 series). You would need to add an arm64 node pool and use node selectors or affinities to schedule arm64 workloads there. For most teams, re-building for amd64 is the simpler path.

Can I use Rosetta 2 / QEMU emulation to avoid rebuilding?

Docker Desktop uses QEMU to emulate architectures, which is why arm64 images might appear to "work" locally on Mac with emulation enabled. However, Kubernetes nodes don't have QEMU installed — they only run native binaries. Emulation is a local development convenience, not a production solution.