k8sgpt Doesn't Need AI to Debug Your Cluster, Just to Explain It

k8sgpt is a CNCF Sandbox project that scans a cluster and explains what's broken in plain English. The marketing leans hard on the AI part. Open the source and most of the value sits in the analyzers, rule-based checks that already encode what an experienced SRE looks for: a Deployment with zero available replicas, a ReplicaSet stuck on a missing ServiceAccount, a Service with no matching Pods. None of that needs a model. The LLM only gets called at the last step, to turn a structured finding into a readable explanation, and even then k8sgpt anonymizes pod names and identifying details before anything leaves your cluster.

I'll go through how the analyzer engine is built, run k8sgpt against a cluster with real, seeded problems, and then write a custom analyzer live for a failure mode it doesn't catch out of the box. That's the actual point: debugging knowledge written as an open source analyzer is something your team can read, argue with, and fix. Debugging knowledge baked into a closed model is something you can only ask nicely.

For anyone running Kubernetes who's tired of tribal knowledge living in one senior engineer's head, or in a vendor's black box

• How k8sgpt's analyzer engine works, and why most of its value doesn't come from the AI step

• What k8sgpt anonymizes before anything reaches a model, and what that means for running it in a regulated environment

• Writing a custom analyzer for a failure mode k8sgpt doesn't catch out of the box

• A way to think about debugging knowledge as forkable code instead of a black box you query