k8sgpt & AI diagnostics · Prasanta Kumar Behera

Use k8sgpt to scan a cluster for common problems and explain them in plain language: its built-in analyzers, AI backends (including local models), anonymisation of names before sending data, the operator for continuous scanning, and how to treat explanations as hypotheses to verify.

What k8sgpt is

k8sgpt (a CNCF sandbox project) scans a Kubernetes cluster with analyzers (codified SRE knowledge about common failure patterns) and can use an AI backend to explain findings in plain language and suggest fixes.

k8sgpt is like a car diagnostic tool. Plug it in, and it reads the warning codes (analyzers): "sensor 42 failed". The optional AI part is a mechanic who explains what code 42 usually means and what to check. You still look under the bonnet before replacing parts.

Analyzers first

$ k8sgpt filters list
$ k8sgpt analyze
$ k8sgpt analyze --filter=Pod,Service,PersistentVolumeClaim -n shop

Typical analyzers cover pods (crash loops, image pull errors, pending), services without endpoints, unbound PVCs, ingress misconfigurations, failed jobs, nodes, and more (the list grows between versions).

Adding explanations

$ k8sgpt auth add --backend ollama --model llama3 --baseurl http://localhost:11434   # local model example
$ k8sgpt analyze --explain --anonymize -n shop

Backends include several cloud AI providers and local options (e.g. Ollama/LocalAI). Check the docs for the current list and flags. Prefer local models or --anonymize for sensitive clusters, and follow your organisation's data rules.

Continuous scanning with the operator

The k8sgpt-operator runs scans on a schedule and stores findings as Result resources, which you can alert on or feed into dashboards and chat notifications. Scope its RBAC to read-only.

Treat explanations as hypotheses

k8sgpt: "Pod cart-7d9 is failing: container exceeded memory limit; increase limits."
you:    kubectl describe pod cart-7d9 -n shop    → Last State: Terminated, Reason: OOMKilled ✔
        kubectl top pod / metrics history         → memory grows steadily: possible leak, not a low limit
decision: raise limit temporarily AND open a bug for the leak

The analyzer finding (OOMKilled) is a fact; the suggested fix is a hypothesis that the evidence refined.

Try it: diagnose a broken namespace

Install the k8sgpt CLI and, if possible, a local model with Ollama.
In a kind cluster, create problems: a bad image, a Service selecting no pods, a PVC with a missing StorageClass, a pod with a 16 Mi memory limit running a memory-hungry app.
Run k8sgpt analyze (no AI) and list findings; then --explain --anonymize and compare.
For each explanation, verify it with kubectl evidence and note whether it was right, partly right or wrong.
(Optional) Install the operator and view findings with kubectl get results -A.

Going deeper: AI diagnostics in operations

Use analyzer output as structured input to your own tools (alerts, tickets) even without AI.
Write custom analyzers for your platform's recurring problems if the built-ins don't cover them.
Combine with your MCP server (lesson 05) so an assistant can fetch evidence to confirm or reject its own hypotheses.

Recap

Analyzers find common Kubernetes problems deterministically; --explain adds AI explanations.
Protect data with local models or --anonymize.
The operator provides continuous scans as Result resources.
Explanations are hypotheses: confirm with events, status and metrics before acting.

This site is a public version of my personal engineering knowledge hub. It intentionally excludes confidential company information and internal operational details.