Kubernetes Workload Rules: What Each Check Looks For

Kubernetes workload rules are audit checks that run against the objects inside a cluster: Deployments, StatefulSets, DaemonSets, Jobs, CronJobs, Services, Ingresses, PersistentVolumeClaims, PersistentVolumes, HorizontalPodAutoscalers, and PodDisruptionBudgets. They differ from cloud cost rules, which look at the nodes and disks a cluster runs on. A node rule can tell you a node pool is oversized; a workload rule tells you which deployment’s requests caused it.

In ZopNight, each rule is written once and instantiated for EKS, GKE, and AKS, so the same check (for example, “missing CPU or memory requests” on a Deployment) reads identically on all three providers. The areas covered are listed below.

Reliability checks

• Missing requests or limits on Deployments, StatefulSets, and DaemonSets. Requests drive scheduling and HPA utilization; limits bound CPU through throttling and memory through OOM kills.
• Missing liveness or readiness probes. Kubernetes uses liveness probes to decide when to restart a container and readiness probes to decide when it may receive traffic.
• Image tag latest or missing. With no tag, Kubernetes assumes latest, and tags can be moved to point at different images, so two pods of one deployment can run different code. Digests are immutable.
• Not fully ready or not fully scheduled workloads, single replica deployments, HPA at max capacity, and failed Jobs. The failed-Job check waits until the Job is at least an hour old, because a Job that just failed may still be inside its retry window.

Security checks

Privileged containers, containers running as root, host networking, ingress without TLS, and Services of type NodePort or LoadBalancer. The root and privileged checks read init containers as well as main containers, since an init container runs with its own security context. The host-network check skips system and service-mesh or CNI namespaces such as kube-system, istio-system, and cilium, whose agents legitimately need the node network. NodePort and LoadBalancer findings are suppressed for services tagged or named as dev or test unless a production tag is present, because an ad-hoc external endpoint on a test service can be deliberate. See privileged containers for the most severe of these.

Idle and orphan checks

Stopped deployments (zero replicas), suspended CronJobs, CronJobs that have never been scheduled, unbound PVCs, released PersistentVolumes, and Services with no endpoints. Orphaned volumes matter for cost because the disk behind a volume keeps billing until it is deleted.

Rightsizing checks

CPU over-provisioning is inferred when an HPA reports that it wants to scale below its minimum replica count while targeting CPU. The matching memory check is registered but abstains: a replica-count signal is not evidence about per-pod memory, and cutting a memory request on a guess risks OOM kills.

Configuration and posture checks

HPA misconfiguration (a maximum of one replica, minimum equal to maximum, minimum of zero, no metrics), PDBs that block all voluntary disruption or match no pods, CronJobs that allow concurrent runs, exhausted or nearly exhausted ResourceQuotas, missing topology spread, node pressure conditions, and storage class settings. These are advisory, carry no computed saving, and are read point in time from the discovered snapshot; checks prone to transient states use a minimum age so a just-created object is not flagged.

Acting on findings

Most workload findings are fixed in the manifest. ZopNight’s remediation workflow includes a step that patches a live Kubernetes manifest, and single-replica fixes through it are guided-only. Applying any change needs a cloud account with read and write access; read-only accounts still receive the findings.

Related: Kubernetes cost and reliability rules, requests and limits, and the Deployment resource page.