Kubernetes clusters

Install

1. 1.Open Add server and choose Kubernetes cluster. Optionally give the cluster a name (for example prod-eks-us-east-1).
2. 2.Click Generate kubectl command and run it against the cluster:

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

The manifest is served with your single-use enrollment token and the cluster name filled in. It creates a namespace opservo (Pod Security restricted), a ServiceAccount with a read-only ClusterRole, a Secret holding the token, and a Deployment opservo-k8s-agent with one replica. The agent registers with the token, then stores its agent ID and key in a Secret in its own namespace so a pod restart does not register again.

The cluster agent is a separate, smaller binary from the Linux agent. It runs as a non-root user with a read-only root filesystem, no added capabilities and no host paths, requesting 50m CPU and 96Mi memory.

One replica per cluster

Everything the agent reads comes from the Kubernetes API server, so one copy per cluster is enough; a copy on every node would report the same data many times. The Deployment uses the Recreate strategy so there are never two agents running at once.

What the cluster can and cannot do

The ClusterRole allows 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. The only write it holds is to one Secret in the opservo namespace, for its own credentials.

There are no remote actions, no uptime probes and no self-update for clusters. Nothing in the dashboard can run a command in a cluster, AI chat answers questions about it but cannot act, and the fleet table never marks a cluster as out of date.

What it reports

Every 60 seconds, signed like a server heartbeat:

• •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, instance type and zone, allocatable capacity against requests, limits and live usage.
• •Workloads — Deployments, StatefulSets and DaemonSets with desired, ready and available counts, restarts, images, HPA and PDB presence, and a status of ok, degraded, down, progressing or scaled to zero.
• •Pods — phase counts plus up to 40 problem pods (CrashLoopBackOff, OOMKilled, ImagePullBackOff, config errors, unschedulable, pending over 5 minutes, failed, restart storms) with reason, exit code and the last 50 lines of the previous container’s log for crash-type reasons.
• •Events — Warning events from the last 15 minutes, de-duplicated.
• •API server — request latency p50 and p99 overall and per verb, etcd latency where the control plane exposes it, and the 5xx rate.

Log tails are the only free text shipped. They are capped and are kept only as long as the heartbeat they arrived in.

Findings

The server page for a cluster 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 log tail. Each comes with the kubectl command to run. Critical findings become alerts through your normal channels. The checks:

System namespaces (kube-system, kube-public, kube-node-lease) are left out of the right-sizing and PDB checks.

Upgrading and removing

The cluster agent does not update itself. Upgrade by changing the image tag on the Deployment, or by re-applying the manifest. To remove it:

kubectl delete namespace opservo clusterrole/opservo-k8s-agent clusterrolebinding/opservo-k8s-agent