目录
kube-scheduler是集群的调度器,主要任务就是把pod部署到节点上。
自动调度的原则
1.公平性:保证每个可用的节点都可以部署pod
2.资源的高效利用:就是集群当中的资源可以被最大化的使用
3.调度的性能要好:能够对大批量的pod完成调度工作
4.灵活性:用户可以根据自己的需求进行控制
调度约束机制:list-watch
list-watch机制进行每个组件的协作,保持数据同步、实现组件之间的解耦。
apiserver和组件之间的watch机制
kubelet、controller-manager、scheduler这些都是主动监听apiserver的信息,是根据监听到的信息来做出指定的动作,然后再传给apiserver,然后每一步的动作都会通过apiserver传到etcd里。
调度过程的默认算法
1.预算策略
预算策略就是先对节点的条件进行过滤
预算的算法
1. pod的资源适应性:节点上是否有资源能够满足pod请求的资源
2. pod的主机适应性:如果指定了节点,那么要检查集群当中是否有满足要求的节点可供部署
3. pod的主机端口适应性:它会检查节点上使用的端口是否与pod请求的端口冲突
4. pod与主机磁盘的适应性:就是每个pod之间的挂载不能冲突
如果预算条件不满足,pod会进入pending状态
2.优选策略
优选策略就是根据过滤出来的节点选择一个最优的节点
优选的算法
1. 最低请求优先级:它通过计算节点上的cpu和内存的使用率,来确定节点的权重。使用率越低权重就越大,那么就越会被选中作为部署节点。它倾向于选择资源利用率占用较少的节点。
2. 平衡资源分配:它也是根据节点上的cpu和内存的使用率,来确定节点的权重。它的权重是按照cpu和内存之间的使用率的比率,两个使用率越接近越好。(1:1)
3. 镜像本地性优先级:如果节点在本地已经有了需要的镜像,分配的概率更大。
*用户定制节点部署
1.强制性节点部署
nodeName:强制性的选择一个节点,不再需要调度器和算法,直接部署即可。
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: nginx1
name: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx1
template:
metadata:
labels:
app: nginx1
spec:
containers:
- name: nginx
image: nginx:1.22
nodeName: node01
2.节点标签部署(匹配机制)
就是只要标签匹配都可以部署。
kubectl get nodes --show-labels 查看节点标签
注:标签的格式是键值对形式,一个节点可以有多个标签,每个标签以 ,隔开
标签的增删改查
查看标签 kubectl get nodes --show-labels
创建标签 kubectl label nodes node01 test1=a
修改标签 kubectl label nodes node01 test1=b --overwrite
删除标签 kubectl label nodes node01 test1-
根据节点标签匹配部署:
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: nginx1
name: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx1
template:
metadata:
labels:
app: nginx1
spec:
containers:
- name: nginx
image: nginx:1.22
nodeSelector:
test2: b
问题:标签选举节点是否需要调度器和算法?
是需要调度器和算法来进行分配的
**亲和性
所有的亲和性都是根据节点标签和pod的标签来进行选择
硬策略和软策略
软策略语法: preferredDuringSchedulingIgnoredDuringExecution
软策略:在选择节点的时候,尽量满足部署的条件,非条件也可以部署
软策略的应用场景:尽量把资源调度到需要的节点
硬策略语法: requiredDuringSchedulingIgnoredDuringExecution
硬策略:必须满足指定的节点条件,否则pending
硬策略应用场景:一般用于特殊场景,比如节点故障,但是有业务要更新,强制性的把资源调度到指定的节点
匹配标签的运算符
键值的运算关系:
1. In 表示在、匹配、= (这里是大写的 i )
2. NotIn 表示不在、不等于 、逻辑非
3. Gt 表示大于
4. Lt 表示小于
5. Exists 表示存在
6. DoesNotExist 表示不存在
举例:
节点亲和性 node Affinity
是根据软策略和硬策略来分配的
硬策略
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: nginx1
name: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx1
template:
metadata:
labels:
app: nginx1
spec:
containers:
- name: nginx
image: nginx:1.22
affinity:
#选择亲和性的字段
nodeAffinity:
#节点亲和性
requiredDuringSchedulingIgnoredDuringExecution:
#硬策略
nodeSelectorTerms:
- matchExpressions:
- key: test3
operator: In
values:
- a
#节点亲和性的硬策略,表示必须选择带有标签的值是test3=a
然后kubectl get pod -o wide 就能查看部署到哪个节点了
注:1. 条件不满足,肯定pending
2. 条件满足时,调度器即刻生效,不需要手动调整
3. 需要调度器分配,不同节点可以有相同的标签
软策略
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: nginx1
name: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx1
template:
metadata:
labels:
app: nginx1
spec:
containers:
- name: nginx
image: nginx:1.22
affinity:
#选择亲和性的字段
nodeAffinity:
#节点亲和性
preferredDuringSchedulingIgnoredDuringExecution:
#软策略
- weight: 1
preference:
matchExpressions:
- key: test3
operator: NotIn
values:
- a
#节点亲和性的软策略,表示希望部署到不包含test3=a的标签节点
注:这里是尽量满足条件,不是必须,所以有可能部署到其他节点上。
多个软策略
affinity:
#选择亲和性的字段
nodeAffinity:
#节点亲和性
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 1
preference:
matchExpressions:
- key: test3
operator: NotIn
values:
- a
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 2
preference:
matchExpressions:
- key: test3
operator: In
values:
- a
#多个软策略以权重来进行分配,权重高的,优先级大
注:如果已经有硬策略,一般不需要声明软策略。
pod亲和性 pod Affinity
是根据软策略和硬策略来分配的
topologyKey :定义节点的拓扑域,也就是用来反映pod和节点之间的关系
前提条件:首先要先在节点上创建app=nginx1的pod,得有这个pod才能匹配。
硬策略
affinity:
#选择亲和性的字段
podAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
#根据标签进行选择
matchExpressions:
- key: app
operator: In
values:
- nginx1
topologyKey: test1
#匹配pod的标签是app=nginx1,且节点上有标签名是test1
注:实际上指向节点的还是topologyKey拓扑域,pod的标签只是倾向性
pod反亲和性 pod Anti-Affinity
注:如果节点上本身没有pod也可以直接创建反亲和性
硬策略
affinity:
#选择亲和性的字段
podAntiAffinity:
#pod的反亲和性
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
#根据标签进行选择
matchExpressions:
- key: app
operator: In
values:
- nginx1
topologyKey: test1
#只能部署在pod的标签不是app=nginx1且节点的标签名不能有test1的节点上
注:节点上不能有pod的标签是app=nginx1 且 节点的标签不能有test1
如果以上两个条件有一个满足时还能运行的原因?
答:1.能够部署的原因在于调度器,调度器的核心是为了部署pod,只要能够部署,调度器有可能会忽略规则进行部署,即使有规则,调度器依然会部署。
2. 资源不足的情况下,为了pod能够部署,调度器极有可能忽略所有的限制。
软策略
affinity:
#选择亲和性的字段
podAntiAffinity:
#pod的反亲和性
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 1
podAffinityTerm:
labelSelector:
#根据标签进行选择
matchExpressions:
- key: app
operator: In
values:
- nginx1
topologyKey: test1
总结:其实在pod的亲和性当中,起决定性作用的是拓扑域的标签。
练习题
1、实现pod的探针:就绪探针 用 tocScoket
2、做挂载卷,容器目录:/usr/share/nginx/html/ 、节点目录: /opt/html
3.node的亲和性:尽量部署在node01
4、pod的亲和性:尽量部署包含有app=nginx的pod且标签名是xy102的节点。
5、软策略选择标签名不包含xy102, xy102值小于100