¿Cómo decide el planificador de Kubernetes dónde se ejecuta un pod?

Ejecuta dos fases. El filtrado descarta los nodos que no pueden alojar el pod, según las peticiones de recursos frente a la capacidad asignable, los selectores de nodo, los taints que el pod no tolera y las restricciones de volumen o afinidad. La puntuación ordena luego a los supervivientes con reglas como repartir entre nodos y preferir los menos cargados. El ganador queda vinculado, y el kubelet de ese nodo es quien arranca de verdad el pod.

El planificador vigila los pods sin nodo asignado y los pasa por filtrado y puntuación. El filtrado descarta cualquier nodo que no pueda funcionar: no hay suficiente CPU o memoria asignable para las peticiones del pod, un selector de nodo que no encaja, un taint sin toleración correspondiente, un volumen que no puede engancharse en esa zona. La puntuación ordena lo que queda, favoreciendo el reparto y una utilización equilibrada, y el nodo que gana queda vinculado. El detalle que importa a nivel operativo es que planifica sobre las peticiones, no sobre lo que el pod usa de verdad. Así que un clúster puede aparecer al quince por ciento de utilización en los paneles y aun así negarse a planificar nada, porque todo el mundo puso peticiones muy por encima del uso real. Cuando un pod se queda en Pending voy directo a los eventos del pod, ya que el planificador te dice exactamente qué predicado falló y en cuántos nodos. Para moldear la colocación uso restricciones de reparto topológico entre zonas por disponibilidad, y taints con toleraciones para mantener las cargas generales fuera de los nodos con hardware especial.