Deployment
Does ZopNight manage Deployment?
Deployments cost nothing directly; replica count times per-pod requests reserves node capacity that bills hourly. ZopNight derives status from replica math (0 replicas is stopped, ready below desired is degraded), captures container requests, limits, probes, and images, and runs rules from missing requests (RC-1700) to stuck rollouts (RC-1714) against each one.
Rules that fire on Deployment
A Deployment manages a replicated set of stateless pods with rolling updates and rollback. The object itself is free; the money is in what it reserves: replica count times per-pod requests is node capacity held whether the pods use it or not.
Requests are reservations, and reservations are node spend
The scheduler places pods by their requests, so an over-requested Deployment burns node capacity without consuming it. Discovery captures every container’s CPU and memory requests and limits, image, probe configuration, and environment, alongside the Deployment’s selector, update strategy, and topology spread constraints. That container-level detail is what the workload rules actually read.
Three statuses from replica arithmetic
Status is derived, not copied: zero replicas maps to stopped, ready below desired maps to degraded, everything else is running. Each state feeds a different rule. Stopped Deployments older than 24 hours surface as a zero-dollar hygiene finding (RC-1732 / RC-1832 / RC-1932). The compute is gone, but PVCs, ConfigMaps, and Secrets linger. Degraded fires as Deployment Not Fully Ready (RC-1714 family, high severity) only when the rollout is complete per updatedReplicas and no start, restart, or scale transition happened in the last 15 minutes, so normal rollouts never alarm.
The rule battery that reads container specs
Missing CPU or memory requests and missing limits each get a rule per workload kind. Single-replica Deployments are flagged for zero redundancy, skipping anything an HPA or KEDA ScaledObject targets, with a guided fix that scales 1 to 2. Containers using :latest, running privileged, sharing the host network, or lacking liveness and readiness probes are each individually flagged, and CPU and memory over-provisioning is computed from a 30-day usage series with a 5 to 85 percent sanity band on the reclaimable share, abstaining when usage or cost data is missing.
kubectl get deployments -A -o custom-columns=NS:.metadata.namespace,NAME:.metadata.name,DESIRED:.spec.replicas,READY:.status.readyReplicas,UPDATED:.status.updatedReplicasScheduled downtime scales, never deletes
During a namespace schedule’s off-hours window, Deployments are scaled to 0 and restored to their prior replica count at resume. The object, its history, and its configuration stay intact; only the reserved capacity is released back to the nodes.