When does the Kube-Scheduler assign a pod to a node?

When does the Kube-Scheduler assign a pod to a node?

• A. After the pod has been created and registered in ETCD
• B. Before the pod exists in the API server
• C. During initial cluster bootstrap
• D. After the pod is deleted

Answer: (A)

Scheduling happens once a Pod exists in the API server and is in Pending state. The Kube-Scheduler watches for such Pods, then selects a suitable Node and binds the Pod to that Node by updating the Pod’s binding (setting its nodeName via the Binding subresource or Pod spec). The Pod must be stored in etcd through the API server before scheduling can occur, so you can’t schedule a Pod before it’s created and registered. After a Pod is created and registered, the scheduler may assign it to a node; after deletion there’s nothing to schedule, and bootstrap processes aren’t the typical scheduling path for regular Pods.

Scheduling happens once a Pod exists in the API server and is in Pending state. The Kube-Scheduler watches for such Pods, then selects a suitable Node and binds the Pod to that Node by updating the Pod’s binding (setting its nodeName via the Binding subresource or Pod spec). The Pod must be stored in etcd through the API server before scheduling can occur, so you can’t schedule a Pod before it’s created and registered. After a Pod is created and registered, the scheduler may assign it to a node; after deletion there’s nothing to schedule, and bootstrap processes aren’t the typical scheduling path for regular Pods.