Kubernetes Reliability Findings: Requests, Probes, Replicas
Workload-health risks found in the same scan that prices your clusters, so cost cuts do not quietly remove your safety margin.
Reliability is the category for findings that put availability at risk rather than money. It arrived with ZopNight’s Kubernetes workload rules, a provider-agnostic rule set written once and run on EKS, GKE and AKS, so a Deployment on any of the three is checked the same way. Like compliance findings, reliability findings are written as prose, because a risk has no single “resize” or “delete” action to lead with.
What the rules check
- Missing CPU/Memory Requests and Missing CPU/Memory Limits on Deployments, StatefulSets and DaemonSets. See pod requests and limits.
- Missing Liveness Probe and Missing Readiness Probe on Deployments and StatefulSets.
- Single Replica Deployment, one pod with nothing to fail over to.
- Deployment Not Fully Ready, StatefulSet Not Fully Ready and DaemonSet Not Fully Scheduled, which report workloads that are running below their declared shape.
- HPA At Max Capacity, an autoscaler that has no room left to scale.
- Container Image Tag Latest or Missing and Failed Job.
A further set of posture checks covers PodDisruptionBudgets that block every voluntary disruption, HPAs that cannot scale because maxReplicas is 1, ResourceQuotas at their limit, nodes under disk, memory or PID pressure, and PVCs that have lost their volume.
Evidence from the control plane
Beyond pod specs, the rules can see actual control-plane activity. EKS audit logs, AKS activity log events and GKE Cloud Logging feed a shared activity store, so ZopNight knows whether a workload was scaled, patched or applied recently, not just what its spec says today.
Fixing a single replica
Single Replica Deployment is one of the few reliability findings with a remediation: it scales the workload from one replica to two by patching the live manifest. It is guided only. ZopNight never scales a workload automatically that its owner chose to run as a singleton, so a person confirms it in a type-to-confirm review.
Related
Reliability findings sit next to the cost and security findings for the same cluster; see security findings and Kubernetes cost management. For how ZopNight reports on its own scheduled actions, see reliability monitoring. Per-cloud rule lists: AWS, GCP, Azure.
Every reliability check ZopNight runs has its own page, with the reason it fires and the fix: see the reliability checks in the ZopNight rule catalogue.
Questions we get a lot.
Do reliability findings show a saving?
No. They are risk findings. They are listed with the cost work so that a cluster owner sees, for example, a missing request next to the rightsizing finding for the same workload.
Which clusters are covered?
The Kubernetes workload rules run on EKS, GKE and AKS with identical logic per cloud, using the workloads ZopNight discovers inside each connected cluster.