The Kubernetes scheduler assigns newly created Pods to suitable worker nodes. After the API server receives a Pod request, the scheduler watches for Pods requiring placement, filters nodes against scheduling criteria, and scores the remaining candidates before assigning a node. section 3.2.2 section 3.3.2
Placement depends on constraints and on the ability of a node to satisfy the workload request:
- Node selectors and node affinity restrict placement to matching labeled nodes. section 3.0
- Taints and tolerations determine whether a Pod can use a node with specific scheduling restrictions. section 3.3.2
- A Pod remains unscheduled and does not start when its resource request cannot be met or its constraints match no node. section 3.2.2
- After assignment, the kubelet retrieves the Pod specification through the API server and creates the Pod on the selected node. section 3.2.3
Selecting a custom scheduler
A Pod can name a non-default scheduler with schedulerName: custom-scheduler1. Without that field, kube-scheduler handles the placement. Custom schedulers are useful when deployments require considerations not included by the base scheduler, although implementing one is outside this treatment. section 3.3.2
apiVersion: v1 kind: Pod metadata: name: nginx-web spec: containers: - name: nginx image: bitnami/nginx schedulerName: custom-scheduler1
Use the manifest listing to see the schedulerName field in a complete Pod definition and distinguish custom scheduling from the default behavior. section 3.3.2
