A deployment never leaves scheduling

Symptom

The deployment was accepted — it exists, GET /api/v1/deployments/{name} returns it — and no container ever appears. The replica count stays at zero and no node lists it.

Diagnose

1. Is any node in your tenant ready? Open Nodes, or GET /api/v1/nodes. Placement never crosses the tenant boundary, so another tenant’s spare capacity is not capacity.
2. Do the resource requests fit on one node? A request larger than any single node’s free capacity is not split. Compare the deployment’s requests against the nodes’ reported capacity.
3. Does the placement block match anything? A label constraint, an anti-affinity or a named node is a filter, and a filter that matches nothing leaves nowhere to put the container. See placement and allocation.
4. Is the tenant at a quota? A quota that is reached stops new containers rather than shrinking existing ones.

Resolve

• No ready node: enrol one, or bring the existing one back — see a node you enrolled is not listed.
• Requests too large: lower them, or add a node that can hold them. The requests inform placement; they are not a reservation, so the fix is fitting rather than reserving.
• Constraint matches nothing: relax it, or label a node so it matches. Setting both a placement block and the equivalent hand-written label is refused, so change one of them, not both.
• Quota reached: free capacity by removing what you no longer run, or ask for the quota to be raised.

Prevent

Set requests from measured usage rather than from a round number, and keep at least one node that matches no constraint at all, so a mistyped label leaves somewhere for the container to land.