K8s 调度器（Scheduler）高级定制与优化：实现复杂业务调度需求

K8s 调度器：你的应用，我来安排！(高级定制与优化，复杂业务需求攻略)

大家好！我是你们的老朋友，代码界的段子手，今天咱们聊点硬核的——K8s 调度器！ 🚀 别害怕，虽然名字听起来像个高冷的霸道总裁，但其实它就是个勤勤恳恳的“老妈子”，负责帮你把应用安排得妥妥当当，舒舒服服地住进 K8s 这个大House里。

但是！ “老妈子”也有自己的脾气，默认的调度方式可能满足不了你花样百出的业务需求。这时候，就需要我们这些 “程序猿老爸” 们出手，定制和优化它，让它更好地为你服务！ 💪

一、默认调度器：入门必修课，摸清底细是关键！

在深入高级定制之前，先得摸清默认调度器的底细。就像追女神，你得先知道人家喜欢吃啥，讨厌啥，才能对症下药嘛！ 😜

K8s 默认调度器（kube-scheduler）的核心职责就是“将 Pod 绑定到最合适的 Node 上”。它的工作流程可以简单概括为：

过滤（Filtering）： 筛选出满足 Pod 资源需求、端口需求、亲和性/反亲和性等条件的 Node。想象一下，这就像一个严格的相亲节目，不符合条件的直接pass！ 🙅‍♂️
打分（Scoring）： 对通过过滤的 Node 进行打分，综合考虑资源利用率、节点亲和性、拓扑分布等因素。这就像评委给相亲对象打分，分数越高，越有可能牵手成功！ 💯
选择（Selecting）： 选择得分最高的 Node，将 Pod 绑定到该 Node 上。恭喜！成功牵手，入住新家！ 🎉

默认调度器背后有一套复杂的算法，涉及多个预选策略（Predicates）和优选策略（Priorities）。我们可以通过 kubectl describe pod <pod_name> 命令查看 Pod 的调度决策过程，了解调度器是如何“选妃”的。

二、高级定制：解锁你的专属 “老妈子”！

默认调度器虽然够用，但总有那么些时候，你需要它更懂你！比如：

特殊的硬件需求： 你的应用需要 GPU、SSD 等特殊硬件，而默认调度器可能不够敏感。
复杂的拓扑约束： 你希望应用尽可能地分布在不同的可用区，或者集中在某些特定的机房。
自定义的业务逻辑： 你可能需要根据应用的版本、优先级等因素，进行更加精细的调度。

这时候，就需要高级定制来拯救你！ K8s 提供了多种方式来定制调度器，让你可以打造一个专属的 “老妈子”，更好地服务你的应用。

1. Node Affinity 和 Pod Affinity/Anti-Affinity：让爱更浓烈，让恨更分明！

Node Affinity (节点亲和性)： 让 Pod 倾向于调度到满足特定标签的 Node 上。就像找对象，你喜欢高个子的，就设置一个 “身高=高” 的标签，让 Pod 优先选择符合条件的 Node。
- requiredDuringSchedulingIgnoredDuringExecution: 必须满足，否则Pod无法调度。就像结婚，必须领证！ 💍
- preferredDuringSchedulingIgnoredDuringExecution: 尽量满足，但不强制。就像谈恋爱，尽量送花，没送也没关系。 💐
```
apiVersion: v1
kind: Pod
metadata:
  name: node-affinity-example
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: node-type
            operator: In
            values:
            - gpu-node  # 只调度到拥有 `node-type=gpu-node` 标签的 Node 上
  containers:
  - name: my-container
    image: nginx
```

Pod Affinity/Anti-Affinity (Pod 亲和性/反亲和性)： 让 Pod 倾向于和某些 Pod 部署在一起，或者避免和某些 Pod 部署在一起。就像室友关系，你希望和爱干净的人住一起（亲和性），避免和打呼噜的人住一起（反亲和性）。

apiVersion: v1
kind: Pod
metadata:
  name: pod-affinity-example
  labels:
    app: my-app
spec:
  affinity:
    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        - labelSelector:
            matchExpressions:
            - key: app
              operator: In
              values:
              - my-app # 调度到拥有 `app=my-app` 标签的 Pod 所在的 Node 上
          topologyKey: kubernetes.io/hostname # 基于 hostname 进行亲和性调度
  containers:
  - name: my-container
    image: nginx

2. Taints 和 Tolerations：我的地盘我做主，想来先交“保护费”！

Taints 和 Tolerations 就像给 Node 贴上“标签”，并设置“准入条件”。 Node 可以被打上 Taint，表示“不受欢迎”，Pod 必须具有相应的 Toleration 才能被调度到该 Node 上。想象一下，这就像一个私人会所，不是会员不让进！ 🙅‍♀️

Taint: Node 的属性，表示Node的“排斥性”，只有拥有对应Toleration的Pod才能调度到该Node上。
Toleration: Pod的属性，表示Pod对某些Taint的“容忍度”，允许Pod调度到带有对应Taint的Node上。
```
# 给 Node 打 Taint：
kubectl taint nodes <node_name> special=true:NoSchedule

# Pod 声明 Toleration：
apiVersion: v1
kind: Pod
metadata:
  name: toleration-example
spec:
  tolerations:
  - key: "special"
    operator: "Equal"
    value: "true"
    effect: "NoSchedule"
  containers:
  - name: my-container
    image: nginx
```
- effect: 指定 Taint 的影响。
  - NoSchedule: 不允许新的 Pod 调度到该 Node 上，除非 Pod 具有相应的 Toleration。
  - PreferNoSchedule: 尽量避免新的 Pod 调度到该 Node 上，即使 Pod 具有相应的 Toleration。
  - NoExecute: 会驱逐该 Node 上已经存在的，没有相应 Toleration 的 Pod。

3. Pod Topology Spread Constraints：雨露均沾，分散风险！

Pod Topology Spread Constraints 可以让你控制 Pod 在不同拓扑域（如 Node、可用区、区域）上的分布。想象一下，这就像撒芝麻，你想把芝麻均匀地撒在馒头上，而不是全部堆在一个地方。 🍞

```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: topology-spread-example
spec:
  replicas: 6
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-container
        image: nginx
      topologySpreadConstraints:
      - maxSkew: 1  # 允许的最大偏差
        topologyKey: kubernetes.io/hostname # 基于 hostname 进行分布
        whenUnsatisfiable: DoNotSchedule # 如果无法满足约束，则不调度
        labelSelector:
          matchLabels:
            app: my-app
```

*   `maxSkew`:  允许的最大偏差。 比如 `maxSkew: 1` 表示，在任何给定的拓扑域中，Pod 的数量最多只能比其他拓扑域多一个。
*   `topologyKey`:  指定拓扑域。 比如 `kubernetes.io/hostname` 表示基于 Node 的 hostname 进行分布。
*   `whenUnsatisfiable`:  指定当无法满足约束时的处理方式。
    *   `DoNotSchedule`:  不调度 Pod。
    *   `ScheduleAnyway`:  仍然调度 Pod，但不保证满足约束。

4. Custom Scheduler：终极武器，打造你的专属“变形金刚”！

如果你对默认调度器的所有策略都不满意，或者需要实现非常复杂的业务逻辑，那么你可以选择自定义调度器！这就像打造一个专属的“变形金刚”，完全按照你的意愿来调度 Pod。 🤖

编写调度器代码： 你需要编写一个独立的程序，监听 K8s API Server，获取待调度的 Pod 和 Node 信息，并根据你的自定义算法进行调度。
注册调度器： 你需要在 K8s 中注册你的自定义调度器，让 K8s 知道它的存在。
配置 Pod 使用自定义调度器： 你需要在 Pod 的 spec.schedulerName 字段中指定你的自定义调度器的名称。

自定义调度器虽然强大，但也需要花费大量的时间和精力进行开发和维护。建议在确实需要非常特殊的调度逻辑时，再考虑使用这种方式。

三、调度器优化：让你的 “老妈子” 跑得更快，更稳！

定制了调度器，并不意味着万事大吉。还需要进行优化，让它跑得更快，更稳，更好地服务你的应用。

1. 资源预留（Resource Reservation）：未雨绸缪，防患于未然！

资源预留可以保证关键应用能够获得足够的资源，避免因为资源竞争而导致性能下降。就像提前预定餐厅，保证你能够有座位吃饭，而不是到了门口才发现没位置了。 🍽️

你可以使用 LimitRange 和 ResourceQuota 来实现资源预留。

LimitRange: 限制 Pod 和 Container 的资源使用范围。
ResourceQuota: 限制 Namespace 的资源使用总量。

2. 优先级和抢占（Priority and Preemption）：让 “VIP” 享受特权！

你可以为 Pod 设置优先级，让高优先级的 Pod 优先被调度，甚至可以抢占低优先级 Pod 的资源。就像机场的 VIP 通道，让重要人物优先登机。 ✈️

PriorityClass: 定义 Pod 的优先级。
preemptionPolicy: 指定当高优先级 Pod 无法调度时，是否可以抢占低优先级 Pod 的资源。

3. 调整调度器参数：精雕细琢，追求极致！

K8s 调度器提供了大量的参数，可以让你根据实际情况进行调整，优化调度性能。比如：

--kube-api-qps: 控制调度器与 API Server 的交互频率。
--leader-elect: 启用 Leader Election，保证只有一个调度器实例在运行。
--algorithm-provider: 选择不同的调度算法。

四、案例分析：实战演练，融会贯通！

光说不练假把式，咱们来个案例分析，看看如何将这些高级定制和优化技巧应用到实际场景中。

案例：GPU 资源调度

假设你有一个深度学习应用，需要使用 GPU 资源进行训练。你需要确保：

只有拥有 GPU 的 Node 才能运行该应用。
尽可能地将多个 GPU 应用调度到不同的 Node 上，避免资源争用。
为 GPU 应用预留足够的资源，保证训练性能。

解决方案：

Node Affinity: 给拥有 GPU 的 Node 打上 gpu=true 的标签，并在 Pod 的 nodeAffinity 中指定 gpu=true。
Pod Anti-Affinity: 使用 podAntiAffinity，基于 kubernetes.io/hostname 拓扑域，避免将多个 GPU 应用调度到同一个 Node 上。
Resource Reservation: 使用 LimitRange 和 ResourceQuota，为 GPU 应用预留足够的 CPU 和 GPU 资源。

五、总结：掌握 “葵花宝典”，纵横 K8s 世界！

K8s 调度器是 K8s 集群的核心组件之一，掌握其高级定制和优化技巧，可以让你更好地管理和调度应用，提高资源利用率，提升应用性能。希望今天的分享能够帮助你解锁 K8s 调度器的 “葵花宝典”，在 K8s 世界里纵横驰骋！ ⚔️

表格：调度器定制方法对比

方法	优点	缺点	适用场景
Node Affinity/Anti-Affinity	简单易用，配置灵活，可以根据标签进行调度。	功能相对简单，无法实现复杂的业务逻辑。	需要根据 Node 的属性或者 Pod 的属性进行调度，例如根据硬件类型、可用区等。
Taints 和 Tolerations	可以实现 Node 的“排斥性”，保证某些 Pod 不会被调度到某些 Node 上。	配置相对复杂，需要同时配置 Node 和 Pod。	需要控制某些 Pod 只能被调度到特定的 Node 上，例如 GPU 节点、特殊硬件节点等。
Pod Topology Spread Constraints	可以控制 Pod 在不同拓扑域上的分布，提高应用的可用性和容错性。	配置相对复杂，需要理解拓扑域的概念。	需要将 Pod 分布在不同的可用区、区域等，提高应用的可用性和容错性。
Custom Scheduler	功能强大，可以实现非常复杂的业务逻辑，完全按照你的意愿来调度 Pod。	开发和维护成本高，需要编写大量的代码。	需要实现非常特殊的调度逻辑，例如根据应用的优先级、版本等进行调度。

最后，送给大家一句至理名言：

“代码虐我千百遍，我待代码如初恋！” 💖

希望大家在学习 K8s 调度器的道路上，能够保持激情，不断探索，最终成为 K8s 大师！ 🍻 祝大家编码愉快！ 😉

K8s 调度器：你的应用，我来安排！(高级定制与优化，复杂业务需求攻略)

发表回复 取消回复

发表回复取消回复