目录
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也不会被调度
本文介绍了如何在Kubernetes中进行节点调度和定向调度。节点调度通过指定Pod.spec.nodeName将Pod强制调度到特定Node,而标签调度则通过nodeSelector将Pod分配给具有特定标签的Node,以优化如数据库在SSD节点上的性能。这两种方法都确保了Pod的调度符合预期,但定向调度可能因缺乏匹配节点而导致Pod无法调度。
3万+

被折叠的 条评论
为什么被折叠?



