Cluster state and cost, side by side.
Most cost dashboards stop at the cloud bill. Most observability stacks stop at logs and traces. Kubernetes View joins the two: it reads cluster state through the Kubernetes API, attributes node spend to the workloads running on those nodes, and checks every workload against the Kubernetes rule set.
Use it to answer questions like:
- Which workloads have no CPU or memory requests and limits set?
- Which deployments run a single replica, or sit at their HPA maximum?
- Which PersistentVolumeClaims are unbound, and which volumes were released and never cleaned up?
- Which non-prod namespaces could be switched off overnight?
Reading the view needs read access only. Editing a manifest, running a remediation or attaching a namespace schedule each needs the matching role permission, and every change is written to the audit log.
One inventory, every cluster.
Clusters are discovered from the cloud accounts you connect: when you connect, when you trigger a sync, and every 6 hours after that. The inventory groups your estate by provider → account → cluster → namespace → workload.
| Level | What it shows |
|---|---|
| Provider | AWS / GCP / Azure: clusters and their cost. |
| Account / Project | Clusters per account and where they run. |
| Cluster | Node pools, the nodes behind them and their cost. |
| Namespace | Workloads in the namespace and its schedule, if one is attached. |
| Workload | Deployment / StatefulSet / DaemonSet detail: replicas, requests and limits, the live manifest, pod logs. |
Live pages read the cluster on demand when you open them: pod logs stream as they are written, including the previous container’s logs after a restart.
Node spend, split by workload.
The cluster bill is rarely the question. The question is usually: "which workloads are behind the number?"
Your nodes are virtual machines, and the cost of those machines is the real money. ZopNight works out each node pool’s hourly rate from the previous day’s VM cost, then gives every Deployment, StatefulSet and DaemonSet a share of it based on the CPU and memory it requests, times its replicas.
Workload cost is a re-slice of node spend, so it is kept out of every money total and is never added on top of the VM cost. It is computed daily, so a node pool change shows up in workload rates the next day.
What the rules check.
Kubernetes View runs the ZopNight Kubernetes rule set (78 rules per cloud) over every discovered workload. The rules fall into five families:
- Reliability: missing requests and limits, degraded workloads, single-replica deployments, HPAs at maximum capacity.
- Security: privileged containers, containers running as root, host networking, ingress without TLS.
- Idle: stopped deployments, suspended CronJobs, failed Jobs.
- Orphan: unbound PVCs, released PersistentVolumes, Services with empty endpoints.
- Rightsizing: CPU and memory over-provisioned, read from the HPA’s own scaling signals.
Every finding carries its severity, the evidence it was raised on, and a link to the workload. Browse the full list in the rule catalogue.
Switch non-prod namespaces off on a schedule.
Attach a ZopNight schedule to a namespace and it stops and starts on your cron, in your time zone.
| On stop | On start |
|---|---|
| Deployments and StatefulSets scale to zero. | Replica counts return to what they were. |
| CronJobs are suspended. | CronJobs resume. |
| HPAs and PodDisruptionBudgets are removed. | HPAs and PodDisruptionBudgets are restored. |
System namespaces (kube-*, istio-*, helm-*, default and ZopNight’s own) are skipped, in the UI and again when the schedule runs.
Reading is open. Changing is gated.
What a person can do in Kubernetes View follows their ZopNight role.
View
Inventory, cost, rule findings, live state and logs. No changes to the cluster.
Change
Editing a live manifest needs the resource:update permission. Secret values are stripped before a manifest is shown.
Remediate and schedule
Remediations run through a workflow with a precondition check and a validate step, for example scaling a single-replica deployment from one replica to two. Namespace schedules run on the cron you set. Every change is logged with the actor and the time.
An override holds a resource on or off against its schedule until an expiry you set. See overrides.
Already in your stack.
| Source | What we read |
|---|---|
| Kubernetes API | Workloads, pods, nodes, HPAs, PVCs and PVs, Services, manifests, pod logs. |
| EKS / GKE / AKS | Clusters and node pools, through the cloud account you connected. |
| metrics-server | Live CPU and memory usage for pods and workloads. |
| Cloud billing | The VM cost behind each node, used for workload attribution. |
Common questions.
Do you require an agent in the cluster?
No. Kubernetes View is agentless. It reads the Kubernetes API through the cloud account you connected.
How fresh is the data?
The inventory refreshes when you connect, when you trigger a sync, and every 6 hours. Live pages such as pod logs and the manifest read the cluster when you open them. Workload cost is computed daily.
Who sees what?
Access follows ZopNight roles. Viewers can read; changing a manifest, running a remediation or attaching a schedule each needs the matching permission.
Which clusters are supported?
EKS, GKE and AKS through your connected AWS, GCP and Azure accounts. OpenShift clusters connect through their own flow in zopday.
How does this relate to the rest of zopdev?
zopday shows live cluster and workload state and deploys to your clusters. zopnight adds workload cost, the Kubernetes rules and namespace schedules. One inventory, two lenses.