一般而言pod的调度都是通过RC、Deployment等控制器自动完成，但是仍可以通过手动配置的方式进行调度，目的就是让pod的调度符合我们的预期。

1 节点调度

Pod.spec.nodeName用于强制约束将Pod调度到指定的Node节点上，这里说是“调度”，但其实指定了nodeName的Pod会直接跳过Scheduler的调度逻辑，直接写入PodList列表，该匹配规则是强制匹配。

1.1 创建资源清单

vi pod-node-dispatch.yml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
        app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      nodeName: node1 #指定调度节点为node1
      containers:
      - name: nginx
        image: nginx:1.20
        ports:
        - containerPort: 80

1.2 应用部署

kubectl apply -f pod-node-selector-dispatch.yml


kubectl get pods -o wide

创建部署后，我们发现节点在node1的节点上

1.3 删除pod

删除pod应用，pod控制器会重建pod

kubectl delete pod nginx-deployment-5dc7769598-n25q5

我们发现节点删除后，重新的应用还是落在了node1节点上，说明我们的节点调度生效的

2 定向调度(标签调度)

定向调度是把pod调度到具有特定标签的node节点的一种调度方式，比如把MySQL数据库调度到具有SSD的node节点以优化数据库性能。此时需要首先给指定的node打上标签，并在pod中设置nodeSelector属性以完成pod的指定调度。

2.1 创建标签

给指定的node打上标签

2.1.1 添加标签

给node2添加上disk=ssd的标签

kubectl label nodes node2 disk=ssd

2.1.2 显示标签

显示node2的所有标签

kubectl label node node2 --list=true

我们发现我们的标签已经添加上去了

2.3 创建资源清单

vi pod-node-selector-dispatch.yml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 2
  selector:
    matchLabels:
        app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      nodeSelector:
        disk: ssd # 节点调度到
      containers:
      - name: nginx
        image: nginx:1.20
        ports:
        - containerPort: 80

2.4 应用部署

kubectl apply -f pod-node-selector-dispatch.yml


kubectl get pods -o wide

创建部署后，我们发现两个pod都在node2的节点上

2.5 删除pod

删除pod应用，pod控制器会重建pod

kubectl delete pod nginx-deployment-5dc7769598-n25q5

我们发现节点删除后，重新的应用还是落在了node2节点上，说明我们的定向调度生效的

注意:定向调度可以把pod调度到特定的node节点，但随之而来的缺点就是如果集群中不存在响应的node，即使有基本满足条件的node节点，pod也不会被调度