Kubernetes系列：高级调度（HPA、Toleration、Taint、Affinity）

type

status

date

slug

summary

1、HPA（自动扩缩容）

HPA（Horizontal Pod Autoscaler，水平 Pod 自动伸缩器）可以根据观察到的 CPU、内存使用率或自定义度量标准来自动扩展或缩容 Pod 的数量。注意 HPA 不适用于无法缩放的对象，比如 DaemonSet。另外 HPA 需要依赖 Metrics Server 插件。

HPA 的工作原理：

指标收集：HPA 从 Metrics Server 或其他自定义指标源获取指标数据

决策计算：比较当前指标值与目标值，计算所需的 Pod 数量

调整副本：通过调整目标资源(如 Deployment)的副本数来实现扩缩容

所需副本数的计算公式

例如目标是保证所有 Pod CPU 使用率为 10%，当前只有 1 个 Pod，最小 Pod 数为 1，最大 Pod 数为 10。如果当前 Pod 的 CPU 使用率突然飙升到 35%，按照计算公式 1 * (35 / 10) = 3.5 ，然后向上取整，得到扩容后的目标 Pod 数为 4 个。

1.1 Metrics Server的使用

Metrics Server 是 Kubernetes 集群中用于收集资源指标的核心组件，它为 Horizontal Pod Autoscaler (HPA) 和 Vertical Pod Autoscaler (VPA) 提供数据支持。

1.1.1 Metrics Server安装

从官方 GitHub 仓库下载最新的部署 YAML 文件：

修改 YAML 文件。由于 Kubernetes 节点的 kubelet 使用自签证书，Metrics Server 默认会校验证书，可能导致连接失败。需在 components.yaml 中添加 --kubelet-insecure-tls 参数：

部署 Metrics Server。

检查 Metrics Server 是否正常运行：

输出示例：

1.1.2 Metrics Server使用

查看节点资源使用情况

查看 Pod 资源使用情况

输出示例：

CPU(cores)：1m 表示使用 1/1000 个 CPU 核心

MEMORY(bytes)：18Mi 表示使用 18MiB 内存

1.2 HPA的使用

HPA 有两种创建方式：

1、使用 kubectl autoscale 命令创建

2、使用 YAML 配置文件创建。注意 HPA 的版本差异：

autoscaling/v1：仅支持 CPU 指标

autoscaling/v2：支持多种指标(CPU、内存、自定义指标等)

1.2.1 基于CPU使用率的HPA

1.2.2 基于内存使用率的HPA

1.2.3 基于自定义指标的HPA

2、Toleration和Taint（容忍和污点）

污点（Taint）和容忍（Toleration）是控制 Pod 调度到特定 Node 的机制，使 Node 排斥或者兼容部署符合某类特征的 Pod。

Taint：作用在 Node 上，声明不允许任何 Pod 调度到这个 Node 上，除非这个 Pod 明确"容忍"该污点。

Toleration：作用在 Pod 上，意为容忍，也就是可以兼容某类污点 Node，所以该 Pod 允许调度到污点 Node 上。

Taint 和 Toleration 相互配合使用实现以下功能：

专用节点：比如有一批 GPU 服务器只能部署要使用 GPU 的 Pod。每个节点上都可以应用一个或多个 Taint，这表示对于那些不能容忍这些 Taint 的 Pod 是不能部署在该服务器上的。如果 Pod 配置了 Toleration，则表示这些 Pod 可以被调度到设置了 Taint的节点上，换而言之不管节点有没有设置 Taint，都可以用来部署 Pod。

驱逐Pod：在节点出现问题时（如磁盘压力、网络不可用），Kubernetes 会自动给节点打上污点，从而阻止新 Pod 调度上来并驱逐已有的 Pod。

2.1 使用Taint

1、设置 Taint。使用 kubectl taint 命令可以对 Node 设置 Taint。

每个 Taint 包含三个部分：

key: 污点的键

value: 污点的值（可选）

effect: 污点的效果，即排斥 Pod 的效果。

NoSchedule：禁止调度。不能容忍此污点的新 Pod 不会被调度到该节点上。已运行在节点上的 Pod 不受影响。
PreferNoSchedule：尽量避免调度。调度器会尽量避免将不能容忍此污点的 Pod 调度到该节点上，但如果没有其他节点可用，仍然会调度上去。这是一个“软性”限制。
NoExecute：禁止执行并驱逐。不仅不会调度新的不能容忍的 Pod，还会立即驱逐节点上已有的、不能容忍此污点的 Pod。

2、查看污点：

3、删除污点：

2.2 使用Tolerations

容忍度定义在 Pod 的 .spec.tolerations 字段中。

1、完全容忍。operator 为 Equal，比如能容忍 key 名为 taintKey、value 为 taintValue、effect 为 NoSchedule 的 Taint（Toleration可以定义多个）。

2、不完全容忍。operator 为 Exists，比如

容忍 key 名为 taintKey、effect 为 NoSchedule 的 Taint，不考虑 Taint 的 value 是什么。

容忍 key 名为 taintKey 的 Taint，不考虑 value 和 effect。

容忍所有污点。这可能会绕过节点的安全隔离，请谨慎使用。

2.3 Taint和Tolerations搭配使用

回到前面的需求，比如有一批 GPU 服务器 Node 只能部署要使用 GPU 的 Pod，步骤如下：

1、给 GPU 节点添加污点。

2、在需要 GPU 的 Pod 中添加容忍。

这样，只有声明了容忍 hardware=gpu:NoSchedule 的 Pod 才能被调度到 gpu-node 上。

3、Affinity（亲和力）

亲和力（Affinity）是一种调度机制，用于控制 Pod 调度哪个到 Node 节点上，或者 Pod 之间应该如何协同调度。

Affinity 主要有两大类：

节点亲和力（Node Affinity）：定义 Pod 应该或必须调度到哪些具有特定标签的节点上。

Pod Affinity/Anti-Affinity（Pod 亲和性/反亲和性）：定义 Pod 应该或不应该与哪些其他 Pod 共同调度在同一节点或拓扑域中。这里可以看出 Pod 之间可以相互排斥，也可以相互吸引。

每种亲和力还有两种不同的“实现方法”，即必须和尽量，所以亲和力又分为

软亲和力（非强制性）

硬亲和力（强制性）

Affinity 和 Taint/Toleration 的区别

Affinity（亲和性）：是 Pod 端的 “吸引” 规则。Pod 主动选择希望被调度到哪些 Node 节点上，或者希望和哪些 Pod 在一起。

Taint/Toleration（污点/容忍）：是 Node 端的 “排斥” 规则。Node 节点主动拒绝不能运行哪些 Pod，Pod 需要声明“容忍”才能“忍受”并运行在污点 Node 上。

特性	Affinity (亲和性)	Taint/Toleration (污点/容忍)
核心思想	吸引 (Pull) - Pod 倾向于被调度到某处	排斥 (Push) - 节点拒绝 Pod调度，除非Pod能忍受
配置对象	主要在Pod Spec中定义 (规则写在Pod的配置里)	Taint在Node上定义，Toleration在Pod Spec中定义
作用方向	Pod → Node / Pod → Pod	Node → Pod
主动权	Pod是主动方，表达自己的偏好或要求	Node是主动方，设置准入条件；Pod是被动响应方
主要目的	1. 优化性能 (调度到有SSD/GPU的节点) 2. 高可用 (Pod分散)3. 低延迟 (Pod集中)	1. 专用节点 (只允许特定Pod运行) 2. 隔离 (隔离Master、特殊硬件节点) 3. 驱逐准备 (节点维护前打上污点)

Affinity 和 Taint/Toleration 在调度过程中是协同工作的，调度器会同时考虑这两组规则，最终决定 Pod 能否被调度到某个 Node 上。

Toleration 是第一道、也是最强硬的关卡。它就像一个守门员，直接拒绝掉没有“门票”（容忍）的 Pod。

NodeAffinity 的硬性要求（required...）是第二道关卡，进一步筛选出符合条件的节点。

最后，NodeAffinity 的软偏好（preferred...）、Pod Affinity/Anti-Affinity 以及其他评分标准共同作用，为剩下的每个节点打分，选择最优解。

一个成功的调度必须同时满足：Pod 容忍了节点的所有污点，并且节点的标签匹配了 Pod 的亲和性（如果有定义的话）。例如：

给专门的 GPU 节点打上 taint: gpu=true:NoSchedule。

同时，给你的机器学习 Pod 加上对应的 toleration 和 nodeAffinity，确保它们只会且优先被调度到这些专用节点上。

3.1 Node Affinity

NodeAffinity 是根据节点上的标签选择性地调度，可以让 Pod 部署在指定标签的节点上，或者不部署在指定标签的节点上，调度时是根据节点上的标签进行选择的。

Node Affinity 有两种主要类型：

requiredDuringSchedulingIgnoredDuringExecution：必须满足的硬性要求。如果找不到匹配的节点，Pod 将无法被调度（Pending）。这类似于 nodeSelector，但语法更强大。

preferredDuringSchedulingIgnoredDuringExecution：偏好的软性要求。调度器会尝试寻找满足这些偏好的节点，但如果没有，Pod 仍然会被调度到其他节点上。

配置文件示例：

requiredDuringSchedulingIgnoredDuringExecution ：硬亲和力要求，必须满足才能调度。

nodeSelectorTerms：节点选择器配置，可以配置多个 matchExpressions，类似于标签选择器的作用。

key ：标签名
values ：标签值
operator：标签匹配的方式，有以下几种情况：

In：相当于 key = value 的形式。
NotIn：相当于 key != value 的形式。
Exists：节点存在 label 的 key 为指定的值即可，不能配置 values 字段。
DoesNotExist：节点不存在 label 的 key 为指定的值即可，不能配置 values 字段。
Gt：大于 value 指定的值，用于数值
Lt：小于 value 指定的值，用于数值

preferredDuringSchedulingIgnoredDuringExecution：软亲和力配置，调度器会尝试满足但不保证。

weight：软亲和力的权重，权重越高优先级越大，范围为1～100。
preference：软亲和力配置项，可以配置多个，matchExpressions 和硬亲和力一致。

💡

如果同时指定了 NodeSelector 和 NodeAffinity，需要两者都满足才能被调度；如果配置了多个 NodeSelectorTerms，满足其一即可调度到指定的节点上；如果配置了多个 MatchExpressions，需要全部满足才能调度到指定的节点上；如果删除了被调度节点上的标签，Pod 不会被删除，也就是说亲和力配置只有在调度的时候才会起作用。

3.2 Pod Affinity和PodAntiAffinity

Pod Affinity 和 PodAntiAffinity 是根据其他Pod的标签进行匹配的。

Pod Affinity：倾向于将 Pod 与其他 Pod 放在同一拓扑域。

Pod Anti-Affinity：倾向于将 Pod 与其他 Pod 分散到不同的拓扑域。

一个关键概念是 topologyKey，它定义了“拓扑域”的范围。这个 Key 是节点标签的 key，系统通过比较节点上这个标签的 value 来判断节点是否属于同一个拓扑域。

常用 kubernetes.io/hostname 表示节点级别（最严格）。

常用 topology.kubernetes.io/zone 表示可用区级别。

常用 topology.kubernetes.io/region 表示区域级别。

1、Pod Affinity 示例

假设你想让一个 Web 服务器 Pod 尽可能地靠近一个缓存 Pod（例如 app=redis-cache）运行，以减少网络延迟。

labelSelector：Pod 选择器配置，可以配置多个。

matchExpressions：和节点亲和力配置一致。

topologyKey：匹配的拓扑域的 key，也就是节点上 label 的 key，key 和 value 相同的为同一个域，用于标注不同的机房和地区。

这个配置表示：优先（preferredDuringScheduling...）将 web-server Pod 调度到某个可用区（topologyKey: topology.kubernetes.io/zone），只要该可用区内至少有一个节点上运行着带有 app=redis-cache 标签的 Pod。

2、Pod Anti-Affinity 示例

为了实现高可用，你通常希望同一应用（例如 app: my-web-app）的多个副本不要运行在同一个节点或同一个可用区上，以避免单点故障。

这个配置表示：my-web-app 的每个 Pod 必须（requiredDuringScheduling...）被调度到不同主机（topologyKey: kubernetes.io/hostname）上。这样就能确保三个副本分散在三个不同的节点上。