影响K8S Pod分配和调度策略的两大关键特性

在Kubernetes中有一个最复杂的调度器可以处理pod的分配策略。基于在pod规范中所提及的资源需求,Kubernetes调度器会自动选择最合适的节点来运行pod。

但在许多实际场景下,我们必须干预调度过程才能在pod和一个节点或两个特定pod之间进行匹配。因此,Kubernetes中有一种十分强大的机制来管理及控制pod的分配逻辑。

那么,本文将探索影响Kubernetes中默认调度决定的关键特性。

节点亲和性/反亲和性

Kubernetes一向以来都是依赖label和selector来对资源进行分组。例如,某服务使用selector来过滤具有特定label的pod,这些label可以选择性地接收流量。Label和selector可以使用简单的基于等式的条件( =and!= )来评估规则。通过nodeSelector的特性(即强制将pod调度到特定节点上),可以将这一技术扩展到节点中。

此外,label和selector开始支持基于集合的query,它带来了基于 innotinexist 运算符的高级过滤技术。与基于等式的需求相结合,基于集合的需求提供了复杂的技术来过滤Kubernetes中的资源。

节点亲和性/反亲和性使用label和annotation的基于表达集的过滤技术来定义特定节点上的pod的分配逻辑。Annotation可以提供不会暴露到selector的其他元数据,这意味着用于annotation的键不会包含在query和过滤资源中。但是节点亲和性可以在表达式中使用annotation。反亲和性可以确保pod不会被强制调度到与规则匹配的节点上。

除了能够在query中使用复杂的逻辑之外,节点亲和性/反亲和性能够为分配逻辑强制施加硬性和软性规则。硬性规则将会执行严格的策略,可能会阻止将pod分配到不符合条件的节点上。而软性规则则会首先确认节点是否与特定的条件相匹配,如果它们不匹配,它将使用默认的调度模式来分配Pod。表达式 requiredDuringSchedulingIgnoredDuringExecutionpreferredDuringSchedulingIgnoredDuringExecution 将会分别执行硬性规则和软性规则。

以下是在硬性和软性规则下使用节点亲和性/反亲和性的示例:

affinity:

nodeAffinity:

preferredDuringSchedulingIgnoredDuringExecution:

nodeSelectorTerms:

- matchExpressions:

- key: "failure-domain.beta.kubernetes.io/zone"

operator: In

values: ["asia-south1-a"]

以上规则将指示Kubernetes调度器尝试将Pod分配到在GKE集群的 asia-south1-a 区域中运行的节点上。如果没有可用的节点,则调度器将会直接应用标准的分配逻辑。

affinity:

nodeAffinity:

requiredDuringSchedulingIgnoredDuringExecution:

nodeSelectorTerms:

- matchExpressions:

- key: "failure-domain.beta.kubernetes.io/zone"

operator: NotIn

values: ["asia-south1-a"]

以上规则通过使用 NotIn 运算符来强制执行反亲和性。这是一个硬性规则,它能够确保没有pod被分配到运行在 asia-south1-a 空间中的GKE节点。

Pod亲和性/反亲和性

尽管节点亲和性/反亲和性能够处理pod和节点之间的匹配,但是有些场景下我们需要确保pod在一起运行或在相同的节点上不运行2个pod。Pod亲和性/反亲和性将帮助我们应用强制实施粒度分配逻辑。

与节点亲和性/反亲和性中的表达式类似,pod亲和性/反亲和性也能够通过 requiredDuringSchedulingIgnoredDuringExecutionpreferredDuringSchedulingIgnoredDuringExecution 强制实施硬性以及软性规则。还可以将节点亲和性与pod亲和性进行混合和匹配,以定义复杂的分配逻辑。

为了能够更好地理解概念,想象一下我们有一个web和缓存deployment,其中三个副本在一个3节点的集群中运行。为了确保在web和缓存pod之间低延迟,我们想要在用一个节点上运行它们。与此同时,我们不想在相同的节点上运行超过1个缓存pod。基于此情况,我们需要实施以下策略:每个节点仅运行1个且只有1个缓存Pod的web pod。

首先,我们将使用反亲和性规则来部署缓存,它将阻止超过1个pod运行在1个节点上:

affinity:

podAntiAffinity:

requiredDuringSchedulingIgnoredDuringExecution:

- labelSelector:

matchExpressions:

- key: app

operator: In

values:

- redis

topologyKey: "kubernetes.io/hostname"

topoloyKey 使用附加到节点的默认label动态过滤节点的名称。请注意,我们使用 podAntiAffinity 表达式和 in 运算符来应用规则的方式。

假设在集群的某个节点上安排了3个pod缓存,那么现在我们想要在与缓存Pod相同的节点上部署web pod。我们将使用 podAffinity 来实施这一逻辑:

podAffinity:

requiredDuringSchedulingIgnoredDuringExecution:

- labelSelector:

matchExpressions:

- key: app

operator: In

values:

- redis

topologyKey: "kubernetes.io/hostname"

以上代码表明Kubernetes调度器要寻找有缓存Pod的节点并部署web pod。

除了节点和pod的亲和性/反亲和性之外,我们还能使用taints和tolerations来定义自定义分配逻辑。此外,我们还能写自定义调度程序,它可以从默认的调度程序中接管调度逻辑。

推荐阅读

5大基本技巧!助你在生产上顺利部署K8S Pod

你不得不了解Helm 3中的5个关键新特性

开箱即用!使用Rancher 2.3 启用Istio初体验

About Rancher Labs

Rancher Labs由CloudStack之父梁胜创建。旗舰产品Rancher是一个开源的企业级Kubernetes管理平台,实现了Kubernetes集群在混合云+本地数据中心的集中部署与管理。Rancher一向因操作体验的直观、极简备受用户青睐,被Forrester评为2018年全球容器管理平台领导厂商,被Gartner评为2017年全球最酷的云基础设施供应商。

目前Rancher在全球拥有超过一亿的下载量,并拥有包括中国人寿、华为、中国平安、兴业银行、民生银行、平安证券、海航科技、厦门航空、上汽集团、海尔、米其林、丰田、本田、中船重工、中联重科、迪斯尼、IBM、Cisco、Nvidia、辉瑞制药、西门子、CCTV、中国联通等全球著名企业在内的共40000家企业客户。

Rancher北上深沈阳火热招聘中!

↓↓↓

我来评几句
登录后评论

已发表评论数()

相关站点

+订阅
热门文章