TL;DR

A little utility to find out fishy Pods in a Kubernetes cluster.

Here’s a handy program to figure out which Pods in a Kubernetes cluster are still… on their way, with the possibility of getting a hint as to why they might be prevented from going Ready:

Local version here. Save it as kgp and put it somewhere in PATH.

Its usage is pretty straightforward: use it as if it were kubernetes get pod. It will run the command for you with the options you pass on the command line, and filter the output to only keep Pods whose state is not as expected.

Examples (output slighly redacted for readability):

# get Pods in a weird state from any namespace
$ kgp -A
NAMESPACE       NAME     READY   STATUS    RESTARTS   AGE
polettix        foobar   0/1     Pending   0          12m

# get Pods in a weird state in namespace "polettix" only
$ kgp -n polettix
NAME     READY   STATUS    RESTARTS   AGE
foobar   0/1     Pending   0          12m

Many times, though, it’s also interesting to know what is going wrong with a Pod; an initial investigation point is usually the last event of the Pod itself. For this reason, it’s possible to get the last event line by setting environment variable KGP_SHOW_LAST_EVENT to 1 (again, output slightly redacted for readability):

$ KGP_SHOW_LAST_EVENT=1 kgp -n polettix
NAME     READY   STATUS    RESTARTS   AGE
foobar   0/1     Pending   0          12m
   [Warning] FailedScheduling:...unbound immediate PersistentVolumeClaims

I know, it can be a real hassle to do this every time, you can either set the environment variable persistently, or you can just call the program with a different name kgpe (the added e is for event):

$ ln -s kgp "$(which kgp)e"
$ kgpe -n polettix
NAME     READY   STATUS    RESTARTS   AGE
foobar   0/1     Pending   0          12m
   [Warning] FailedScheduling:...unbound immediate PersistentVolumeClaims

In this way you can decide whether you want the more compact behaviour or the more verbose one.

Oh, a question!

Why would you want the compact one?

Sometimes Pods just need some time to get up and reach the Ready state, without necessarily being problematic. In these cases, the compact behaviour prints less clutter and is perfect for running a watch looper, like this:

watch kgp -A

I hope you will never be in the condition to need this program of course… but I’m more hopeful that it will be useful in case you need to do some troubleshooting.

Cheers!