k8s(九)-调度器

1、问答

 

2 理论基础

2.1基础知识

从k8s架构图可看出，Kubernetes属于主从分布式架构，主要由Master节点和Node节点组成。Master节点作为控制节点，对集群进行调度管理；Node节点作为真正的工作节点，运行容器。Scheduler (/ˈʃɛdjuːlə/)是kubernetes的调度器，主要的任务是把定义的pod分配到集群的节点上。

Scheduler 是作为单独的程序运行的，它启动之后会一直监听 API server ，获取Spec.NodeName为空的 pod。调度执行完之后，调度器会将 Pod 对象的NodeName字段的值，修改为 Node 的名字，表明 pod 放在哪个节点，这个步骤在 k8s中称为Bind。

它具有以下特性：

• 公平：保证每一个节点都能被合理分配资源或者能被分配资源
• 资源高效利用：集群所有资源最大化被使用
• 效率：调度的性能要好，能够尽快地完成大量的pod调度工作
• 灵活：允许用户根据自己的需求控制调度的逻辑

调度分3个阶段：节点预选、节点优选、节点选定。

阶段1：节点预选（predicate,/ˈpredɪkət/）

即排除完全不满足条件的节点，如内存大小，端口等条件不满足。基于一系列的预选规则对每个节点进行检查，将那些不符合条件的节点过滤，从而完成节点的预选。如果在 predicate 过程中没有合适的节点，pod 会一直在 pending 状态，不断重试调度，直到有节点满足条件。经过这个步骤，如果有多个节点满足条件，就继续 priorities 过程。

Predicate 有一系列的算法：

• PodFitsResources：节点上剩余的资源是否大于 pod 请求的资源
• PodFitsHost：如果 pod 指定了 NodeName，检查节点名称是否和 NodeName 匹配
• PodFitsHostPorts：节点上已经使用的 port 是否和 pod 申请的 port 冲突
• PodSelectorMatches：过滤掉和 pod 指定的 label 不匹配的节点
• NoDiskConflict：已经 mount 的 volume 和 pod 指定的 volume 不冲突，除非它们都是只读

阶段2：节点优选（Priority，praɪˈɒrəti）

对预选出的节点按照优先级大小进行排序，以便选出最合适运行Pod对象的节点

优先级由一系列键值对组成，键是该优先级项的名称，值是它的权重。这些优先级选项包括：

• LeastRequestedPriority：通过计算 CPU 和 Memory 的使用率来决定权重，使用率越低权重越高。换句话说，这个优先级指标倾向于资源使用比例更低的节点
• BalancedResourceAllocation：节点上 CPU 和 Memory 使用率越接近，权重越高。这个应该和上面的一起使用，不应该单独使用
• ImageLocalityPriority：倾向于已经有使用镜像的节点，镜像总大小值越大，权重越高

比如节点1的CPU使用率是20%，内存使用率是60%；节点2的CPU使用率是40%，内存使用率是40%，通过LeastRequestedPriority计算出它们的剩余使用率都一样，但节点2的CPU 和 Memory使用率更接近，即BalancedResourceAllocation权重更大，更会被选中。

阶段3：节点选定：从优先级排序结果中挑选出优先级最高的节点运行Pod，当这类节点多于1个时，则进行随机选择。

Kubernetes的资源分为两种：

• 可压缩资源：（例如CPU循环，Disk I/O带宽）都是可以被限制和被回收的，对于一个Pod来说可以降低这些资源的使用量而不去杀掉Pod。
• 不可压缩资源：（例如内存、硬盘空间）一般来说不杀掉Pod就没法回收。未来Kubernetes会加入更多资源，如网络带宽，存储IOPS的支持。

Schedule（/ˈskedʒuːl/）内部调度的具体过程：

第一个控制循环称为Imformer Path

它主要目的是启动一系列informer(/ɪnˈfɔːmə/,告密者，线人)，来监听 Etcd 中 Pod、Node、Service 等与调度相关的对象的变化。比如当一个待调度 Pod（即：它的 nodeName 字段是空的）被创建出来之后，调度器就会通过Pod Informer的Handler，将这个待调度Pod添加进调度队列。

同时，调度器的informer还要负责对调度器缓存( scheduler cache）进行更新。Kubernetes 调度部分进行性能优化的一个最根本原则，就是尽最大可能将集群信息 Cache 化，以便从根本上提高 Predicate 和 Priority 调度算法的执行效率。

第二个控制循环称为Scheduling Path，是调度器负责 pod 调度的主循环。

这部分的主要逻辑，就是不断地从调度队列里出队一个 Pod。

然后，调用 Predicates 算法进行“过滤”。这一步“过滤”得到的一组 Node，就是所有可以运行这个 Pod 的宿主机列表。

接下来，调度器就会再调用 Priorities 算法为上述列表里的 Node 打分，分数从 0 到 10。得分最高的 Node，就会作为这次调度的结果。

当然，上面两个调度算法所需的 node 数据，都是从 Scheduler Cache 里直接拿到的，这是调度器保证算法执行效率的主要手段。

算法执行完后，调度器会执行 Bind 操作，将 Pod 对象的 nodeName 字段的值，修改为上述 Node 的名字。但是，为了不在这个关键调度步骤中远程访问 API server，在 Bind 阶段，调度器只会更新 Scheduler Cache 里的 Pod 和 Node 信息。这种基于“乐观”假设的 API 对象更新方式，在 Kubernetes 里被称作 Assume （/əˈsjuːm/，假定，假设）。

等 Assume 之后，调度器才会创建一个 Goroutine 来异步向 API server 发起更新 Pod 的请求，来完成真正的 Bind 操作。对应节点的 kubelet 会进行一个 Admit （/ədˈmɪt/，承认，准许...加入）的操作，再次确认该 pod 能否运行在该节点上。

除了上面所说的，k8s 调度器还有一个重要设计，那就是无锁化。

在 Scheduling Path 上，调度器会启动多个Goroutine并发执行 Predicates 算法，从而提高这一阶段的执行效率。而与之类似的，Priorities 算法也会以 MapReduce 的方式并行计算，然后再进行汇总。而在这些所有需要并发的路径上，调度器会避免设置任何全局的竞争资源，从而免去了使用锁进行同步带来的巨大的性能损耗。

总结一下，上面介绍了调度的具体过程，以及提升调度效率的三个方法：Cache化、乐观假设、无锁化。

Schedule（/ˈskedʒuːl/）在k8s架构中所处的流程：

 

periodically（/pɪərɪˈɒdɪkəli/,定期地;定期;周期性）

2.2 调度器的亲和性

所谓的亲和性就是待在一起，硬亲和：必须待在一起，否则不匹配。软亲和：尽可能待在一起，不在一起也没关系。

调度器的亲和性有两种：

• 节点的亲和性
• Pod的亲和性

亲和性是在Predicate（预选）的基础上实现的.

2.2.1 节点(node)亲和性

为要创建的Pod找指定的node节点，描述字段-pod.spec.affinity.nodeAffinity（/əˈfɪnəti/, 密切关系;喜好）

亲和性的策略

pod.spec.affinity.nodeAffinity分为软策略和硬策略

• preferredDuringSchedulingIgnoredDuringExecution：软策略（preferred，/prɪˈfɜːd/,较喜欢，首选；execution，/ˌeksɪˈkjuːʃn/,处决;执行）
• requiredDuringSchedulingIgnoredDuringExecution：硬策略

当硬亲和性规则不满足时，Pod会置于Pending状态，软亲和性规则不满足时，会选择一个不匹配的节点。当节点标签改变而不再符合此节点亲和性规则时，不会将Pod从该节点移出，仅对新建的Pod对象生效。
对于软策略，会使用权重 weight 定义优先级，1~100 值越大优先级越高。

键值运算关系:

• In：label 的值在某个列表中
• NotIn：label 的值不在某个列表中
• Gt：label 的值大于某个值
• Lt：label 的值小于某个值
• Exists：某个 label 存在
• DoesNotExist：某个 label 不存在

 2.2. Pod 亲和性

为要创建的Pod找指定类型的Pod，描述字段–pod.spec.affinity.podAffinity/podAntiAffinity（anti，/ˈænti/，反对。AntiAffinity反亲和力）。

pod 亲和性主要解决 pod 可以和哪些 pod 部署在同一个拓扑域中的问题（其中拓扑域用主机标签实现，可以是单个主机，也可以是多个主机组成的 cluster、zone 等等）。

pod 反亲和性主要是解决 pod 不能和哪些 pod 部署在同一个拓扑域中的问题，它们都是处理的 pod 与 pod 之间的关系

Pod的亲和性策略：

• preferredDuringSchedulingIgnoredDuringExecution：软策略
• requiredDuringSchedulingIgnoredDuringExecution：硬策略

2.3 Taint(污点)和 Toleration(容忍)

污点和容忍的选择是在预选（调度器的调度过程第一步）之后的选择，预选是第一步，第一步都不符合，其他都免谈。
节点亲和性，是pod的一种属性（偏好或硬性要求），它使pod被吸引到一类特定的节点。Taint 则相反，它使节点能够 排斥 一类特定的 pod
Taint 和 toleration 相互配合，可以用来避免 pod 被分配到不合适的节点上。

每个节点上都可以应用一个或多个 taint（/teɪnt/） ，这表示对于那些不能容忍这些 taint 的 pod，是不会被该节点接受的。

如果将 toleration 应用于 pod 上，则表示这些 pod 可以（但不要求）被调度到具有匹配 taint 的节点上（默认都不会容忍污点）

2.3.1污点(Taint)

通过kubctl taint命令可以给某一个node节点设置污点，node上设置了污点之后，pod可以拒绝 node 的调度，甚至可以将node上已经存在的pod驱逐出去。
污点可以用于集群节点迁移准备工作，通过打污点来使当前节点上的pod迁移出去。k8s 的master节点自带污点。
污点的组成为：

key = value : effect

每个污点有一个 key 和 value 作为污点的标签，其中 value 可以为空，effect 描述污点的作用。当前 taint effect 支持如下三个选项：

• NoSchedule：表示 k8s 将不会将 Pod 调度到具有该污点的 Node 上
• PreferNoSchedule：表示 k8s 将尽量避免将 Pod 调度到具有该污点的 Node 上
• NoExecute：表示 k8s 将不会将 Pod 调度到具有该污点的 Node 上，同时会将 Node 上已经存在的 Pod 驱逐出去

污点的设置和取消：

kubectl taint nodes node1 key1=value1:NoSchedule # 设置污点
kubectl taint nodes node1 key1:NoSchedule-# 去除污点

2.3.2 容忍(Toleration)

pod 可以设置容忍，即使 node 有污点，也可以分配。

pod.spec.toleration：

tolerations:
- key: "key1"
  operator: " Equal"
  value: "value1"
  effect: "NoSchedule"
  tolerationSeconds: 3600
- key: "key1"
  operator: "Equal"
  value: "value1"
  effect: "NoExecute"
- key: "key2"
  operator: "Exists"
  effect: "NoSchedule"

• 其中key，vaule，effect要与Node中设置的taint保持一致
• operator 的值为 Exists 将会忽略 value 值
• tolerationSeconds 用于描述当 Pod 需要被驱逐时可以在 Pod 上继续保留运行的时间

k8s的namespace可以提供资源的逻辑隔离，但是无法提供物理隔离。物理隔离可以通过污点与容忍来实现。
比如想隔离不同产品线的服务，可以提前给 node 打上不同的污点，不同的产品线的pod容忍对应的污点即可。

2.4 指定调度节点

要创建的Pod被指定的node节点上创建，所有的Pod副本都会在指定的node节点创建，不会按系统策略分配node需要在调度器完成预选之后才能被调度

Ⅰ、Pod.spec.nodeName 将 Pod 直接调度到指定的 Node 节点上，会跳过 Scheduler 的调度策略，该匹配规则是强制匹配

Ⅱ、Pod.spec.nodeSelector：通过 kubernetes 的 label-selector 机制选择节点，由调度器调度策略匹配 label，而后调度 Pod 到目标节点，该匹配规则属于强制约束

2.5 调度器的可扩展设计

默认调度器的可扩展机制，在 Kubernetes 里面叫作 Scheduler Framework。这个设计的主要目的，就是在调度器生命周期的各个关键点上，为用户暴露出可以进行扩展和实现的接口，从而实现由用户自定义调度器的能力。

每一个绿色的箭头都是一个可以插入自定义逻辑的接口.比如,上面的 Queue 部分,就意味着你可以在这一部分提供一个自己的调度队列的实现,从而控制每个Pod 开始被调度(出队)的时机。
Predicates部分,则意味着你可以提供自己的过滤算法实现,根据自己的需求,来决定选择哪些机器
上述这些可插拔式逻辑,都是标准的Go语言插件机制(Go plugin 机制),也就是说,你需要在编译的时候选择把哪些插件编译进去

3、实战

3.1 节点亲和性

3.1.1 硬亲和

查看节点# kubectl get node --show-labels

k8s-node04节点没开启，现使用硬策略pod只能在指定节点k8s-node04运行

# vi node-required-affinity.yaml

apiVersion: v1
kind: Pod
metadata:
  name: node-affinity-required
  labels:
    app: node-affinity-pod
spec:
  containers:
  - name: with-node-affinity
    image: nginx:1.21.3
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:  #硬策略
        nodeSelectorTerms:
        - matchExpressions:
          - key: kubernetes.io/hostname #指定节点的key
            operator: In  #只能在k8s-node04节点运行
            values:
            - k8s-node04 #指定节点的value

应运清单

# kubectl apply -f node-required-affinity.yaml && kubectl get pod -owide

发现pod一直处于挂起状态，因为k8s-node04节点未启动

把上面的operator: In改为operator: notIn,指定节点不能在出故障的节点运行

3.1.2 软亲和

编辑清单# vi node-preferred-affinity.yaml

apiVersion: v1
kind: Pod
metadata:
  name: node-preferred-affinity
  labels:
    app: node-preferred-affinity-pod
spec:
  containers:
  - name: with-node-affinity
    image: nginx:1.21.3
  affinity:
    nodeAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 1
        preference:
          matchExpressions:
          - key: kubernetes.io/hostname
            operator: In
            values:
            - k8s-node04

应用清单后查看节点

# kubectl apply -f node-preferred-affinity.yaml
# kubectl get pod -owide

 

 发现使用软亲和时，如果对应节点出故障，pod会改变运行到其它节点，不会一直pending等待

这里weight:1权重的作用是，一个pod节点可以有多个软策略，每个软策略可以有不同的权重，然后根据权重由高到选择不同软策略，直到选中符合条件的节点。如果设置了多个软策略，权重价值就体现出来了。比如张三节点权重为4.先看看张三节点符不符合选中条件，不符合，再看权重为3的李四节点符不符合选中条件...直到找到符合选中条件的节点。

3.1.3 软硬亲和

如果硬亲和和软亲和一起用，首先必须符合硬亲和，再尝试是否符合软亲和

# kubectl apply -f node-required-preferred-affinity.yaml

apiVersion: v1
kind: Pod
metadata:
  name: node-preferred-affinity
  labels:
    app: node-preferred-affinity-pod
spec:
  containers:
  - name: with-node-affinity
    image: nginx:1.21.3
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: kubernetes.io/hostname
            operator: NotIn
            values:
            - k8s-node04
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 1
        preference:
          matchExpressions:
          - key: kubernetes.io/hostname
            operator: In
            values:
            - k8s-node02

应运资源清单，创建pod对象

# kubectl apply -f node-required-preferred-affinity.yaml
# kubectl get pod -o wide

3.2 pod亲和性和反亲和性antiaffinity

节点的亲和性匹配的是节点标签，pod的亲和性匹配的已运行的pod标签

3.2.1 软亲和

查看已运行的pod标签# kubectl get pod -owide --show-labels

编辑pod硬策略亲和性

#vi pod-preferred-affinity.yaml

apiVersion: v1
kind: Pod
metadata:
  name: pod-3
  labels:
    app: pod-3
spec:
  containers:
  - name: pod-3
    image: nginx:1.21.3
  affinity:
    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: app
            operator: In
            values:
            - node02
        topologyKey: kubernetes.io/hostname #拓扑域，具有相同标签的节点构成一个拓扑域，pod亲和性在这些相同标签的拓扑域上进行匹配

topologyKey（/[tə'pɒlədʒɪ/,拓扑结构）: kubernetes.io/hostname，这里指定的是node节点标签的key

# kubectl apply -f pod-preferred-affinity.yaml
# kubectl get pod -owide --show-labels

由于是硬策略，发现没有匹配到标签为app=node02的pod节点，当前pod处于一直挂起pending状态

 修改node-affinity-required的pod标签为node02，再看看pod-3是否匹配到了标签

# kubectl label pod node-affinity-required app=node02 --overwrite=true
# kubectl get pod -owide --show-labels

实验证明硬亲和性可以让pod调度到指定pod标签的节点

3.2.1 亲和反亲和

查看pod标签，新增pod对象，让其亲和nginx1.21的版本，但不能运行在node02的节点上

 

# pod-preferred-affinity-anti.yaml

apiVersion: v1
kind: Pod
metadata:
  name: pod-3
  labels:
    app: pod-3
spec:
  containers:
  - name: pod-3
    image: nginx:1.21.3
  affinity:
    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: version
            operator: In
            values:
            - nginx1.21
        topologyKey: kubernetes.io/hostname
    podAntiAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 1
        podAffinityTerm:
          labelSelector:
            matchExpressions:
            - key: app
              operator: In
              values:
              - node02
          topologyKey: kubernetes.io/hostname

运行pod

# kubectl apply -f pod-preferred-affinity-anti.yaml
# kubectl get pod -owide --show-labels

3.3 污点taint和容忍toleration

上面说的节点亲和性，可以理解为 pod 的一种偏好(或者是硬性的)属性，它使得 pod 被吸引到一类特定的节点。Taint(污点)则相反，它使得节点能排斥一类特定的 pod.

Taint 和 Toleration 相互配合，可以用来避免 pod 被分配到不合适的节点上。每个节点都可以有一个或多个污点，而对于不能容忍这些污点的pod，是不会被该节点接受的。如果将 Toleration 应用于 pod 上，则表示这些 pod 可以(但不要求)被调度到具有匹配 taint 的节点上。

3.3.1 master污点taint

通过kubctl taint命令可以给某一个node节点设置污点，node上设置了污点之后，pod可以拒绝 node 的调度，甚至可以将node上已经存在的pod驱逐出去。

每个污点的组成如下：

key=value:effect

每个污点有一个 key 和 value 作为污点的标签，其中 value 可以为空，effect 描述污点的作用。当前 taint  effect 支持如下三个选项：

• NoSchedule ：表示 k8s 将不会将 Pod 调度到具有该污点的 Node 上
• PreferNoSchedule ：表示 k8s 将尽量避免将 Pod 调度到具有该污点的 Node 上
• NoExecute ：表示 k8s 将不会将 Pod 调度到具有该污点的 Node 上，同时会将 Node 上已经存在的 Pod 驱逐出去

为什么pod不会被调度到k8s的master节点上，因为k8s的master节点上设置了污点？

查看master节点

# kubectl get node -n kube-system

# kubectl describe node node

发现k8s中设置了污点

这就是在运行pod的时候不会被分配到master节点，只会被分配到node节点原因。

为什么污点值为NoSchedule ，而不是NoExecute？

因为master节点上还运行其它pod对象，而这些对象很重要，不能被驱逐出去。

# kubectl get pod -owide -n kube-system --sort-by="{.spec.nodeName}"

 3.3.2 设置污点驱逐pod

创建一个自主式pod

# vi pod-preferred-affinity.yaml

apiVersion: v1
kind: Pod
metadata:
  name: pod-3
  labels:
    app: pod-3
spec:
  containers:
  - name: pod-3
    image: nginx:1.21.3
  affinity:
    podAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 1
        podAffinityTerm:
          labelSelector:
            matchExpressions:
            - key: app
              operator: In
              values:
              - node02
          topologyKey: kubernetes.io/hostname

创建pod对象

# kubectl apply -f pod-preferred-affinity.yaml
# kubectl get pod -owide --show-labels

k8s-node02节点上设置污点，驱逐pod

# kubectl taint nodes k8s-node02 check=cdf:NoExecute

随便起一个标签，比如这个节点被cdf检测，则标签为check=cdf（可没有值），effect 描述污点的作用NoExecute。

node打上污点后pod被驱逐了，然后删除污点.加上-代表删除

# kubectl taint nodes k8s-node02 check:NoExecute-  //或kubectl taint nodes k8s-node02 check=cdf:NoExecute-

 

3.3.3 容忍toleration

给k8s-node02设置污点

# kubectl taint nodes k8s-node02 check=cdf:NoExecute

查看污点：

# kubectl describe node k8s-node02

容忍污点运行pod

# vi pod-preferred-toleration.yaml

apiVersion: v1
kind: Pod
metadata:
  name: pod-3
  labels:
    app: pod-3
spec:
  containers:
  - name: pod-3
    image: nginx:1.21.3
  affinity:
    podAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 1
        podAffinityTerm:
          labelSelector:
            matchExpressions:
            - key: app
              operator: In
              values:
              - node02
          topologyKey: kubernetes.io/hostname
  tolerations:
  - key: "check"
    operator: "Equal"
    value: "cdf"
    effect: "NoSchedule"

运行pod清单

# kubectl delete -f pod-preferred-toleration.yaml
# kubectl get pod -owide

发现k8s-node02节点即使设置了污点，可资源清单允许对应标签的污点，pod依然可以调度到该节点

 3.3.4 让pod在master节点运行

把master节点的 node-role.kubernetes.io/master:NoSchedule设置为PreferNoSchedule ，表示 k8s 将尽量避免将 Pod 调度到具有该污点的 Node 上。然后关闭所有其它node节点

查看master的污点：

# kubectl describe node node

 删除污点后设置污点effect为PreferNoSchedule，这样资源不足时，pod也会被调度到master节点

# kubectl taint nodes node node-role.kubernetes.io/master:NoSchedule-
# kubectl taint nodes node node-role.kubernetes.io/master:PreferNoSchedule

查看污点

# kubectl describe node node|grep Taints

 编辑pod

# vi nginx-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: mkeduit-pod
  labels:
    app: mkeduit
    version: v1
  namespace: default
spec:
  containers:
  - name: jastudy-c
    image: nginx:1.21.3
    imagePullPolicy: IfNotPresent
    ports:
    - name: http
      containerPort: 8080

生成pod对象

# kubectl apply -f nginx-pod.yaml
# kubectl get pod -owide

发现pod已经运行到master节点了

3.5 固定节点

可以设置节点名称Pod.spec.nodeName或节点标签Pod.spec.nodeSelector，固定pod到某个节点运行

3.5.1 通过节点名称固定节点

 Pod.spec.nodeName将Pod直接调度到指定的Node节点上，会跳过Scheduler的调度策略，该匹配规则是强制匹配

 # vi nginx-deploy-nodename.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 2
  selector:
    matchLabels:
        app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      nodeName: k8s-node03  #通过nodeName指定pod固定在k8s-node03上运行
      containers:
      - name: nginx
        image: nginx:1.21.3
        ports:
        - containerPort: 80

生成实例

# kubectl apply -f nginx-deploy-nodename.yaml
# kubectl get pod -owide

3.5.2 通过节点标签固定节点

Pod.spec.nodeSelector：通过kubernetes的label-selector机制选择节点，由调度器调度策略匹配label，而后调度Pod到目标节点，该匹配规则属于强制约束

 # vi nginx-deploy-selector.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myweb
spec:
  replicas: 2
  selector:
    matchLabels:
        app: myweb
  template:
    metadata:
      labels:
        app: myweb
    spec:
      nodeSelector:
        disk: ssd
      containers:
      - name: myweb
        image: nginx:1.21.3
        ports:
        - containerPort: 80

运行deployment

# kubectl apply -f nginx-deploy-selector.yaml
# kubectl get pod -owide

在k8s-node02上打标签

# kubectl label node k8s-node02 disk=ssd
# kubectl get pod -owide -w

实验表明可以通过设置节点标签让pod运行到指定node。

给k8s-node03也打上这个标签，然后修改副本数

# kubectl label node k8s-node03 disk=ssd
# kubectl edit deploy myweb

 

 

 

 

参考文档：

pdf转word

http://www.pdfdo.com/pdf-to-word.aspx

 

Kubernetes 集群调度

https://www.jianshu.com/p/b271e6d59b59

 

 K8S原理剖析：调度器原理剖析和实践（比较有意思，使用图示讲解）

 https://blog.csdn.net/fly910905/article/details/103794239