您的位置:  首页 > 技术杂谈 > 正文

K8s污点容忍度横向主节点

2022-06-16 13:00 https://my.oschina.net/u/5034704/blog/5540446 火线安全平台 次阅读 条评论

污点 节点亲和性 容忍度

污点是K8s高级调度的特性,用于限制哪些Pod可以被调度到某一个节点。在普通节点横向时我们可以使用污点容忍度创建恶意pod来对主节点进行横向控制。

1、kube-scheduler调度

kube-schedulerKubernetes 集群的默认调度器,并且是集群控制面(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接受信息到创建容器。

1654856204-730990-image

2、哪些因素影响调度

1.pod资源限制

当前调度器选择适当的节点时,调度程序会检查每个节点是否有足够的资源满足 Pod 调度,比如查看CPU和内存限制是否满足:

1654856218-318825-image

通过资源限制调度程序可确保由于过多 Pod 竞争消耗节点所有可用资源,从而导致节点资源耗尽引起其他系统异常。

2.节点选择器nodeSelector

在创建pod的时候,节点选择器可以约束pod在特定节点上运行。

nodeSelector 也是节点选择约束的最简单推荐形式,nodeSelector 字段添加到 Pod 的规约中设置希望目标节点所具有的节点标签。 K8s 只会将 Pod 调度到拥有你所指定的每个标签的节点上。 1654856233-741326-image

例子, 比如多个节点需要调度时候,通过给1,2节点打上标签,创建pod时候使用节点选择器,那么pod会被按照节点选择器希望的目标在相应节点调度。

1654856242-986859-image

为节点打上标签:

kubectl label node nodename env_role=env

1654856276-99065-image

查看节点的标签:

kubectl get nodes nodename --show-labels

1654856290-523756-image

3.节点亲和性nodeAffinity

节点亲和性概念上类似于 nodeSelector, 它使可以根据节点上的标签来约束 Pod 可以调度到哪些节点上,这种方法比上面的nodeSelector更加灵活,它可以进行一些简单的逻辑组合了,不只是简单的相等匹配。

1654856307-694417-image

节点亲和性和节点选择器相比功能更强大,比如还是刚才的图,如果我使用节点选择器env_role:dev1的话是找不到相应的节点的,就没有办法调度,会一直是一个等待的状态:

1654856328-413659-image

但我如果使用节点亲和性,就算当前没有这个节点,我还是可以根据调度调度策略进行调度,不只是简单的相等匹配。

调度策略

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

  • 软亲和性(preferredDuringSchedulingIgnoredDuringExecution)就是如果你没有满足调度要求的节点的话,POD 就会忽略这条规则,继续完成调度过程,说白了就是满足条件最好了,没有的话也无所谓了的策略;

  • 硬亲和性(requiredDuringSchedulingIgnoredDuringExecution)表示当前的条件必须满足,如果没有满足条件的节点的话,就不断重试直到满足条件为止,简单说就是你必须满足我的要求,不然我就不干的策略。

如图可以看到软亲和性和硬亲和性的字段其实差不多,软亲和性多了一个weight字段,表权重:

1654856351-643531-image

亲和性操作符

如上亲和性还有一个字段是operator表匹配的逻辑操作符,可以使用descirbe命令查看具体的调度情况是否满足我们的要求,K8s提供的操作符有下面的几种:

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

如果nodeSelectorTerms下面有多个选项的话,满足任何一个条件就可以了;如果matchExpressions有多个选项的话,则必须同时满足这些条件才能正常调度 POD。 1654856373-652246-image

污点(Taints)与容忍(tolerations)

容忍度(Toleration)是应用于 Pod 上的,允许(但并不要求)Pod 调度到带有与之匹配的污点的节点上。污点说白了就是不做普通的调度。

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

污点(Taints)

查看污点情况:

kubectl describe node nodename | grep Taint

1654856395-837128-image

可以看到,默认污点也只有master有。

污点里的值有三种:

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

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

创建一个pod:

1654856431-844199-image

如果不加污点,可以看到这个pod会随机调度到节点1或者节点2:

1654856446-355374-image

这时候把pod删除了,重新创建pod并且给node加上污点:

给节点打污点:

kubectl taint node nodename key=value:NoSchedule 1654856459-579523-image

重新创建pod并且deployment多个: 1654856471-14659-image

可以发现全部被调度在节点2上,节点1的污点NoSchedule起了作用。

删除污点:

1654856483-233145-image

污点容忍度(tolerations)

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

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

Pod对象上定义容忍度时,它支持两种操作符:一种是等值比较Equal,表示容忍度与污点必须在keyvalueeffect三者之上完全匹配;另一种是存在性判断Exists,表示二者的keyeffect必须完全匹配,而容忍度中的value字段要使用空值。

这里的key和value对应的值都是你自己设置的key和value:

1654856493-926957-image

说白了就是:

  • 如果operatorExists(此时容忍度不能指定 value)
  • 如果operatorEqual,则它们的value应该相等

而污点容忍的作用举个例子,如果像上面污点一样设置了NoSchedule污点的节点,那么创建pod的时候是必不被调度到的,但是如果我使用污点容忍,那这个节点可以在设置NoSchedule污点的情况下可能又被调度,类似于亲和性那种作用。

3、污点横向渗透

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

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

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    env: test
spec:
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent
  tolerations:
  - key: "node-role.kubernetes.io/master"
    operator: "Exists"
    effect: "NoSchedule"

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

查看节点,当前是在普通节点:

1654856509-944193-image

多次创建可以发现在master节点上了: 1654856523-204282-image

可以通过挂载操作master节点母机shell:

1654856535-594334-image

展开阅读全文
  • 0
    感动
  • 0
    路过
  • 0
    高兴
  • 0
    难过
  • 0
    搞笑
  • 0
    无聊
  • 0
    愤怒
  • 0
    同情
热度排行
友情链接