Few sights are more frustrating in a production Kubernetes cluster than a critical operator pod cycling through CrashLoopBackOff. Because operators control secondary workloads like database clusters, message queues, and ingress controllers, an operator failure immediately halts reconciliation and self-healing.
1. Inspecting the Previous Container Instance
The single most common mistake when troubleshooting CrashLoopBackOff is running kubectl logs <pod> without flags. Because the container is repeatedly dying and restarting, standard logs only query the newly spawned process, which is often still initializing.
# Inspect the crash traceback of the dying container
kubectl logs <pod-name> -n <namespace> --previous2. Checking Exit Codes with kubectl describe
Run kubectl describe pod <pod-name> -n <namespace> and scroll to the Last State section:
- Exit Code 137: The Linux kernel Out-Of-Memory (OOM) killer dispatched SIGKILL. The operator exceeded its
resources.limits.memory. - Exit Code 1: An unhandled application panic or missing environment variable caused an abnormal exit.
- Exit Code 143: Graceful SIGTERM received, usually because a liveness probe failed or the node was cordoned.
3. Verifying Operator RBAC Permissions
Kubernetes operators require granular ClusterRole permissions to watch Custom Resource Definitions (CRDs). If an operator attempts to query a CRD without appropriate verbs (get, list, watch, update), the apiserver returns HTTP 403 Forbidden, triggering an application panic on startup.