K8s调度策略

元旦快乐

1

调度

    在K8s中，调度是指将Pod放置到合适的节点上。调度器通过 K8s 的监测机制来发现集群中新创建且尚未被调度到节点上的Pod。 调度器会将所发现的每一个未调度的Pod调度到一个合适的节点上来运行。

kube-scheduler调度器

    kube-scheduler组件是K8s集群的默认调度器，并且是集群控制面的一部分。 对每一个新创建的Pod或者是未被调度的 Pod，kube-scheduler 会选择一个最优的节点去运行这个Pod。 然而，Pod内的每一个容器对资源都有不同的需求，而且Pod本身也有不同的需求。因此，Pod 在被调度到节点上之前，根据这些特定的调度需求，需要对集群中的节点进行一次过滤。在一个集群中满足一个 Pod调度请求的所有节点称之为可调度节点。 如果没有任何一个节点能满足 Pod 的资源请求，那么这个 Pod 将一直停留在未调度状态直到调度器能够找到合适的Node节点。kube-scheduler调度器先在集群中找到一个Pod的所有可调度节点，然后根据一系列函数对这些可调度节点打分，选出其中得分最高的节点来运行 Pod。之后，调度器将这个调度决定通知给 kube-apiserver，这个过程叫做绑定。

    在做调度决定时需要考虑的因素包括：单独和整体的资源请求、硬件/软件/策略限制、 亲和以及反亲和要求、数据局部性、负载间的干扰等等。

kube-scheduler调度流程

    kube-scheduler 给一个 Pod 做调度选择时包含两个步骤：

• 过滤
• 打分

    过滤阶段会将所有满足Pod调度需求的节点选出来。 PodFitsResources 过滤函数会检查候选节点的可用资源能否满足 Pod 的资源请求。 在过滤之后，得出一个节点列表，里面包含了所有可调度节点；通常情况下， 这个节点列表包含不止一个节点。如果这个列表是空的，代表这个 Pod 不可调度。

    在打分阶段，调度器会为 Pod 从所有可调度节点中选取一个最合适的节点。 根据当前启用的打分规则，调度器会给每一个可调度节点进行打分。最后，kube-scheduler 会将 Pod 调度到得分最高的节点上。 如果存在多个得分最高的节点，kube-scheduler 会从中随机选取一个。

    支持以下两种方式配置调度器的过滤和打分行为：

• 调度策略：允许你配置过滤所用的 断言（Predicates） 和打分所用的 优先级（Priorities）。
• 调度配置：允许你配置实现不同调度阶段的插件， 包括：QueueSort、Filter、Score、Bind、Reserve、Permit 等等。 你也可以配置 kube-scheduler 运行不同的配置文件。

2

将Pod分配给指定节点

    可以通过一些手段约束一个Pod以便限制其只能在特定的节点上运行，或优先在特定的节点上运行。有几种方法可以实现这点：

• 节点标签
• 亲和性与反亲和性
• nodeName字段
• Pod拓扑分布约束
• 污点和容忍度

节点标签

    标签（Labels）是附加到 K8s 对象（比如 Pod）上的键值对。 标签旨在用于指定对用户有意义且相关的对象的标识属性，但不直接对核心系统有语义含义。 标签可以用于组织和选择对象的子集。标签可以在创建时附加到对象，随后可以随时添加和修改。 每个对象都可以定义一组键/值标签。每个键对于给定对象必须是唯一的，如下：

"metadata": {
  "labels": {
    "key1" : "value1",
    "key2" : "value2"
  }
}

    与很多其他 K8s 对象类似，节点也有标签(Labels)，也可以手动给节点添加标签。 K8s 也会为集群中所有节点添加一些标准的标签。

给节点添加标签

”

    执行如下命令给指定的k8s-node1节点添加标签 key1=value1。

#给指定的节点打标签
kubectl label nodes k8s-node1 key1=value1
#移除标签
kubectl label nodes k8s-node1 key1-

创建一个将被调度到你选择的节点的 Pod

”

    如下Pod 配置文件描述了一个拥有节点选择器 key1: value1 的 Pod。这表明该 Pod 将被调度到有 key1: value1 标签的节点上。

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    env: test
spec:
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent
  nodeSelector:
    key1: value1

    可以看到该pod确实创建在具有该标签的node节点上。

亲和性和反亲和性

    nodeSelector 提供了一种最简单的方法来将 Pod 约束到具有特定标签的节点上，而亲和性和反亲和性扩展了你可以定义的约束类型。使用亲和性与反亲和性的一些好处有如下：

• 亲和性、反亲和性语言的表达能力更强。nodeSelector 只能选择拥有所有指定标签的节点，而亲和性、反亲和性为你提供对选择逻辑的更强控制能力。
• 你可以标明某规则是“软需求”或者“偏好”，这样调度器在无法找到匹配节点时仍然调度该 Pod。
• 你可以使用节点上（或其他拓扑域中）运行的其他 Pod 的标签来实施调度约束， 而不是只能使用节点本身的标签。这个能力让你能够定义规则允许哪些 Pod 可以被放置在一起。

亲和性功能由两种类型的亲和性组成：

• 节点亲和性功能类似于 nodeSelector 字段，但它的表达能力更强，并且允许你指定软规则。
• Pod 间亲和性、反亲和性允许你根据其他 Pod 的标签来约束 Pod。

节点亲和性

”

    节点亲和性概念上类似于 nodeSelector， 它使你可以根据节点上的标签来约束 Pod 可以调度到哪些节点上。 节点亲和性有两种：

• requiredDuringSchedulingIgnoredDuringExecution： 调度器只有在规则被满足的时候才能执行调度。此功能类似于 nodeSelector， 但其语法表达能力更强。
• preferredDuringSchedulingIgnoredDuringExecution： 调度器会尝试寻找满足对应规则的节点。如果找不到匹配的节点，调度器仍然会调度该 Pod。

    注：在上述类型中，IgnoredDuringExecution 意味着如果节点标签在 Kubernetes 调度 Pod 后发生了变更，Pod 仍将继续运行。

Pod 间亲和性与反亲和性

”

    Pod间亲和性与反亲和性使你可以基于已经在节点上运行的Pod的标签来约束Pod可以调度到的节点，而不是基于节点上的标签。

    Pod间亲和性与反亲和性的规则格式为“如果 X 上已经运行了一个或多个满足规则 Y 的 Pod， 则这个 Pod 应该（或者在反亲和性的情况下不应该）运行在 X 上”。 这里的 X 可以是节点、机架、云提供商可用区或地理区域或类似的拓扑域， Y 则是 K8s 尝试满足的规则。

    你可以通过标签选择算符的形式来表达规则（Y），并可根据需要指定关联的名字空间列表。 Pod 在 K8s 中是名字空间作用域的对象，因此 Pod 的标签也隐式地具有名字空间属性。 针对 Pod 标签的所有标签选择算符都要指定名字空间，K8s 会在指定的名字空间内寻找标签。

    你会通过 topologyKey 来表达拓扑域（X）的概念，其取值是系统用来标示域的节点标签键。

    注：Pod 间亲和性和反亲和性都需要相当的计算量，因此会在大规模集群中显著降低调度速度。 我们不建议在包含数百个节点的集群中使用这类设置。Pod 反亲和性需要节点上存在一致性的标签。换言之， 集群中每个节点都必须拥有与 topologyKey 匹配的标签。 如果某些或者所有节点上不存在所指定的 topologyKey 标签，调度行为可能与预期的不同。

用节点亲和性把Pod分配到节点

”

    执行如下命令给指定的k8s-node1节点添加标签 key1=value1。

#给指定的节点打标签
kubectl label nodes k8s-node1 key1=value1

    下面清单描述了一个 Pod，它有一个节点亲和性配置 requiredDuringSchedulingIgnoredDuringExecution，key1=value1。 这意味着 pod 只会被调度到具有 key1=value1 标签的节点上。

apiVersion: v1
kind: Pod
metadata:
  name: nginx4
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: key1
            operator: In
            values:
            - value1            
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent

    本清单描述了一个Pod，它有一个节点亲和性设置 preferredDuringSchedulingIgnoredDuringExecution，key1=value1。 这意味着 pod 将首选具有 key1=value1 标签的节点。如果没有找到key1=value1 标签的节点，则会随机调度到可用的Node节点上。

apiVersion: v1
kind: Pod
metadata:
  name: nginx5
spec:
  affinity:
    nodeAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 1
        preference:
          matchExpressions:
          - key: key1
            operator: In
            values:
            - value1         
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent

nodeName字段

    可以通过设置 nodeName 将某个 Pod 调度到特定的节点，且该 Pod 将只能被调度到特定节点。

apiVersion: v1
kind: Pod
metadata:
  name: nginx2
spec:
  nodeName: k8s-node2
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent

Pod 拓扑分布约束

    可以使用拓扑分布约束（Topology Spread Constraints）来控制Pod在集群内故障域之间的分布，故障域的示例有区域（Region）、可用区（Zone）、节点和其他用户自定义的拓扑域。这样做有助于提升性能、实现高可用或提升资源利用率。详细：Pod 拓扑分布约束：https://kubernetes.io/zh-cn/docs/concepts/scheduling-eviction/topology-spread-constraints/

污点(Taint)和容忍度(Toleration)

    节点亲和性是Pod的一种属性，它使Pod被吸引到一类特定的节点（这可能是出于一种偏好，也可能是硬性要求）。 而污点（Taint）则相反，污点(Taint)是应用在Node节点之上的它使节点能够排斥一类特定的Pod，具有污点Taint的node和pod是互斥关系；而容忍度（Toleration）是应用于 Pod 上的，容忍度允许(但不要求)调度器调度带有对容忍度的Pod到Node节点上，污点和容忍度的目的是优化pod在集群间的调度。作为其功能的一部分， 调度器也会评估其他参数。

    污点和容忍度（Toleration）相互配合，可以用来避免 Pod 被分配到不合适的节点上。 每个节点上都可以应用一个或多个污点，这表示对于那些不能容忍这些污点的 Pod， 是不会被该节点接受的。

给Node节点打污点

”

    给节点k8s-master增加一个污点，它的键名是key1，键值是value1，效果是NoSchedule。 这表示只有拥有和这个污点相匹配的容忍度的 Pod 才有可能够被分配到k8s-node1这个节点上。

#查看节点信息
kubectl describe node k8s-node1
#添加污点
kubectl taint nodes k8s-node1 key1=value1:NoSchedule
#移除污点
kubectl taint nodes k8s-node1 key1=value1:NoSchedule-

在pod中定义容忍度

”

    可以在 PodSpec 中定义 Pod 的容忍度。下面两个容忍度均与上面例子中使用kubectl taint命令创建的污点相匹配， 因此如果一个 Pod 拥有其中的任何一个容忍度都可能能够被分配到node1：

tolerations:
- key: "key1"
  operator: "Equal"
  value: "value1"
  effect: "NoSchedule"

或

tolerations:
- key: "key1"
  operator: "Exists"
  effect: "NoSchedule"

实例

apiVersion: v1
kind: Pod
metadata:
  name: myapp
  labels:
    env: test
spec:
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent
  tolerations:
  - key: "key1"
    operator: "Exists"
    effect: "NoSchedule"

    一个容忍度和一个污点相“匹配”是指它们有一样的键名和效果。

operator 的参数含义：

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

    注：如果一个容忍度的 key 为空且 operator 为 Exists， 表示这个容忍度与任意的 key、value 和 effect 都匹配，即这个容忍度能容忍任何污点。

effect 的参数含义：

• 如果effect是NoSchedule，则新的不能容忍的pod不能再调度过来，但是之前运行在node节点中的Pod不受影响。
• 如果effect是NoExecute，则新的不能容忍的pod不能调度过来，老的pod也会被驱逐。
• 如果effect是PreferNoScheduler，则表示尽量不调度到污点节点中去。

注：如果 effect 为空，则可以与所有键名 key1 的效果相匹配。

多个污点的匹配规则

”

    可以给一个节点添加多个污点，也可以给一个Pod添加多个容忍度。 K8s处理多个污点和容忍度的过程就像一个过滤器：从一个节点的所有污点开始遍历， 过滤掉那些 Pod 中存在与之相匹配的容忍度的污点。余下未被过滤的污点的effect 值决定了 Pod 是否会被分配到该节点，特别是以下情况：

• 如果未被过滤的污点中存在至少一个effect值为NoSchedule的污点， 则 Kubernetes 不会将Pod分配到该节点。
• 如果未被过滤的污点中不存在 effect 值为NoSchedule的污点， 但是存在 effect 值为PreferNoSchedule的污点， 则 Kubernetes 会尝试不将 Pod 分配到该节点。
• 如果未被过滤的污点中存在至少一个 effect 值为NoExecute 的污点， 则 Kubernetes 不会将 Pod 分配到该节点（如果 Pod 还未在节点上运行）， 或者将 Pod 从该节点驱逐（如果 Pod 已经在节点上运行）。

    例如，假设您给一个节点添加了如下污点：

kubectl taint nodes node1 key1=value1:NoSchedule
kubectl taint nodes node1 key1=value1:NoExecute
kubectl taint nodes node1 key2=value2:NoSchedule

假定有一个 Pod，它有两个容忍度：

tolerations:
- key: "key1"
  operator: "Equal"
  value: "value1"
  effect: "NoSchedule"
- key: "key1"
  operator: "Equal"
  value: "value1"
  effect: "NoExecute"

    上述 Pod 不会被分配到 node1 节点，因为其没有容忍度和第三个污点相匹配。 

    但是如果在给节点添加上述污点之前，该 Pod 已经在上述节点运行， 那么它还可以继续运行在该节点上，因为第三个污点是三个污点中唯一不能被这个 Pod 容忍的。

    通常情况下，如果给一个节点添加了一个 effect 值为 NoExecute 的污点， 则任何不能忍受这个污点的 Pod 都会马上被驱逐，任何可以忍受这个污点的 Pod 都不会被驱逐。 但是，如果 Pod 存在一个 effect 值为 NoExecute 的容忍度指定了可选属性tolerationSeconds 的值，则表示在给节点添加了上述污点之后， Pod 还能继续在节点上运行的时间。例如：

tolerations:
- key: "key1"
  operator: "Equal"
  value: "value1"
  effect: "NoExecute"
  tolerationSeconds: 3600

    这表示如果这个 Pod 正在运行，同时一个匹配的污点被添加到其所在的节点， 那么 Pod 还将继续在节点上运行 3600 秒，然后被驱逐。 如果在此之前上述污点被删除了，则 Pod 不会被驱逐。

说明

• 默认情况下，只有master节点会有污点(role.kubernetes.io/master:NoSchedule)，Node节点默认没有污点。这也是为什么默认情况下Pod不会被分配到master节点的原因。
• 当只有一个节点没污点，其他节点都有污点时，创建pod的yml文件的容忍度没匹配上所有的污点时，创建的pod节点在没有污点的节点上。
• 当只有一个节点没污点，其他节点都有污点时，创建pod的yml文件的容忍度匹配上污点时，创建的pod节点也在没有污点的节点上。
• 当所有node的节点都有污点，创建pod的yml文件的容忍度能匹配上污点时，创建的pod节点在匹配的污点的节点上。
• 当所有node节点都有污点，但是创建pod的yml文件的容忍度没匹配上所有的污点时，创建的pod节点的NODE这里为空。

3

给master节点分配pod

    默认情况下创建的pod是不会被分配到master节点上的，因为master节点默认被打上了node-role.kubernetes.io/master:NoSchedule的污点。

#查询k8s-master节点的Taints
kubectl describe node k8s-master | grep Taints
#取消污点
kubectl taint nodes k8s-master role.kubernetes.io/master:NoSchedule-

注：其实也可以省略取消master节点污点这一步。

然后使用nodeName字段指定k8s-master

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  nodeName: k8s-master
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent

END

    非常感谢您读到现在，由于作者的水平有限，编写时间仓促，文章中难免会出现一些错误或者描述不准确的地方，恳请各位师傅们批评指正。

    如果你想一起学习内网渗透、域渗透、云安全、红队攻防的话，可以加入下面的知识星球一起学习交流。

参考：

将 Pod 指派给节点：https://kubernetes.io/zh-cn/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity

污点和容忍度：https://kubernetes.io/zh-cn/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity

k8s 的污点（Taint）和容忍度（Toleration）：https://zhuanlan.zhihu.com/p/405348246