KubeGlance Blog — Kubernetes Troubleshooting & Cluster Operations

How kubectl decides what to put in the STATUS column

Tue, 18 Aug 2026 02:30:00 +0100

The STATUS column in kubectl get pods is not a field. There is no status.status in the Pod API, and it is not status.phase either — phase only has five possible values (Pending, Running, Succeeded, Failed, Unknown), and none of them is CrashLoopBackOff.

STATUS is computed client-side, by kubectl, every time you run the command. Knowing the algorithm explains most of the confusing output you have ever seen from it.

RBAC for a read-only Kubernetes user (and why view isn't enough)

Tue, 18 Aug 2026 02:00:00 +0100

Kubernetes has no “read-only” switch. There is no flag, no mode, and no account type. Read-only is just a set of verbs — get, list, watch — and everything depends on which resources you attach them to.

The obvious move is to use the built-in view ClusterRole. It is the right starting point, but it has three properties that catch people out, and the third one is a security problem rather than an inconvenience.

How KUBECONFIG merges multiple files (first wins, not last)

Tue, 18 Aug 2026 01:30:00 +0100

You can point KUBECONFIG at several files at once and kubectl will treat them as one configuration:

export KUBECONFIG=~/.kube/config:~/.kube/work.yaml:~/.kube/prod.yaml

Most people assume this behaves like PATH-style overriding, where the last definition wins. It is the opposite. The first file to define a given name wins outright, and every later definition of that name is discarded silently.

That single inversion is behind almost every “why am I connected to the wrong cluster” story.

How to fix CrashLoopBackOff in Kubernetes

Tue, 18 Aug 2026 01:00:00 +0100

CrashLoopBackOff is not an error. It is Kubernetes telling you it has given up restarting your container for now and is sitting out a waiting period before it tries again. The actual failure already happened, and the status has replaced it.

That distinction is the whole reason people get stuck. You cannot fix CrashLoopBackOff, because nothing is broken called CrashLoopBackOff. You fix whatever made the container exit, and the status resolves itself.

ImagePullBackOff and ErrImagePull: what they mean and how to fix them

Tue, 18 Aug 2026 00:30:00 +0100

These two statuses are the same problem at two different moments. ErrImagePull is the kubelet telling you a pull just failed. ImagePullBackOff is the kubelet telling you it has failed enough times that it is now waiting before trying again.

The important consequence: by the time you look, the status has usually changed from the useful one to the useless one. ImagePullBackOff contains no information about why. The reason is in the pod’s Events, and that is the only place it lives.