Anjali Sharma

I read a manifest as a set of requests and constraints, because nearly every scheduling failure traces back to one of them. They are set separately and the difference matters: a container with a request equal to its limit is guaranteed but inflexible, and one with no request may be scheduled onto a busy node and then fail. The default is that nothing is reserved, which is why an unconfigured workload behaves unpredictably under load. Scheduling then places the pod by filtering nodes on those numbers and scoring what remains. A pod requesting more than the largest node has will stay pending forever, and the message is specific enough to find and specific enough to be ignored. Node selection narrows further. A pod can demand a label, and a cluster where no node carries that label produces the same pending state with a different message. Taints and tolerations are the counterpart for keeping workloads off particular nodes. Probes decide what the platform thinks is happening. A readiness probe failing keeps traffic away; a liveness probe failing restarts the container. Setting them to the same check removes the distinction and turns a slow start into a restart loop. I also cover the two limits people meet first: the namespace quota, which can reject a deployment before it schedules, and the container count limit, which is per node and produces a scheduling failure rather than a clear one. Requests also set the scheduling priority, so two workloads with identical requests and different priorities can behave quite differently on the same cluster.