Container & Kubernetes

Your clusters, no new agent required.

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 Klyroo monitors.

3resource kinds: nodes, deployments, pods
0in-cluster operator to run
2tiers of "no data" alerting

Agent-based polling, not an in-cluster watcher.

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. Klyroo 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.

Setup requirement: kubectl needs to be configured with reachable cluster access from the agent's host, with read-level RBAC on nodes, pods, and deployments.
Alerting Parity

The same incident model as Container Intelligence.

Kubernetes support was built specifically to close the gap with container monitoring — not a lighter version of it.

Alert typeScopeFires when
not_readyNodeA node's Ready condition flips false
degradedDeploymentAvailable replica count falls below desired
pod_statusPodPod phase indicates a problem (CrashLoopBackOff, Failed, etc.)
restarts / restart_rate_anomalyPodRestart count rises, or the rate deviates from that pod's own baseline
nodataNode or DeploymentA specific resource stops reporting status — a silent gap gets a name instead of going unnoticed
cluster_nodataCluster-wideThe agent's entire polling connection to the cluster goes dark — a dead connection pages you instead of quietly producing no data

Same mechanism as containers, scoped per pod.

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.

Cluster resources — production
ResourceKindStatus
node-2NodeReady
checkout-apiDeploymentDegraded 2/3
checkout-api-7f9c-x2pPodCrashLoopBackOff
ALERT · restart_rate_anomalycheckout-api-7f9c-x2p
Restart rate is well above this pod's own baseline — 6 restarts in 10 min vs. a typical 0.2.
Fix: check the container logs for the crash reason before it's throttled by the backoff.
Where We Stand

Scope, honestly.

What's covered

  • Node, deployment, and pod status tracked via the agent's own cluster access
  • Full alerting parity with containers: not-ready, degraded, pod status, restarts
  • Restart-rate anomaly detection, baselined per pod
  • Two-tier "no data" alerting: per-resource and cluster-wide
  • Same incident-trail model as every other asset type

On the roadmap

  • Per-pod CPU/memory ETA prediction and baseline anomaly detection — pod metrics are categorical (status-based) today, not yet collected as numeric time series
  • Pod log content scanning via kubectl logs — parked pending a clean answer for pods running more than one container
  • Not an in-cluster operator by design — see the architecture note above for the trade-off
Pairs Well With

Related capabilities

See your clusters in the same dashboard.

Point the agent at a host with cluster access and watch node status arrive on the next check-in.

Book a 20-minute demo