k8s集群的调度

自动调度的原则

调度约束机制：list-watch

apiserver和组件之间的watch机制

调度过程的默认算法

1.预算策略

预算的算法

2.优选策略

优选的算法

*用户定制节点部署

1.强制性节点部署

2.节点标签部署（匹配机制）

标签的增删改查

**亲和性

硬策略和软策略

匹配标签的运算符

节点亲和性 node Affinity

硬策略

软策略

多个软策略

pod亲和性 pod Affinity

硬策略

pod反亲和性 pod Anti-Affinity

硬策略

软策略

练习题

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的亲和性当中，起决定性作用的是拓扑域的标签。