Why does a Kubernetes Deployment show 0/3 ready with no Pods?

The Deployment says zero of three ready, but there are no Pods at all. Not Running, not even Pending. Five minutes in, kubectl get pods returns nothing, so there's no Pod to describe and no logs to read. That means the failure happened upstream, before any Pod existed.

A Deployment doesn't create Pods itself. It creates a ReplicaSet, and the ReplicaSet asks the API server to create each Pod. The API server runs that request through admission, and only if admission passes does the Pod get stored in etcd. Until it's stored, the Pod doesn't exist, so there's nothing to list.

Follow the call. The ReplicaSet asks the API server to create a Pod. The API server asks quota admission whether it's allowed. The quota check denies it, and the API server returns 403 Forbidden. The Pod is never stored. The ReplicaSet records a FailedCreate event instead, then retries with backoff. So the evidence lands on the ReplicaSet, not on a Pod.

These two failures look similar but differ in one thing: whether the Pod object exists. A Pending Pod is stored, just unscheduled, so kubectl describe pod shows its events. A Pod that was never created was refused at admission, so there's nothing to describe. Look at the controller that tried to create it.

When admission rejects the Pod, nothing gets stored, so the error has to land somewhere else. The ReplicaSet records a FailedCreate event each time its create call is refused. It then reports ReplicaFailure on the Deployment. Meanwhile, get pods shows nothing, because there's no Pod object to list. So read the ReplicaSet events.

The quota tracks requests and limits for CPU and memory, so every new Pod has to declare them. But the orders-api container has no resources block, and there's no LimitRange to fill in defaults. Quota admission can't count what isn't declared, so it rejects each Pod create.

Now the manifest is fine, with resources set. The problem is capacity. The team-a quota allows 4 CPU cores, and other workloads already use 3.8. That leaves 0.2. One replica asks for 0.5, so quota admission rejects the create, even though the Pod spec is correct.

Quota isn't the only gatekeeper. Pod Security Admission, policy webhooks like Kyverno or Gatekeeper, or any validating admission can deny creation. You'd see the same zero Pods and the same FailedCreate trail, though message wording varies by version and tool.

Start at the Deployment. Its ReplicaFailure condition says FailedCreate, which tells you Pods were never made. Next, describe the ReplicaSet. Its event gives the reason: the quota rejected the Pod. Finally, check the quota's used versus hard values. That separates a missing resource spec from an exhausted 4 CPU limit.

You have three fixes, and each costs something. Setting explicit requests and limits is the most accurate, but you edit every workload. A LimitRange gives blanket defaults, which are really guesses. Freeing quota needs cleanup, and raising it needs approval.

Pending Pods exist and wait; rejected Pods never exist anywhere. So when kubectl get pods comes back empty, describe the ReplicaSet first, because that's where the rejection gets recorded.