1 节点调度
一般而言pod的调度都是通过RC、Deployment等控制器自动完成，但是仍可以通过手动配置的方式进行调度，目的就是让pod的调度符合我们的预期。
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也不会被调度
