No in-cluster operator to install, upgrade, or grant broad RBAC to. The same lightweight agent that already watches your hosts polls the cluster it runs alongside — nodes, deployments, and pods get the same alerting and incident model as everything else Kllyroo monitors.
Most Kubernetes monitoring tools ask you to deploy an in-cluster operator — its own Deployment, its own RBAC bindings, its own upgrade cycle, separate from the rest of your monitoring stack. Kllyroo takes a different, deliberately simpler approach: the same agent already running on a host with cluster access uses kubectl to poll node, pod, and deployment status on its normal check-in cycle, then reports it through the exact same protocol it already uses for host and container data.
That's a real trade-off, stated plainly: detection cadence follows the agent's check-in interval rather than a live watch stream, and there's no continuous in-cluster event tail. What you get in exchange is one thing to install instead of two, and Kubernetes data sitting in the same dashboard as everything else — not a separate tool with a separate login.
kubectl needs to be configured with reachable cluster access from the agent's host, with read-level RBAC on nodes, pods, and deployments.Kubernetes support was built specifically to close the gap with container monitoring — not a lighter version of it.
| Alert type | Scope | Fires when |
|---|---|---|
not_ready | Node | A node's Ready condition flips false |
degraded | Deployment | Available replica count falls below desired |
pod_status | Pod | Pod phase indicates a problem (CrashLoopBackOff, Failed, etc.) |
restarts / restart_rate_anomaly | Pod | Restart count rises, or the rate deviates from that pod's own baseline |
nodata | Node or Deployment | A specific resource stops reporting status — a silent gap gets a name instead of going unnoticed |
cluster_nodata | Cluster-wide | The agent's entire polling connection to the cluster goes dark — a dead connection pages you instead of quietly producing no data |
Pod restart cadence is baselined individually, keyed on (server, namespace, pod name) — the same exponential-moving-average approach used for container restart-rate anomaly detection, applied here so a pod that legitimately cycles often isn't judged against a pod that shouldn't.
| Resource | Kind | Status |
|---|---|---|
| node-2 | Node | Ready |
| checkout-api | Deployment | Degraded 2/3 |
| checkout-api-7f9c-x2p | Pod | CrashLoopBackOff |
kubectl logs — parked pending a clean answer for pods running more than one containerOffices in India and the US — reach out and we'll get back to you.