I built an AI agent that watches my Kubernetes cluster (and can’t break it)

I built an AI that watches my Kubernetes cluster (and can't break it)

I only ever found out something was wrong in my cluster when I happened to
open a dashboard. That was the whole reason for this project.

There are plenty of Kubernetes dashboards, and I didn't want to build
another one. I wanted something that looks at the cluster for me, pings me when something breaks, and can answer "why is payments-api failing?" without me grepping logs at midnight.

The obvious answer in 2026 is "point an LLM at it". The obvious problem is
that nobody in their right mind gives an LLM write access to their cluster.

So I built Kentinel around one
rule: the AI can see everything and touch nothing.

What it does

Every few minutes an agent snapshots the cluster — pod states, events,
deployment availability, CPU/memory from Prometheus — and has an LLM review
it. You get a healthy/warning/critical verdict with specific findings
("checkout is in ImagePullBackOff, the image tag has a typo: 1.27-alpin
should be 1.27-alpine"), not a wall of text.

There's also a chat assistant. It answers with real read-only tools — it
lists resources, reads logs, pulls events, queries metrics — so the answers are grounded in what it actually fetched, not what it imagines your cluster looks like.

Status changes go to Slack, Discord, or Teams. Only transitions, so it won't message you every five minutes about the same problem. There's an optional daily digest too: what broke, what got fixed, what the LLM usage cost.

Review history sits in SQLite on a PVC, so "when did this start?" still has an answer after a pod restart.

The part I'm most happy with

In assisted mode the agent can propose a fix. It shows up right in the chat as a diff with Approve and Reject buttons:

The agent itself cannot apply anything. Its ServiceAccount has no write
verbs at all — you can check with kubectl auth can-i. When you approve, a separate server component (which does have write access) applies the change and records the outcome. Every proposal, approval, and rejection is kept.

That's not a UX choice, it's RBAC. Even if the model goes completely off the rails, "can the AI break prod?" is answered by Kubernetes permissions, not by trusting a prompt. Fully autonomous remediation is explicitly a non-goal. One "the AI deleted my StatefulSet" story is one too many.

Nothing has to leave your cluster

The default install ships a small Ollama model in-cluster. No API keys, no
cluster data going anywhere. Being honest: the default model is small
(qwen3 0.6b, picked so it runs on a 4GB minikube) and noticeably dumber
than the cloud options. Claude, OpenAI, DeepSeek, and Gemini are supported
and you can switch from the UI — on my own cluster I run claude-haiku and
the difference in analysis quality is big. But if you're air-gapped, a
bigger local model does fine.

Try breaking something

helm install kentinel oci://ghcr.io/emreoztoprak/charts/kentinel \
  -n kentinel --create-namespace
kubectl -n kentinel port-forward svc/kentinel-server 8080:80

The repo ships a demo stack for exactly this:

make demo-up        # a healthy little "shop"
make demo-incident  # four realistic failures

Then watch the dashboard flag them and ask the assistant why. That loop —
break it, watch the AI find it — is the best two minutes of the project.

Code and docs: github.com/emreoztoprak/kentinel
· docs site

If you try it and something's wrong or missing, an issue
would genuinely help.