When a service misbehaves, the first question is where in the cluster the problem is. At Demuxer we build Kuberniq, a desktop Kubernetes client for macOS and Windows, and this article shows its analysis, which answers that question for the whole cluster at once.

The problem

Without a tool, the search is a round of commands. You run kubectl get pods -A and scan for anything that isn't Running, kubectl describe pod on each suspect to read its events, kubectl get nodes to see whether a node dropped out, and then you look up what ImagePullBackOff or OOMKilled means in that case and what to do about it. On a cluster with a couple of hundred pods spread over dozens of namespaces, the one canary that can't pull its image is easy to miss.

How Kuberniq does it

Kuberniq Overview of the whole cluster over 7 days, with the Analysis window open on the finding "The image cannot be pulled"

  1. Open the cluster and set the namespace dropdown to All namespaces.
  2. Open Overview and pick a range: 1 h, 6 h, 24 h or 7 d. The summary shows nodes ready, pods running, pending and failed, CPU and memory requested against allocatable and used, and restarts, with charts of CPU and memory from the cluster's Prometheus. In the screenshot, 13 of 14 nodes are ready, 242 pods are running and 3 have failed.
  3. The Analysis tool window at the bottom groups the findings into Errors, Warnings and Information, and the tabs narrow them to Failures, Reliability or Recommendations.
  4. Select a finding to read it. In the screenshot, under Errors (6), "The image cannot be pulled" points at search/search-api-canary-rrql5bqvl-mmlmx. The detail says that the container cannot pull ghcr.io/shop/search-api:2.15.0-rc.1, then Why: "the name or the tag does not exist, the registry asks for a credential the pod does not have, or the registry does not answer", and What to do: "Check the name and the tag of the image and, for a private registry, the imagePullSecrets of the pod."

The same list has a node that is not ready, a container that restarts in a loop and a container that went past its memory limit, each with its own Why and What to do.

What it doesn't do yet

The analysis says what to do, and you make the fix yourself; the exception is the CPU and memory recommendations, which you apply through a diff. It reads the cluster when you open it and when you analyze again, so it doesn't watch the cluster while Kuberniq is closed and doesn't send alerts to chat or to a pager. The rules are the ones Kuberniq ships with, and you can't write your own.

Try it

The free license covers personal projects, study, teaching and open source, with the whole app and no account. If you try the analysis on one of your clusters, we'd like to know which finding it missed and which one you'd rather not see.

Download Kuberniq from its page: https://demuxer.dev/kuberniq?utm_source=devto&utm_medium=organic&utm_campaign=kuberniq-desktop&utm_content=dev-to%2Fanalysis