Which Linux monitoring agent makes Kubernetes cluster data collection simple?

Most of what tells you a cluster is unhealthy lives in the API server, not on the nodes: which pods are crash-looping, which Deployment has fewer ready replicas than desired, which image cannot be pulled, which node is under memory pressure. One agent reading the API sees all of it. A DaemonSet on every node adds host-level detail, but it multiplies the install, the RBAC and the data sent, and it reports the same cluster facts many times.

• •Cluster: Kubernetes version, platform (GKE, EKS, AKS, k3s, kind, RKE2), node and namespace counts, whether metrics-server is present
• •Nodes: Ready and pressure conditions, cordoned state, kubelet version, allocatable capacity against requests, limits and live usage
• •Workloads: Deployments, StatefulSets and DaemonSets with desired, ready and available counts, restarts and images
• •Problem pods: CrashLoopBackOff, OOMKilled, ImagePullBackOff, config errors, unschedulable or long-pending pods, with the reason and exit code
• •Events: recent Warning events, de-duplicated
• •API server: request latency and the 5xx rate

Only read verbs. Opservo’s ClusterRole grants get, list and watch on nodes, pods, namespaces, events, services, persistent volume claims, Deployments, ReplicaSets, StatefulSets, DaemonSets, Jobs, CronJobs, HorizontalPodAutoscalers and PodDisruptionBudgets; get on pod logs; read access to metrics.k8s.io; and get on the API server’s /metrics and /version. Its only write is to one Secret in its own namespace, for its own credentials.

The pod runs as a non-root user with a read-only root filesystem, no added capabilities and no host paths, in a namespace with Pod Security set to restricted, requesting 50m CPU and 96Mi memory.

In the dashboard, add a cluster and generate the command. The manifest is served with a single-use enrollment token and the cluster name filled in:

kubectl apply -f "https://api.getopservo.com/install-k8s.yaml?token=ipk_…&name=prod-eks"

It creates the opservo namespace, a ServiceAccount with the read-only ClusterRole, and one Deployment using the Recreate strategy, so two agents never run at once. The agent dials out over HTTPS and signs each 60-second heartbeat, so no inbound port or LoadBalancer is needed.

The cluster page has Overview, Workloads, Pods, Resources and Events tabs with a Needs attention list above them. Findings are grouped per workload, so a 20-replica crash loop is one finding carrying the worst pod’s exit code and the last 50 lines of the previous container’s log, with secrets masked. Each finding comes with the kubectl command to run, and critical findings alert through your normal channels.

The cluster agent cannot change anything: there are no remote actions, no uptime probes and no self-update for clusters, and AI chat answers questions about a cluster but cannot act on it. Linux servers outside the cluster use the separate server agent.