阅读中文版本

Preflight Check Cluster Capacity

Compare requested resources against allocatable capacity so a deployment does not land pods in a permanently pending state.

kubectl get nodes -o json | jq -r '.items[] | {name: .metadata.name, cpu: .status.allocatable.cpu, mem: .status.allocatable.memory}'

kubectl describe nodes | grep -A5 'Allocated resources' | head -40

What this recipe does

Compute whether a proposed workload fits the cluster before applying it.

A new deployment schedules slowly or never, because nodes are full and the scheduler cannot place the pods.

Prerequisites

• kubectl access to the target cluster
• The proposed resource requests
• A tool such as kubectl or jq

Procedure

1. Summarise allocatable and requested resources per node.

kubectl get nodes -o json | jq -r '.items[] | {name: .metadata.name, cpu: .status.allocatable.cpu, mem: .status.allocatable.memory}'

Expected result: You can see how much CPU and memory each node can actually offer.

2. Compare with current requests and pod count per node.

kubectl describe nodes | grep -A5 'Allocated resources' | head -40

Expected result: The allocated percentages reveal whether the new workload fits without evicting neighbours.

How to confirm it worked

Run the commands above and confirm every expected result in order. If a step does not produce the stated output, use the troubleshooting notes before continuing. A passing run shows the workload schedules promptly and no pods remain pending because of insufficient resources.

Troubleshooting

Cluster autoscaler should handle it — Check the autoscaler limits and whether the pending pods match the node template labels.

Requests too small — Right-size requests; pods with tiny requests still need real capacity and may be throttled.

Limitations

• Snapshot in time; capacity changes as pods churn.
• Does not model topology spread or anti-affinity constraints.
• Autoscaling may mask capacity issues until limits are hit.