> ## Documentation Index
> Fetch the complete documentation index at: https://docs.komodor.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Kubernetes
> Three catalog agents for Kubernetes — one resource at a time, one cluster with telemetry and GPU signals, or a question across every cluster Komodor covers.
Three catalog agents investigate Kubernetes, and the one to deploy depends on how much you want it
to see: **Kubernetes RCA** for one resource in one cluster, **Cluster Investigator** for one cluster
correlated against Grafana and GPU health, and **Klaudia Investigator** for a question spanning every
cluster your Komodor account covers.
The first two run inside a cluster and see only that cluster. Deploying one instance and expecting
it to answer for a fleet is the mistake worth avoiding before you install rather than after.
## 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.
| Source | What it uses it for |
| ------------------------- | -------------------------------------------------------------------- |
| Namespaced resources | The resource under investigation and everything it depends on |
| Cluster-scoped reads | Nodes, persistent volumes, storage classes, API services and metrics |
| Events and change history | Reconstructing what changed before the failure |
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.
It investigates **only the cluster it is deployed in**. The wizard states this on its first step and
holds Next until you confirm it, and recommends putting the cluster name in the agent's name for
exactly this reason.
**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-only `kubectl`, 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.
| Source | What it uses it for |
| ----------------------- | ---------------------------------------------------------------------- |
| Kubernetes | Cluster state, dependencies, events, and the change timeline |
| Prometheus, Loki, Tempo | Metrics, logs and traces around the incident window |
| GPU health signals | XID and SXid errors, DCGM metrics, and inference-engine crash patterns |
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](/manage-your-agents/build/integration-groups) 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.
**Where it stops.** It cannot answer an approval or a choice on your behalf, and that is enforced in
the agent rather than by configuration, so a gate Klaudia raises always comes back to a human. It
performs no investigation of its own either: what it can see is exactly what your Komodor account
covers.
## Next steps
Every deployable agent, and what each one is for.
The Datadog and Grafana investigators.
The group-scoped gateway endpoint Klaudia Investigator needs.
The module that owns Kubernetes spend rather than incidents.
## Related topics
- [Kubernetes Cost](/modules-and-workflows/cost-optimization/k8s-cost.md)
- [Agent catalog](/manage-your-agents/build/catalog/overview.md)
- [Cloud Cost](/modules-and-workflows/cost-optimization/cloud-optimization.md)
- [Overview](/get-started/overview.md)
- [Onboarding](/get-started/onboarding.md)