image-20220217154111330

目录

文章目录

实验环境

实验环境：
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、调度

一般情况下我们部署的 Pod 是通过集群的自动调度策略来选择节点的，默认情况下调度器考虑的是资源足够，并且负载尽量平均，但是有的时候我们需要能够更加细粒度的去控制 Pod 的调度，比如我们希望一些机器学习的应用只跑在有 GPU 的节点上；但是有的时候我们的服务之间交流比较频繁，又希望能够将这服务的 Pod 都调度到同一个的节点上。这就需要使用一些调度方式来控制 Pod 的调度了，主要有两个概念：亲和性和反亲和性，亲和性又分成节点亲和性(nodeAffinity)和 Pod 亲和性(podAffinity)。

2、nodeSelector

📍 案例演示：nodeSelector(测试成功)

在了解亲和性之前，我们先来了解一个非常常用的调度方式：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 的 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:
    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)。

3、亲和性和反亲和性调度

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

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

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

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

1.节点亲和性

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

📍 案例演示：节点亲和性(测试成功)

🍀 比如现在我们用一个 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>



$ kubectl apply -f 02-node-affinity-demo.yaml 
deployment.apps/node-affinity create
$ kubectl get po -owide # 注意，我本次是全部都调度在node2节点了。
NAME                             READY   STATUS    RESTARTS        AGE   IP             NODE    NOMINATED NODE   READINESS GATES
node-affinity-5f76cfc56d-d94qw   1/1     Running   0               33s   10.244.2.218   node2   <none>           <none>
node-affinity-5f76cfc56d-g2kjq   1/1     Running   0               33s   10.244.2.215   node2   <none>           <none>
node-affinity-5f76cfc56d-k7fwt   1/1     Running   0               33s   10.244.2.211   node2   <none>           <none>
node-affinity-5f76cfc56d-n7mdn   1/1     Running   0               33s   10.244.2.216   node2   <none>           <none>
node-affinity-5f76cfc56d-nbff4   1/1     Running   0               33s   10.244.2.212   node2   <none>           <none>
node-affinity-5f76cfc56d-qpl89   1/1     Running   0               33s   10.244.2.214   node2   <none>           <none>
node-affinity-5f76cfc56d-rslrn   1/1     Running   0               33s   10.244.2.213   node2   <none>           <none>
node-affinity-5f76cfc56d-vqn69   1/1     Running   0               33s   10.244.2.217   node2   <none>           <none>

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

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

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

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

测试结束。😘

2.Pod 亲和性

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

这里要重点理解下什么是拓扑域？–>你可以把它看成为一个分组。

image-20220218130412064

image-20220218130728392

image-20220218130913150

image-20220218131033136

📍 案例演示：pod亲和性(测试成功)

🍀 由于我们这里只有一个集群，并没有区域或者机房的概念，所以我们这里直接使用主机名来作为拓扑域，把 Pod 创建在同一个主机上面。

[root@master1 ~]# kubectl get node --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=
node1     Ready    <none>                 110d   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>                 110d   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 的亲和性：

# 03-pod-affinity-demo.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: pod-affinity
  labels:
    app: pod-affinity
spec:
  replicas: 3
  selector:
    matchLabels:
      app: pod-affinity
  template:
    metadata:
      labels:
        app: pod-affinity
    spec:
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80
          name: nginxweb
      affinity:
        podAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:  # 硬策略
          - labelSelector: #去选择具有app in ["busybox-pod"]的pod所在的hostname这个域。
              matchExpressions:
              - key: app
                operator: In
                values:
                - busybox-pod
            topologyKey: kubernetes.io/hostname

上面这个例子中的 Pod 需要调度到某个指定的节点上，并且该节点上运行了一个带有 app=busybox-pod 标签的 Pod。我们可以查看有标签 app=busybox-pod 的 pod 列表：

[root@master1 ~]#kubectl get pods -l app=busybox-pod -o wide
NAME           READY   STATUS    RESTARTS      AGE   IP             NODE    NOMINATED NODE   READINESS GATES
test-busybox   1/1     Running   5 (23m ago)   18h   10.244.2.210   node2   <none>           <none>

🍀 我们看到这个 Pod 运行在了 node2 的节点上面，所以按照上面的亲和性来说，上面我们部署的3个 Pod 副本也应该运行在 node2 节点上：

$ kubectl apply -f 03-pod-affinity-demo.yaml 
deployment.apps/pod-affinity created
$ kubectl get pods -o wide -l app=pod-affinity
NAME                           READY   STATUS    RESTARTS   AGE   IP             NODE    NOMINATED NODE   READINESS GATES
pod-affinity-785f687c5-52t54   1/1     Running   0          60s   10.244.2.228   node2   <none>           <none>
pod-affinity-785f687c5-g594p   1/1     Running   0          60s   10.244.2.229   node2   <none>           <none>
pod-affinity-785f687c5-s6j7h   1/1     Running   0          60s   10.244.2.227   node2   <none>           <none>

🍀 如果我们把上面的 test-busybox 和 pod-affinity 这个 Deployment 都删除，然后重新创建 pod-affinity 这个资源，看看能不能正常调度呢：

$ kubectl delete -f 01-node-selector-demo.yaml
pod "test-busybox" deleted
$ kubectl delete -f 03-pod-affinity-demo.yaml
deployment.apps "pod-affinity" deleted
$ kubectl apply -f 03-pod-affinity-demo.yaml 
deployment.apps/pod-affinity created
$ kubectl get po
NAME                           READY   STATUS    RESTARTS   AGE
pod-affinity-785f687c5-2256q   0/1     Pending   0          80s
pod-affinity-785f687c5-7gpz5   0/1     Pending   0          80s
pod-affinity-785f687c5-97gpj   0/1     Pending   0          80s

我们可以看到都处于 Pending 状态了，这是因为现在没有一个节点上面拥有 app=busybox-pod 这个标签的 Pod，而上面我们的调度使用的是硬策略，所以就没办法进行调度了，大家可以去尝试下重新将 test-busybox 这个 Pod 调度到其他节点上，观察下上面的3个副本会不会也被调度到对应的节点上去。(这里可以自己测试下，可以利用node1的kubernetes.io/hostname: node1标签用nodeSelector来实现)

🍀 我们这个地方使用的是 kubernetes.io/hostname 这个拓扑域，意思就是我们当前调度的 Pod 要和目标的 Pod 处于同一个主机上面，因为要处于同一个拓扑域下面。为了说明这个问题，我们把拓扑域改成 beta.kubernetes.io/os，同样的我们当前调度的 Pod 要和目标的 Pod 处于同一个拓扑域中，目标的 Pod 是拥有 beta.kubernetes.io/os=linux 的标签，而我们这里所有节点都有这样的标签，这也就意味着我们所有节点都在同一个拓扑域中，所以我们这里的 Pod 可以被调度到任何一个节点，重新运行上面的 app=busybox-pod 的 Pod，然后再更新下我们这里的资源对象：

$ kubectl get po -owide
NAME                            READY   STATUS    RESTARTS   AGE    IP             NODE    NOMINATED NODE   READINESS GATES
pod-affinity-6bf5bb4fc4-j6ctw   1/1     Running   0          22s    10.244.2.230   node2   <none>           <none>
pod-affinity-6bf5bb4fc4-xb7tr   1/1     Running   0          22s    10.244.2.231   node2   <none>           <none>
pod-affinity-6bf5bb4fc4-xl6pn   1/1     Running   0          22s    10.244.1.97    node1   <none>           <none>

image-20220218145745621

可以看到现在是分别运行在2个节点下面的，因为他们都属于 beta.kubernetes.io/os 这个拓扑域。

⚠️ 这里需要注意下：通过上面这个实验可以看到，这2个node节点都属于beta.kubernetes.io/os这个拓扑域，但只有node1上有app=pod-affitity这个标签的pod，从结果可以看到也是可以调度到node2上的。

实验结束。😘

3.Pod 反亲和性

📍 案例演示：pod反亲和性(测试成功)

🍀 Pod 反亲和性（podAntiAffinity）则是反着来的，比如一个节点上运行了某个 Pod，那么我们的模板 Pod 则不希望被调度到这个节点上面去了。我们把上面的 podAffinity 直接改成 podAntiAffinity：

# 04-pod-antiaffinity-demo.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: pod-antiaffinity
  labels:
    app: pod-antiaffinity
spec:
  replicas: 3
  selector:
    matchLabels:
      app: pod-antiaffinity
  template:
    metadata:
      labels:
        app: pod-antiaffinity
    spec:
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80
          name: nginxweb
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:  # 硬策略
          - labelSelector: #3个pod副本不会调度到具有app=busybox-pod所在的hostanme这个域(节点)上面
              matchExpressions:
              - key: app
                operator: In
                values:
                - busybox-pod
            topologyKey: kubernetes.io/hostname #注意：pod反亲和性是直接不往这个域里直接调度pod的！！！

这里的意思就是如果一个节点上面有一个 app=busybox-pod 这样的 Pod 的话，那么我们的 Pod 就别调度到这个节点上面来，上面我们把app=busybox-pod 这个 Pod 固定到了 node2 这个节点上面的，所以正常来说我们这里的 Pod 不会出现在该节点上：

$ kubectl apply -f 04-pod-antiaffinity-demo.yaml 
deployment.apps/pod-antiaffinity created
$ kubectl get po -owide
NAME                                READY   STATUS    RESTARTS   AGE   IP             NODE    NOMINATED NODE   READINESS GATES
pod-antiaffinity-57c57dd9f7-jspkt   1/1     Running   0          25s   10.244.1.100   node1   <none>           <none>
pod-antiaffinity-57c57dd9f7-mm78w   1/1     Running   0          25s   10.244.1.99    node1   <none>           <none>
pod-antiaffinity-57c57dd9f7-x9mft   1/1     Running   0          25s   10.244.1.98    node1   <none>           <none>
test-busybox                        1/1     Running   0          55s   10.244.2.232   node2   <none>           <none>

我们可以看到没有被调度到 node2 节点上，因为我们这里使用的是 Pod 反亲和性。

🍀 大家可以思考下，如果这里我们将拓扑域更改成 beta.kubernetes.io/os 会怎么样呢？可以自己去测试下看看。

$ kubectl apply -f 04-pod-antiaffinity-demo.yaml 
deployment.apps/pod-antiaffinity created
$ kubectl get po
NAME                               READY   STATUS    RESTARTS   AGE
pod-antiaffinity-c5fb4db4d-jj5j7   0/1     Pending   0          4s
pod-antiaffinity-c5fb4db4d-xxnhg   0/1     Pending   0          4s
pod-antiaffinity-c5fb4db4d-zkbgp   0/1     Pending   0          4s

实验结束。😘

4、污点与容忍

对于 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 生效，如该节点内正在运行的 Pod 没有对应容忍（Tolerate）设置，则会直接被逐出

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

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

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

🍀 比如现在我们想要将一个 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
        ports:
        - name: http
          containerPort: 80
      tolerations:
      - key: "node-role.kubernetes.io/master"
        operator: "Exists"
        effect: "NoSchedule"

由于 master 节点被标记为了污点，所以我们这里要想 Pod 能够调度到改节点去，就需要增加容忍的声明：

tolerations:
- key: "node-role.kubernetes.io/master"
  operator: "Exists"
  effect: "NoSchedule"

🍀 然后创建上面的资源，查看结果：

➜ kubectl apply -f taint-demo.yaml
deployment.apps "taint" created

➜ kubectl get pods -o wide
NAME                                      READY     STATUS             RESTARTS   AGE       IP             NODE
......
taint-845d8bb4fb-57mhm                    1/1       Running            0          1m        10.244.4.247   node2
taint-845d8bb4fb-bbvmp                    1/1       Running            0          1m        10.244.0.33    master1
taint-845d8bb4fb-zb78x                    1/1       Running            0          1m        10.244.4.246   node2
......

我们可以看到有一个 Pod 副本被调度到了 master 节点，这就是容忍的使用方法。

对于 tolerations 属性的写法，其中的 key、value、effect 与 Node 的 Taint 设置需保持一致， 还有以下几点说明：

  • 如果 operator 的值是 Exists，则 value 属性可省略
  • 如果 operator 的值是 Equal，则表示其 key 与 value 之间的关系是 equal(等于)
  • 如果不指定 operator 属性，则默认值为 Equal

另外，还有两个特殊值：

  • 空的 key 如果再配合 Exists 就能匹配所有的 key 与 value，也就是是能容忍所有节点的所有 Taints

  • 空的 effect 匹配所有的 effect

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

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

实验结束。😘

课后习题

1.不用 DaemonSet，如何使用 Deployment 是否实现同样的功能？

我们知道 DaemonSet 控制器的功能就是在每个节点上运行一个 Pod，如何要使用 Deployment 来实现，首先就要设置副本数量为节点数，比如我们这里加上 master 节点一共3个节点，则要设置3个副本，要在 master 节点上执行自然要添加容忍，那么要如何保证一个节点上只运行一个 Pod 呢？是不是前面的提到的 Pod 反亲和性就可以实现，以自己 Pod 的标签来进行过滤校验即可，新的 Pod 不能运行在一个已经具有该 Pod 的节点上，是不是就是一个节点只能运行一个？

🍀 模拟的资源清单如下所示：

# 06-daemonset-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: mock-ds-demo
spec:
  replicas: 3
  selector:
    matchLabels:
      app: mock-ds-demo
  template:
    metadata:
      labels:
        app: mock-ds-demo
    spec:
      tolerations: #加上容忍，这样才有机会运行在master节点上
      - key: "node-role.kubernetes.io/master"
        operator: "Exists"
        effect: "NoSchedule"
      containers:
      - image: nginx
        name: nginx
        ports:
        - containerPort: 80
          name: ngpt
      affinity:
        podAntiAffinity:  # pod反亲合性
          requiredDuringSchedulingIgnoredDuringExecution:  # 硬策略
          - labelSelector:
              matchExpressions:
              - key: app   # Pod的标签
                operator: In
                values: ["mock-ds-demo"]
            topologyKey: kubernetes.io/hostname  # 以hostname为拓扑域，相当于每一个节点都是一个拓扑域

🍀 创建上面的资源清单验证：

$ kubectl apply -f 06-daemonset-deployment.yaml 
deployment.apps/mock-ds-demo created
$ kubectl get po -owide
NAME                            READY   STATUS    RESTARTS   AGE   IP             NODE      NOMINATED NODE   READINESS GATES
mock-ds-demo-8694759c69-882fx   1/1     Running   0          18s   10.244.0.15    master1   <none>           <none>
mock-ds-demo-8694759c69-frfhx   1/1     Running   0          18s   10.244.1.108   node1     <none>           <none>
mock-ds-demo-8694759c69-p5cjw   1/1     Running   0          18s   10.244.2.235   node2     <none>           <none>

可以看到我们用 Deployment 部署的服务在每个节点上都运行了一个 Pod，实现的效果和 DaemonSet 是一致的。

2.同样的如果想在每个节点（或指定的一些节点）上运行2个（或多个）Pod 副本，如何实现？

DaemonSet 是在每个节点上运行1个 Pod 副本，显然我们去创建2个（或多个）DaemonSet 即可实现该目标，但是这不是一个好的接近方案，而 PodAntiAffinity 只能将一个 Pod 调度到某个拓扑域中去，所以都不能很好的来解决这个问题。

要实现这种更细粒度的控制，我们可以通过设置拓扑分布约束来进行调度，设置拓扑分布约束来将 Pod 分布到不同的拓扑域下，从而实现高可用性或节省成本，具体实现方式请看下文。

关于我

我的博客主旨：我希望每一个人拿着我的博客都可以做出实验现象，先把实验做出来，然后再结合理论知识更深层次去理解技术点，这样学习起来才有乐趣和动力。并且，我的博客内容步骤是很完整的，也分享源码和实验用到的软件，希望能和大家一起共同进步！

各位小伙伴在实际操作过程中如有什么疑问，可随时联系本人免费帮您解决问题：

  1. 个人微信二维码：x2675263825 （舍得）， qq：2675263825。

    image-20211002091450217

  2. 个人博客地址：www.onlyonexl.cn

    image-20211002092057988

  3. 个人微信公众号：云原生架构师实战

    image-20211002141739664

  4. 个人csdn

    https://blog.csdn.net/weixin_39246554?spm=1010.2135.3001.5421

    image-20211002092344616

  5. 个人已开源干货😘

    01 实战：打造一款王者云笔记：typora+坚果云+阿里云oss

    https://www.jianguoyun.com/p/DXS6qiIQvPWVCRiS0qoE
    02 实战：定制宇宙中最美的typora主题皮肤

    https://www.jianguoyun.com/p/DeUK9u0QvPWVCRib0qoE
    03 玩转vscode

    https://www.jianguoyun.com/p/DZe8gmsQvPWVCRid0qoE
    04 陈果的幸福哲学课.md

    https://www.jianguoyun.com/p/Db0kM7gQvPWVCRj2q6YE

  6. x

最后

​ 好了，关于亲和性调度实验就到这里了，感谢大家阅读，最后贴上我女神的photo，祝大家生活快乐，每天都过的有意义哦，我们下期见！

image-20220218164942962

# kubernetes # docker # 容器
Logo
K8S/Kubernetes

K8S/Kubernetes社区为您提供最前沿的新闻资讯和知识内容

更多推荐

【深度】阿里巴巴万级规模 K8s 集群全局高可用体系之美

作者 |  韩堂、柘远、沉醉来源 | 阿里巴巴云原生公众号​前言台湾作家林清玄在接受记者采访的时候，如此评价自己 30 多年写作生涯：“第一个十年我才华横溢，‘贼光闪现’，令周边黯然失色；第二个十年，我终于‘宝光现形’，不再去抢风头，反而与身边的美丽相得益彰；进入第三个十年，繁华落尽见真醇，我进入了‘醇光初现’的阶段，真正体味到了境界之美”。​长夜有穷，真水无香。领略过了 K8s“身在江

avatar K8S/Kubernetes

如何基于 K8s 构建下一代 DevOps 平台？

作者 | 孙健波（天元）导读：当前云原生 DevOps 体系现状如何？面临哪些挑战？如何通过 OAM 解决云原生 DevOps 场景下的诸多问题？云原生开发应用模型 OAM(Open Application Model) 社区核心成员孙健波将为大家一一解答，并分享如何基于 OAM 和 Kubernetes 打造无限能力的下一代 DevOps 平台。什么是 DevOps？为什么基于 Kub

avatar K8S/Kubernetes

k8s 火了！

2020，上云之年，产品云端化成为一种趋势。在一线城市，很多公司都已经构建了自己的私有云环境，比如阿里云、网易云、华为云等。而Kubernetes 作为基于容器编排领域的王者，具备扩展...

avatar K8S/Kubernetes