kubernetes之亲合性调度

实验环境： 1、win10,vmwrokstation虚机； 2、k8s集群：3台centos7.6 1810虚机，1个master节点,2个node节点    k8s version：v1.22.2    containerd://1.5.5 

链接：https://pan.baidu.com/s/1P3Z_ujk22dYDXzM37WI5FA?pwd=v01w 提取码：v01w

2022.2.18-39.亲和调度-实验代码.zip

1. 实践：nodeSelector测试(测试成功)-2022.5.16
2. 实践:节点亲和力测试(成功测试)-2022.5.16
3. 实践：pod亲和力(测试成功)-2022.5.16
4. 实践：pod反亲和性(测试成功)-2022.5.16
5. 实践:污点与容忍(测试成功)-2022.5.16
6. 实践：nodeName测试(测试成功)-2022.5.16

一般来说，我们部署的部署 Pod 是通过集群自动调度策略为了选择节点，调度器默认考虑足够的资源和平均负荷。但有时我们需要能够控制更细的粒度 Pod 的调度，例如，我们希望机器学习的一些应用程序只能运行 GPU 的节点上；但有时我们的服务交流更频繁，我们希望能够提供这项服务 Pod 都调度到同一个的节点上。这需要一些调度来控制 Pod 的调度了，主要有两个概念：亲和力和反亲和力，亲和力又分了节点亲和性(nodeAffinity)和 Pod 亲和性(podAffinity)。

Kubernetes基于list-watch机制实现组件间交互的解耦。 当这些资源发生变化时，其他组件监控其负责的资源，kube-apiserver这些组件类似于这个过程发布与订阅。

• 我们通过命令创造一个pod：

• 当我们执行命令时kubectl run pod4 --image=nginx之后，组件之间的调用过程是什么？

1、kubectl向apiserver发送创建pod的请求 2、apiserver接收到并向etcd写入存储，成功返回提示  #这个过程类似于老板和客户之间的关系:  api-server:开店老板  etcd：仓库  其它组件：客户 

• 注：如下：kubectl run pod4 --image=nginx当命令卡住时，有什么问题？

–>说明： etcd数据库写入有问题/性能瓶颈，或api-server和etcd 两者总有一个问题：

• 继续：scheduler向apiserver查询未分配的pod通过自己的调度算法选择合适的资源node绑定(给这个pod标记资源，标记分配到node1)注意:它的调度算法比较复杂均匀，会考虑你机器的硬件配置。pod属性等综合属性；

• 问题：如果scheduler如果组件有问题，那么此时pod会发生什么状态？

答：pod会出现通过kubectl get pod根本看不到你刚创造的。pod信息的，更别说它的状态了，因为它根本没分配。

所以，如果你创造的话pod根本看不到信息，那么哪个组件可能有问题呢？–>scheduler组件可能有问题。

• 如果是pending状态：pod已经绑定到某个节点了。

• 继续流程解释：

4、kubelet向apiserver查询分配到自己的节点pod，调用docker api（/var/run/docker.sock）创建容器 5、kubelet获取docker创建容器的状态并报告apiserver，apiserver更新状态到etcd存储 6、kubectl get pods就能查看pod状态  备注： kubelet管理容器的主要功能是：  这是默认调用docker api接口 [root@k8s-master ~]#ll /var/run/docker.sock srw-rw---- 1 root docker 0 Jun 14 11:46 /var/run/docker.sock 

• 问题：controller-manager为什么不用？

controller-manager例如，它用于管理控制器deployment（rs）、service，因为创造的是一个pod，不受它管理。

如果controller-manager把它放在这里，一般是放在etcd后面的：

• kube-proxy为什么没用到？

proxy是用于管理pod网络，例如service，因为没创建service。

kube-proxy的主要功能就是维护好service，service是k8s的抽象资源；

• 扩展

比如，这个容器创建的时候创建失败了，不是一个running状态，也不是一个pending状态。可能就是docker在启动容器时，用你那个镜像启动容器失败了。所以这是你需要用docker去run一个镜像看能不能起来。

⚠️ 注意

resources: {} 资源调度依据这个，挺重要的； 很多大厂都会去二开"schedulerName: default-scheduler"这个调度器的，会去加一些调度策略，进而完成他们的需求；

🍂 调度原因失败分析

1.limits：在Cgroups里使用；cpu.cfs_quota/cpu.cfs_period(10w)=1 2.requests：cpu这个requests其实在Cgroup里也起作用。当你多个应用发生资源抢占时，他们抢占的cpu时间比较是多少呢？是通过cpu.share去调节的。k8s是如何实现的呢？这里如果设置的是一个cpu，request是1的话，那么cpu.share是1024。 如果你设置的是100m，相当于是0.1个cpu，那么cpu.share就是0.1*1024=102. 也就是cpu.requests也是最终会体现到Cgroups里面去的。

nodeSelector：用于将Pod调度到匹配Label的Node上，如果没有匹配的标签会调度失败。

作用：

• 约束Pod到特定的节点运行
• 完全匹配节点标签

应用场景：

• 专用节点：根据业务线将Node分组管理
• 配备特殊硬件：部分Node配有SSD硬盘、GPU

在了解亲和性之前，我们先来了解一个非常常用的调度方式：nodeSelector。我们知道 label 标签是 kubernetes 中一个非常重要的概念，用户可以非常灵活的利用 label 来管理集群中的资源，比如最常见的 Service 对象通过 label 去匹配 Pod 资源，而 Pod 的调度也可以根据节点的 label 来进行调度。

• 我们可以通过下面的命令查看我们的 node 的 label：

[root@master1 ~]#kubectl get node --show-labels 
NAME      STATUS   ROLES                  AGE    VERSION   LABELS
master1   Ready    control-plane,master   109d   v1.22.2   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=master1,kubernetes.io/os=linux,node-role.kubernetes.io/control-plane=,node-role.kubernetes.io/master=,node.kubernetes.io/exclude-from-external-load-balancers=
node1     Ready    <none>                 109d   v1.22.2   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=node1,kubernetes.io/os=linux
node2     Ready    <none>                 109d   v1.22.2   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=node2,kubernetes.io/os=linux

• 现在我们先给节点 node2 增加一个com=youdianzhishi的标签，命令如下：

[root@master1 ~]#kubectl label nodes node2 com=youdianzhishi
node/node2 labeled

我们可以通过上面的 --show-labels 参数可以查看上述标签是否生效。

[root@master1 ~]#kubectl get node node2 --show-labels 
NAME    STATUS   ROLES    AGE    VERSION   LABELS
node2   Ready    <none>   109d   v1.22.2   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,com=youdianzhishi,kubernetes.io/arch=amd64,kubernetes.io/hostname=node2,kubernetes.io/os=linux

• Pod里配置nodeSelector字段：

当节点被打上了相关标签后，在调度的时候就可以使用这些标签了，只需要在 Pod 的 spec 字段中添加 nodeSelector 字段，里面是我们需要被调度的节点的 label 标签，比如，下面的 Pod 我们要强制调度到 node2 这个节点上去，我们就可以使用 nodeSelector 来表示了：

$ vim 01-node-selector-demo.yaml

# 01-node-selector-demo.yaml
apiVersion: v1
kind: Pod
metadata:
  labels:
    app: busybox-pod
  name: test-busybox
spec:
  containers:
  - command:
    - sleep
    - "3600"
    image: busybox
    imagePullPolicy: Always
    name: test-busybox
  nodeSelector: #注意：nodeSelector是和containers同级的；注意，这个放的顺序一定要放在containers后面。不然会报错的！
    com: youdianzhishi

• 部署后，我们就可以通过 describe 命令查看调度结果：

hg@LAPTOP-G8TUFE0T:/mnt/c/Users/hg/Desktop/yaml$ kubectl apply -f 01-node-selector-demo.yaml 
pod/test-busybox created

hg@LAPTOP-G8TUFE0T:/mnt/c/Users/hg/Desktop/yaml$ kubectl get po  -owide
NAME           READY   STATUS    RESTARTS   AGE   IP             NODE    NOMINATED NODE   READINESS GATES
test-busybox   1/1     Running   0          78s   10.244.2.210   node2   <none>           <none>


[root@master1 ~]#kubectl describe po test-busybox 
Name:         test-busybox
Namespace:    default
Priority:     0
Node:         node2/172.29.9.53
Start Time:   Thu, 17 Feb 2022 19:45:11 +0800
Labels:       app=busybox-pod
Annotations:  <none>
Status:       Running
IP:           10.244.2.210
IPs:
  IP:  10.244.2.210
Containers:
  test-busybox:
    Container ID:  containerd://1b4d323942e6d305a4ea25f655eaced77f8cb8e4229eaf1972dc9dfb1246a0c0
    Image:         busybox
    Image ID:      docker.io/library/busybox@sha256:5acba83a746c7608ed544dc1533b87c737a0b0fb730301639a0179f9344b1678
    Port:          <none>
    Host Port:     <none>
    Command:
      sleep
      3600
    State:          Running
      Started:      Thu, 17 Feb 2022 19:45:31 +0800
    Ready:          True
    Restart Count:  0
    Environment:    <none>
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-p5z6t (ro)
Conditions:
  Type              Status
  Initialized       True 
  Ready             True 
  ContainersReady   True 
  PodScheduled      True 
Volumes:
  kube-api-access-p5z6t:
    Type:                    Projected (a volume that contains injected data from multiple sources)
    TokenExpirationSeconds:  3607
    ConfigMapName:           kube-root-ca.crt
    ConfigMapOptional:       <nil>
    DownwardAPI:             true
QoS Class:                   BestEffort
Node-Selectors:              com=youdianzhishi
Tolerations:                 node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
                             node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
  Type    Reason     Age    From               Message
  ----    ------     ----   ----               -------
  Normal  Scheduled  2m45s  default-scheduler  Successfully assigned default/test-busybox to node2
  Normal  Pulling    2m43s  kubelet            Pulling image "busybox"
  Normal  Pulled     2m26s  kubelet            Successfully pulled image "busybox" in 17.583571931s
  Normal  Created    2m26s  kubelet            Created container test-busybox
  Normal  Started    2m25s  kubelet            Started container test-busybox
[root@master1 ~]#

我们可以看到 Events 下面的信息，我们的 Pod 通过默认的 default-scheduler 调度器被绑定到了 node2 节点。不过需要注意的是nodeSelector 属于强制性的，如果我们的目标节点没有可用的资源，我们的 Pod 就会一直处于 Pending 状态。

通过上面的例子我们可以感受到 nodeSelector 的方式比较直观，但是还不够灵活，控制粒度偏大。接下来我们再和大家了解下更加灵活的方式：节点亲和性(nodeAffinity)。

测试结束。😘

🍂 问题：

因pod中nodeSelector里的标签未出现在all node节点，但后续给node打好符合要求的标签，原来处于pending状态的pod会自动迁移过去的吗？–>会的。

前面我们了解了 kubernetes 调度器的调度流程，我们知道默认的调度器在使用的时候，经过了 predicates 和 priorities 两个阶段，但是在实际的生产环境中，往往我们需要根据自己的一些实际需求来控制 Pod 的调度，这就需要用到 nodeAffinity(节点亲和性)、podAffinity(pod 亲和性) 以及 podAntiAffinity(pod 反亲和性)。

🍂 亲和性调度可以分成软策略和硬策略两种方式:

• 软策略就是如果现在没有满足调度要求的节点的话，Pod 就会忽略这条规则，继续完成调度过程，说白了就是满足条件最好了，没有的话也无所谓
• 硬策略就比较强硬了，如果没有满足条件的节点的话，就不断重试直到满足条件为止，简单说就是你必须满足我的要求，不然就不干了

对于亲和性和反亲和性都有这两种规则可以设置： preferredDuringSchedulingIgnoredDuringExecution 和requiredDuringSchedulingIgnoredDuringExecution，前面的就是软策略，后面的就是硬策略。

节点亲和性（nodeAffinity）主要是用来控制 Pod 要部署在哪些节点上，以及不能部署在哪些节点上的，它可以进行一些简单的逻辑组合了，不只是简单的相等匹配(比如前面的nodeSelector就是标签的=)。

nodeAffinity：节点亲和类似于nodeSelector，可以根据节点上的标签来约束Pod可以调度到哪些节点。

🍂 相比nodeSelector：

• 匹配有更多的逻辑组合，不只是字符串的完全相等，支持的操作符有：In、NotIn、Exists、DoesNotExist、Gt、Lt
• 调度分为软策略和硬策略，而不是硬性要求
  • 硬（required）：必须满足
  • 软（preferred）：尝试满足，但不保证

🍂 这里的匹配逻辑是 label 标签的值在某个列表中，现在 Kubernetes 提供的操作符有下面的几种：

• In：label 的值在某个列表中 (这里的操作符，我们一般只用到in就足够了；)
• NotIn：label 的值不在某个列表中
• Gt：label 的值大于某个值
• Lt：label 的值小于某个值
• Exists：某个 label 存在
• DoesNotExist：某个 label 不存在

⚠️ 注意：

但是需要注意的是如果 nodeSelectorTerms 下面有多个选项的话，满足任何一个条件就可以了；如果 matchExpressions有多个选项的话，则必须同时满足这些条件才能正常调度 Pod。

🍂

比nodeSelector更高级的一个！ matchExpressions比selector更加灵活。

• 比如现在我们用一个 Deployment 来管理8个 Pod 副本，现在我们来控制下这些 Pod 的调度，如下例子：

# 02-node-affinity-demo.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: node-affinity
  labels:
    app: node-affinity
spec:
  replicas: 8
  selector:
    matchLabels:
      app: node-affinity
  template:
    metadata:
      labels:
        app: node-affinity
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80
          name: nginxweb
      affinity: #定义亲和性
        nodeAffinity: #节点亲和性 
          requiredDuringSchedulingIgnoredDuringExecution:  # 硬策略
            nodeSelectorTerms:
            - matchExpressions:
              - key: kubernetes.io/hostname
                operator: NotIn
                values:
                - master1 #相当于只能调度到node1和node2节点。默认就不会调度到master1节点
          preferredDuringSchedulingIgnoredDuringExecution:  # 软策略(尽可能调度到node2节点)
          - weight: 1
            preference:
              matchExpressions:
              - key: com
                operator: In
                values:
                - youdianzhishi

上面这个 Pod 首先是要求不能运行在 master1 这个节点上，如果有个节点满足 com=youdianzhishi 的话就优先调度到这个节点上。

由于上面 node02 节点我们打上了 com=youdianzhishi 这样的 label 标签，所以按要求会优先调度到这个节点来的。

• 现在我们来创建这个 Pod，然后查看具体的调度情况是否满足我们的要求。

➜ kubectl apply -f node-affinty-demo.yaml
deployment.apps/node-affinity created
➜ kubectl get pods -l app=node-affinity -o wide #老师这个有部分pod被调度到node1节点
NAME                            READY   STATUS    RESTARTS   AGE     IP             NODE         NOMINATED NODE   READINESS GATES
node-affinity-cdd9d54d9-bgbbh   1/1     Running   0          2m28s   10.244.2.247   node2   <none>           <none>
node-affinity-cdd9d54d9-dlbck   1/1     Running   0          2m28s   10.244.4.16    node1   <none>           <none>
node-affinity-cdd9d54d9-g2jr6   1/1     Running   0          2m28s   10.244.4.17    node1   <none>           <none>
node-affinity-cdd9d54d9-gzr58   1/1     Running   0          2m28s   10.244.1.118   node1   <none>           <none>
node-affinity-cdd9d54d9-hcv7r   1/1     Running   0          2m28s   10.244.2.246   node2   <none>           <none>
node-affinity-cdd9d54d9-kvxw4   1/1     Running   0          2m28s   10.244.2.245   node2   <none>           <none>
node-affinity-cdd9d54d9-p4mmk   1/1     Running   0          2m28s   10.244.2.244   node2   <none>           <none>
node-affinity-cdd9d54d9-t5mff   1/1     Running   0          2m28s   10.244.1.117   node2   <none>           <none>

从结果可以看出有5个 Pod 被部署到了 node2 节点上，但是可以看到并没有一个 Pod 被部署到 master1 这个节点上，因为我们的硬策略就是不允许部署到该节点上，而 node2 是软策略，所以会尽量满足。

测试结束。😘

Pod 亲和性（podAffinity）主要解决 Pod 可以和哪些 Pod 部署在同一个拓扑域中的问题（其中拓扑域用主机标签实现，可以是单个主机，也可以是多个主机组成的 cluster、zone 等等），而 Pod 反亲和性主要是解决 Pod 不能和哪些 Pod 部署在同一个拓扑域中的问题，它们都是处理的 Pod 与 Pod 之间的关系。比如一个 Pod 在一个节点上了，那么我这个也得在这个节点，或者你这个 Pod 在节点上了，那么我就不想和你待在同一个节点上。

Taint（污点）与Tolerations（污点容忍）

Taints：避免Pod调度到特定Node上

Tolerations：允许Pod调度到持有Taints的Node上

应用场景：

• 专用节点：根据业务线将Node分组管理，希望在默认情况下不调度该节点，只有配置了污点容忍才允许分配
• 配备特殊硬件：部分Node配有SSD硬盘、GPU，希望在默认情况下不调度该节点，只有配置了污点容忍才允许分配
• 基于Taint的驱逐

对于 nodeAffinity 无论是硬策略还是软策略方式，都是调度 Pod 到预期节点上。而污点（Taints）恰好与之相反，如果一个节点标记为 Taints ，除非 Pod 也被标识为可以容忍污点节点，否则该 Taints 节点不会被调度 Pod。

比如用户希望把 Master 节点保留给 Kubernetes 系统组件使用，或者把一组具有特殊资源预留给某些 Pod，则污点就很有用了，Pod 不会再被调度到 taint 标记过的节点。我们使用 kubeadm 搭建的集群默认就给 master 节点添加了一个污点标记，所以我们看到我们平时的 Pod 都没有被调度到 master 上去。

⚠️ 污点：其实是一个label标签，只不过它是一个特殊的label标签。

[root@master1 ~]#kubectl get node master1 --show-labels 
NAME      STATUS   ROLES                  AGE    VERSION   LABELS
master1   Ready    control-plane,master   110d   v1.22.2   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=master1,kubernetes.io/os=linux,node-role.kubernetes.io/control-plane=,node-role.kubernetes.io/master=(注意，这个是一个空标签),node.kubernetes.io/exclude-from-external-load-balancers=

[root@master1 ~]#kubectl describe node master1
Name:               master1
Roles:              master
Labels:             beta.kubernetes.io/arch=amd64
                    beta.kubernetes.io/os=linux
                    kubernetes.io/arch=amd64
                    kubernetes.io/hostname=master1
                    kubernetes.io/os=linux
                    node-role.kubernetes.io/master=
......
Taints:             node-role.kubernetes.io/master:NoSchedule
Unschedulable:      false
......

我们可以使用上面的命令查看 master 节点的信息，其中有一条关于 Taints 的信息：node-role.kubernetes.io/master:NoSchedule，就表示master 节点打了一个污点的标记，其中影响的参数是 NoSchedule，表示 Pod 不会被调度到标记为 taints 的节点。除了 NoSchedule 外，还有另外两个选项：

• PreferNoSchedule：NoSchedule 的软策略版本，表示尽量不调度到污点节点上去
• NoExecute：该选项意味着一旦 Taint 生效(被打上taint)，如该节点内正在运行的 Pod 没有对应容忍（Tolerate）设置，则会直接被逐出。 哈哈😂这个命令也是够狠。。。kubectl taint node k8s-node1 disktype=ssd:NoExecute

🍂 污点 taint 标记节点的命令如下：

➜ kubectl taint nodes node2 test=node2:NoSchedule
node "node2" tainted

上面的命名将 node2 节点标记为了污点，影响策略是 NoSchedule，只会影响新的 Pod 调度，如果仍然希望某个 Pod 调度到 taint 节点上，则必须在 Spec 中做出 Toleration 定义，才能调度到该节点。

🍂 最后如果我们要取消节点的污点标记，可以使用下面的命令：

➜ kubectl taint nodes node2 test-
node "node2" untainted

• 比如现在我们想要将一个 Pod 调度到 master 节点：

# 05-taint-demo.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: taint
  labels:
    app: taint
spec:
  replicas: 3
  selector:
    matchLabels:
      app: taint
  template:
    metadata:
      labels:
        app: taint
    spec:
      containers:
      - name: nginx
        image: nginx