Kubernetes RCA
Name a resource — a kind and a name — and it investigates that resource: reconstructing what changed around it, reading the state of its dependencies, and working through a domain-specific method for whatever it is. It is built from Klaudia’s root-cause knowledge, which is why it knows how to diagnose a Kafka consumer group or a stuck Istio sidecar rather than only reading events.
Read-only
kubectl against the cluster it runs in. There is no connection to bind: the
ServiceAccount’s own permissions are simultaneously its only data source and its only security
boundary.
Where it stops. It changes nothing, and its one non-read grant is confined to a fixed list of
diagnostics by the agent’s own classifier. It has no Komodor backend, no metrics vendor and no cloud
provider API, so a cause living in any of those is outside what it can observe — and it says so
rather than inferring.
Cluster Investigator
Investigates across three signal sources at once: cluster state through read-onlykubectl, the
metrics, logs and traces around the incident from Grafana, and GPU health where the workload depends
on it. The point of combining them is correlation neither half can do alone — a pod restarting
because of a GPU fault looks like an ordinary crash loop until something reads both.
It carries the same twenty-three workload-specific methods as Kubernetes RCA, plus five
GPU-specific ones.
Before you deploy — model access, and a cluster to run in. Self-hosted only, one instance per
cluster.
Where it stops. It changes nothing in the cluster or in Grafana; its non-read grant is confined
to a fixed list of read-only in-pod diagnostics, and everything else is refused. It sees exactly one
cluster — run one per cluster, and name each after the cluster it watches.
Klaudia Investigator
Ask a Kubernetes question or describe an incident, and the agent puts it to Klaudia, who investigates across the clusters your Komodor account already covers. It relays the answer back — as prose for a question, or as a structured root-cause analysis when that is what she produces. Unlike the in-cluster investigators, it is not bound to one cluster: its reach is whatever your Komodor account’s agent already sees. It reads nothing directly. Its entire surface is a small, fixed set of tools for holding a conversation with Klaudia. Because that surface is fixed by the agent itself, the wizard’s tool checklist has no effect on it — what it can do is decided by the implementation, not by what you tick. Before you deploy — model access, and an integration group with a Komodor server.There is no Komodor connection to create. The Komodor MCP server authenticates itself on the gateway
server object, configured once in gateway administration, so the Integrations step has nothing to
collect for this agent — only the MCP group needs binding.
Next steps
Agent catalog
Every deployable agent, and what each one is for.
APM
The Datadog and Grafana investigators.
Integration groups
The group-scoped gateway endpoint Klaudia Investigator needs.
Kubernetes Cost
The module that owns Kubernetes spend rather than incidents.