Kubernetes

The Kubernetes section shows the managed clusters found in your cloud accounts and gives connected clusters a live, read-only view: nodes, workloads, pods, services, ingresses, autoscalers and warning events, with history, uptime and alerts.

The sidebar has All clusters, Amazon EKS, Azure AKS, Google GKE and Oracle OKE. Each provider page shows only that provider's clusters.

Kubernetes uses the Cloud module in Access control: read to view, modify to connect clusters, refresh, toggle alerts and issue agent manifests, and full to disconnect.

#Discovered clusters

Cloud sync finds managed clusters automatically. They appear in the Discovered in your cloud accounts table as soon as a cloud account has synced. No extra setup is needed.

The table shows Cluster, Service, Region, Version, Status, Account, Network and Cost · 14d. Version and network (the VPC, linked to the Resources page) are filled in for EKS. Cost is shown when AWS per-resource cost is available; see Cost and budgets.

Discovery only lists clusters. To see what runs inside a cluster, connect it. Click Connect on its row to open the connect dialog with the cluster's details filled in.

#Connect a cluster

Click Connect cluster and choose one of three methods.

There is no kubeconfig upload. For a cluster you reach with a kubeconfig, use API URL + token or the in-cluster agent.

#Amazon EKS

You need an AWS account connected under Cloud > AWS first.

1. Choose a Discovered EKS cluster, or pick the AWS account, enter the Region and the EKS cluster name.

2. Optional: enter a Display name.

3. Give the IAM user or role of that AWS account read access inside the cluster. Run this once as a cluster admin:

   bash

   aws eks create-access-entry --cluster-name <cluster> --region <region> \
     --principal-arn <ARN of the IAM user/role used by the AWS account in OpsNexus>
   aws eks associate-access-policy --cluster-name <cluster> --region <region> \
     --principal-arn <same ARN> \
     --policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSAdminViewPolicy --access-scope type=cluster

4. Click Connect and test.

The AWS credentials also need eks:DescribeCluster. If the cluster's endpoint is private only, OpsNexus refuses to connect unless it runs inside the VPC with ALLOW_PRIVATE_TARGETS=true. Use the in-cluster agent instead.

#API URL + token

1. Enter a Name, choose the Kubernetes service (Azure AKS, Google GKE, Oracle OKE, Amazon EKS or Other / self-managed) and the API endpoint type.
2. Run the script shown in the dialog with kubectl. It creates a namespace opsnexus, a service account opsnexus-reader, a read-only ClusterRole and a token. At the end it prints the API server URL, the CA certificate and the token.
3. Paste the API server URL. It must start with https://.
4. Paste the CA certificate (base64). You can leave it empty if the API server's certificate is publicly trusted.
5. Paste the Service-account token.
6. Click Connect and test.

The token is stored in the OpsNexus secret store. If the connection test fails, the cluster is still added. Open it to fix the details or disconnect it.

#In-cluster agent

1. Enter a Name and choose the Kubernetes service.

2. Click Create agent manifest.

3. Copy or click Download YAML, then apply it:

   bash

   kubectl apply -f opsnexus-agent-<name>.yaml

The manifest creates, in the opsnexus namespace, a service account with a read-only ClusterRole, a Secret with the agent token, and a one-replica Deployment. The agent:

• runs python:3.12-alpine as a non-root user with a read-only root filesystem,
• requests 20m CPU and 64Mi memory (limits 200m and 256Mi),
• sends data to the OpsNexus public URL every 60 seconds over outbound HTTPS.

The cluster must be able to reach OpsNexus at its public URL (PUBLIC_URL). The first data arrives about a minute after the agent pod starts.

#What OpsNexus reads

All three methods use the same read-only rules. They allow get, list and watch (only get and list for metrics) on:

OpsNexus has no access to Secrets and makes no changes to the cluster.

Ingresses, autoscalers, warning events and metrics are optional. If the cluster does not serve one of these APIs, that part of the page says so.

#How often data is refreshed

• Amazon EKS and API URL + token clusters are polled every 60 seconds by the OpsNexus scheduler. Click Refresh now on the cluster page to poll at once.
• In-cluster agent clusters push every 60 seconds. If the agent has not reported for 3 minutes, the cluster is marked down.

History points are kept for METRIC_RETENTION_DAYS days (30 by default).

#The clusters page

The top of the page shows Connected clusters, Nodes ready, Pods failing / pending and Open problems across the connected clusters.

Each cluster card shows its provider, connection method, endpoint type and version; ready and total nodes; running, pending and failed pods; CPU and memory use as a share of allocatable capacity; uptime over 24 hours; and the first open problem. Click a card to open the cluster.

#The cluster page

The header shows the status (connected, degraded, down or pending), version, connection method, endpoint type and when it was last updated. A Namespace filter at the top applies to every tab except Nodes.

Click a pod to see its details: node, pod IP, owner, restarts, CPU and memory used against requests and limits, and each container's image, state, readiness and restarts.

The cluster page is read-only. It does not show container logs and has no actions on workloads.

#Cluster actions

#Problems and alerts

On every refresh, OpsNexus checks the cluster for problems and lists them in the Problems card. With Alerts on, each new problem sends a notification, and each problem that clears sends a resolved notification.

Pod problems are grouped per workload, so a crashing 20-replica Deployment sends one alert. At most 15 new problems are sent individually per refresh; the rest are summed up in one message.

To receive these alerts, subscribe a channel to the Kubernetes events in Notifications.