首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

理解 Kubernetes 的亲和性调度

(图片来源:https://unsplash.com/photos/UhagOo7IOyc)

一般情况下我们部署的 POD 是通过集群自动调度选择某个节点的,默认情况下调度器考虑的是资源足够,并且负载尽量平均,但是有的时候我们需要能够更加细粒度的去控制 POD 的调度,比如我们内部的一些服务 gitlab 之类的也是跑在集群上的,我们就不希望对外的一些服务和内部的服务跑在同一个节点上了,害怕内部服务对外部的服务产生影响;有的时候呢我们两个服务直接交流比较频繁,又希望能够将这两个服务的 POD 调度到同样的节点上。这就需要用到 Kubernetes 里面的一个概念:亲和性,亲和性主要分为两类:和。

nodeSelector

我们知道是中一个非常重要的概念,用户可以非常灵活的利用 label 来管理集群中的资源,比如最常见的一个就是 service 通过匹配 label 去选择 POD 的。而 POD 的调度也可以根据节点的 label 进行特定的部署。

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

现在我们先给节点192.168.1.140增加一个的标签,命令如下:

我们可以通过上面的参数可以查看上述标签是否生效。当 node 被打上了相关标签后,在调度的时候就可以使用这些标签了,只需要在 POD 的 spec 字段中添加字段,里面是我们需要被调度的节点的 label。例如,下面是我们之前的一个默认的 busybox POD 的 YAML 文件:

然后我需要让上面的 POD 被调度到140的节点上,那么最简单的方法就是去匹配140上面的 label,如下:

然后我们可以通过 describe 命令查看调度结果:

我们可以看到 Events 下面的信息,上面的 POD 被正确的调度到了140节点。通过上面的例子我们可以感受到的方式比较直观,但是还够灵活,控制粒度偏大,下面我们再看另外一种更加灵活的方式:。

nodeAffinity

就是节点亲和性,相对应的是,就是反亲和性,这种方法比上面的更加灵活,它可以进行一些简单的逻辑组合了,不只是简单的相等匹配。

调度可以分成软策略和硬策略两种方式,软策略就是如果你没有满足调度要求的节点的话,POD 就会忽略这条规则,继续完成调度过程,说白了就是满足条件最好了,没有的话也无所谓了的策略;而硬策略就比较强硬了,如果没有满足条件的节点的话,就不断重试直到满足条件为止,简单说就是你必须满足我的要求,不然我就不干的策略。

就有两上面两种策略:和,前面的就是软策略,后面的就是硬策略。

如下例子:(test-node-affinity.yaml

上面这个 POD 首先是要求 POD 不能运行在140和161两个节点上,如果有个节点满足的话就优先调度到这个节点上,同样的我们可以使用命令查看具体的调度情况是否满足我们的要求。这里的匹配逻辑是 label 的值在某个列表中,现在提供的操作符有下面的几种:

In:label 的值在某个列表中

NotIn:label 的值不在某个列表中

Gt:label 的值大于某个值

Lt:label 的值小于某个值

Exists:某个 label 存在

DoesNotExist:某个 label 不存在

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

podAffinity

上面两种方式都是让 POD 去选择节点的,有的时候我们也希望能够根据 POD 之间的关系进行调度,在1.4版本引入的概念就可以实现我们这个需求。

和类似,也有和 两种调度策略,唯一不同的是如果要使用互斥性,我们需要使用字段。

如下例子,我们希望和能够就近部署,而不希望和部署在同一个拓扑域下面:(test-pod-affinity.yaml

上面这个例子中的 POD 需要调度到某个指定的主机上,至少有一个节点上运行了这样的 POD:这个 POD 有一个的 label。则是希望最好不要调度到这样的节点:这个节点上运行了某个 POD,而这个 POD 有的 label。根据前面两个 POD 的定义,我们可以预见上面这个 POD 应该会被调度到140的节点上,因为被调度到了140节点,而被调度到了140以为的节点,正好满足上面的需求。通过查看:

上面的事件信息也验证了我们的想法。

在和 的同级,还可以定义 namespaces 列表,表示匹配哪些 namespace 里面的 pod,默认情况下,会匹配定义的 pod 所在的 namespace;如果定义了这个字段,但是它的值为空,则匹配所有的 namespaces。

查看上面我们定义的3个 POD 结果:

污点(Taints)与容忍(tolerations)

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

比如用户希望把 Master 节点保留给 Kubernetes 系统组件使用,或者把一组具有特殊资源预留给某些 POD,则污点就很有用了,POD 不会再被调度到 taint 标记过的节点。taint 标记节点举例如下:

如果仍然希望某个 POD 调度到 taint 节点上,则必须在 Spec 中做出定义,才能调度到该节点,举例如下:

effect 共有三个可选项,可按实际需求进行设置:

:POD 不会被调度到标记为 taints 节点。

:NoSchedule 的软策略版本。

:该选项意味着一旦 Taint 生效,如该节点内正在运行的 POD 没有对应 Tolerate 设置,会直接被逐出。

  • 发表于:
  • 原文链接http://kuaibao.qq.com/s/20180308A10R4J00?refer=cp_1026
  • 腾讯「腾讯云开发者社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 cloudcommunity@tencent.com 删除。

扫码

添加站长 进交流群

领取专属 10元无门槛券

私享最新 技术干货

扫码加入开发者社群
领券