Node
Does ZopNight manage Node?
Nodes are the only Kubernetes objects with a direct hourly cost: each is a cloud VM priced by the instance type in its node.kubernetes.io/instance-type label, and 20 half-empty nodes bill exactly like 20 full ones. ZopNight converts spec.providerID into the cloud VM record, parents every node to its EKS, GKE, or AKS pool, and captures capacity.
Rules that fire on Node
No active rule family targets Node today. Rules that used to are retired, and retired rules publish no pages and fire no findings. Scheduling and permissions coverage are unaffected.
A Kubernetes node is a worker machine registered with the API server. On EKS, GKE, and AKS it is a real cloud VM with an hourly rate. It is the one object in this Kubernetes section where the invoice is direct rather than implied.
The one Kubernetes object the invoice meters
Every pod request in the cluster eventually lands on a node, and the node bills by instance type per hour regardless of how full it is. ZopNight reads the instance type from the node.kubernetes.io/instance-type label, falling back to the deprecated beta.kubernetes.io variant, and uses it to look up hourly pricing from the pricing cache. Packing density, not pod count, decides how much of that price is doing useful work: a half-empty node costs exactly what a full one does.
From spec.providerID to a billable VM record
Kubernetes stamps each node with a spec.providerID, and discovery converts it into the native compute identifier so utilization for the underlying VM can be fetched. An aws:///us-east-1a/i-0abc... value becomes the bare i-0abc... instance ID, a gce://project/zone/name value becomes the full //compute.googleapis.com/... path, and azure:/// values are kept as ARM resource IDs. Alongside that, the record carries status (Ready, NotReady, or Unknown), roles, kubelet version, architecture, CPU capacity in millicores, memory capacity in GB, pod capacity, taints, and node conditions.
Pools own capacity; nodes only report it
Each node’s parent in the inventory is its pool, resolved from provider labels: eks.amazonaws.com/nodegroup, cloud.google.com/gke-nodepool, or kubernetes.azure.com/agentpool. That mirrors how capacity is actually managed, since you resize a node group or agent pool and never an individual machine, so cost rollups happen at the pool level too.
kubectl get nodes -L node.kubernetes.io/instance-type,topology.kubernetes.io/zoneWhy the node-rightsizing rule stays switched off
A node CPU-underutilization rule exists in the recommender (30 percent average threshold with a 50 percent peak guard) but is deliberately not registered. Kubernetes metrics-server returns point-in-time snapshots in which average, maximum, and minimum are the same single value, which makes any average-versus-peak comparison dead code. Rather than ship unreliable downsize advice, node savings are left to workload rightsizing and scheduling until a real time-series source is available.