污点 节点亲和性 容忍度

污点是K8s高级调度的个性，用于限度哪些Pod能够被调度到某一个节点。在一般节点横向时咱们能够应用污点容忍度创立歹意pod来对主节点进行横向管制。

1、kube-scheduler调度

kube-scheduler是Kubernetes 集群的默认调度器，并且是集群管制面(master)的一部分。对每一个新创建的Pod或者是未被调度的Pod，kube-scheduler会抉择一个最优的Node去运行这个Pod。

然而，Pod内的每一个容器对资源都有不同的需要，而且Pod自身也有不同的资源需要。因而，Pod在被调度到Node上之前，依据这些特定的资源调度需要，须要对集群中的Node进行一次过滤。

如下为在创立pod的流程中，调度器的作用：

当创立pod时候，会首先把创立的命令申请提交给apiserver，通过一系列认证受权,apiserver把pod数据存储到etcd,创立deployment资源并初始化。而后再是scheduler通过进行list-watch机制进行监测，通过调度算法把pod调度到某个node节点上，最初信息更新到etcd，再前面就是kubelet承受信息到创立容器。

2、哪些因素影响调度

1.pod资源限度

以后调度器抉择适当的节点时，调度程序会查看每个节点是否有足够的资源满足 Pod 调度，比方查看CPU和内存限度是否满足：

通过资源限度调度程序可确保因为过多 Pod 竞争耗费节点所有可用资源，从而导致节点资源耗尽引起其余零碎异样。

2.节点选择器nodeSelector

在创立pod的时候，节点选择器能够束缚pod在特定节点上运行。

nodeSelector 也是节点抉择束缚的最简略举荐模式，nodeSelector 字段增加到 Pod 的规约中设置心愿指标节点所具备的节点标签。 K8s 只会将 Pod 调度到领有你所指定的每个标签的节点上。

例子， 比方多个节点须要调度时候，通过给1，2节点打上标签，创立pod时候应用节点选择器，那么pod会被依照节点选择器心愿的指标在相应节点调度。

为节点打上标签：

kubectl label node nodename env_role=env

查看节点的标签：

kubectl get nodes nodename --show-labels

3.节点亲和性nodeAffinity

节点亲和性概念上相似于 nodeSelector， 它使能够依据节点上的标签来束缚 Pod 能够调度到哪些节点上，这种办法比下面的nodeSelector更加灵便，它能够进行一些简略的逻辑组合了，不只是简略的相等匹配。

节点亲和性和节点选择器相比性能更弱小，比方还是方才的图，如果我应用节点选择器env_role:dev1的话是找不到相应的节点的，就没有方法调度，会始终是一个期待的状态：

但我如果应用节点亲和性，就算以后没有这个节点，我还是能够依据调度调度策略进行调度，不只是简略的相等匹配。

调度策略

调度能够分成软策略(软亲和性)和硬策略(硬亲和性)两种形式：

  • 软亲和性(preferredDuringSchedulingIgnoredDuringExecution)就是如果你没有满足调度要求的节点的话，POD 就会疏忽这条规定，持续实现调度过程，说白了就是满足条件最好了，没有的话也无所谓了的策略；
  • 硬亲和性(requiredDuringSchedulingIgnoredDuringExecution)示意以后的条件必须满足，如果没有满足条件的节点的话，就一直重试直到满足条件为止，简略说就是你必须满足我的要求，不然我就不干的策略。

如图能够看到软亲和性和硬亲和性的字段其实差不多，软亲和性多了一个weight字段，表权重：

亲和性操作符

如上亲和性还有一个字段是operator表匹配的逻辑操作符，能够应用descirbe命令查看具体的调度状况是否满足咱们的要求，K8s提供的操作符有上面的几种：

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

如果nodeSelectorTerms上面有多个选项的话，满足任何一个条件就能够了；如果matchExpressions有多个选项的话，则必须同时满足这些条件能力失常调度 POD。

污点（Taints）与容忍（tolerations）

容忍度（Toleration）是利用于 Pod 上的，容许（但并不要求）Pod 调度到带有与之匹配的污点的节点上。污点说白了就是不做一般的调度。

对于节点亲和性无论是软亲和性和硬亲和性，都是调度 POD 到预期节点上，而污点(Taints)恰好与之相同，如果一个节点标记为 Taints ，除非 POD 也被标识为能够容忍污点节点，否则该 Taints 节点不会被调度pod。

污点（Taints）

查看污点状况：

kubectl describe node nodename | grep Taint

能够看到，默认污点也只有master有。

污点里的值有三种：

  1. NoSchedule：POD 不会被调度到标记为 taints 节点。
  2. PreferNoSchedule：NoSchedule 的软策略版本。
  3. NoExecute：该选项意味着一旦 Taint 失效，如该节点内正在运行的 POD 没有对应 Tolerate 设置，会间接被逐出。

NoSchedule就是字面意思，不会被调度，PreferNoSchedule说白了是尽量不被调度，NoExecute是不会调度并且还会驱赶node已有的pod。

创立一个pod：

如果不加污点，能够看到这个pod会随机调度到节点1或者节点2：

这时候把pod删除了，从新创立pod并且给node加上污点：

给节点打污点：

kubectl taint node nodename key=value:NoSchedule

从新创立pod并且deployment多个：

能够发现全副被调度在节点2上，节点1的污点NoSchedule起了作用。

删除污点：

污点容忍度（tolerations）

容忍度tolerations是定义在 Pod对象上的键值型属性数据，用于配置其可容忍的节点污点，而且调度器仅能将Pod对象调度至其可能容忍该节点污点的节点之上。

污点定义在节点的node Spec中，而容忍度则定义在Pod的podSpec中，它们都是键值型数据。

在Pod对象上定义容忍度时，它反对两种操作符：一种是等值比拟Equal,示意容忍度与污点必须在key、value和effect三者之上齐全匹配；另一种是存在性判断Exists，示意二者的key和effect必须齐全匹配，而容忍度中的value字段要应用空值。

这里的key和value对应的值都是你本人设置的key和value：

说白了就是：

  • 如果operator是Exists（此时容忍度不能指定 value）
  • 如果operator是Equal，则它们的value应该相等

而污点容忍的作用举个例子，如果像下面污点一样设置了NoSchedule污点的节点，那么创立pod的时候是必不被调度到的，然而如果我应用污点容忍，那这个节点能够在设置NoSchedule污点的状况下可能又被调度，相似于亲和性那种作用。

3、污点横向浸透

污点和污点容忍度的作用也就是获取主节点的shell，因为像常见或者节点shell的流程是创立pod--》调配到失常node---》通过惯例挂载目录拿到节点的shell，而默认主节点是不被调度的，所以只有应用污点容忍度，创立一个可能被调度到master节点的pod，而后通过挂载之类的手法来拿到主节点的shell。

通过创立一个具备node-role.kubernetes.io/master:NoSchedule的容忍度让Pod被Kubernetes Master所调度。

apiVersion: v1kind: Podmetadata:  name: nginx  labels:    env: testspec:  containers:  - name: nginx    image: nginx    imagePullPolicy: IfNotPresent  tolerations:  - key: "node-role.kubernetes.io/master"    operator: "Exists"    effect: "NoSchedule"

如上的Pod中将宿主机的根目录挂载到容器中（volumes与volumeMounts）即可逃逸至Kubernetes Master中接管集群。

查看节点，以后是在一般节点：

屡次创立能够发现在master节点上了：

能够通过挂载操作master节点母机shell: