Kubernetes系列：高级调度(HPA、污点、亲和力)

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，除非这些 Pod 明确"容忍"该污点。

Toleration 作用在 Pod 上，意为容忍，也就是可以兼容某类污点。

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

2.1 使用Taint

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

每个 Taint 包含三个部分：

key: 污点的键

value: 污点的值（可选）

effect: 污点的效果，必须是以下之一：

NoSchedule: 不能容忍此污点的 Pod 不会被调度到该节点
PreferNoSchedule: Kubernetes 尽量避免将不能容忍此污点的 Pod 调度到该节点
NoExecute: 不能容忍此污点的 Pod 不会被调度到该节点，并且已运行但不容忍的 Pod 将被驱逐

2、查看污点：

3、删除污点：

2.2 使用Tolerations

在 Pod 的 spec 中配置容忍：

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 中添加容忍。

3、亲和力（Affinity）

亲和力（Affinity）是一种调度机制，允许指定 Pod 应该如何调度到节点上，或者 Pod 之间应该如何共同调度。

通过 Taint 让节点不能随便部署 Pod，也通过 NodeSelector + Toleration 实现了将 Pod 部署到指定的节点上。但是 NodeSelector 对节点的选择是强制性的，假如配置了 NodeSelector 为 ssd=true，那么如果集群中没有匹配的节点，这个 Pod 将一直处于 Pending 状态。而在生产环境中可能会有这样的需求：

某些 Pod 优先选择有 ssd=true 标签的节点，如果没有再考虑部署到其他节点。

某些 Pod 需要部署在 ssd=true 和 type=physical 的节点上，但是优先部署在 ssd=true 的节点上。

同一类应用的 Pod 尽量不要部署或不允许部署在同一个节点或者符合某个标签的一类节点上。

相互依赖的两个 Pod 尽量或必须部署在同一个节点上。

诸如此类的需求单单使用 NodeSelector、NodeName、Taint 和 Toleration 是无法实现的，所以 Kubernetes 引用了 Affinity（亲和力）的概念，用于满足生产环境中更复杂的需求。

Affinity 根据功能的不同分为

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

Pod亲和力（Pod Affinity）：定义 Pod 应该或不应该与哪些其他 Pod 共同调度在同一节点或拓扑域中。

每种亲和力还有两种不同的“实现方法”，即必须和尽量，所以亲和力又分为软亲和力（非强制性）和硬亲和力（强制性）。

还可以看出 Pod 之间可以相互排斥，也可以相互吸引，所以 Pod 亲和力又分为 PodAffinity（Pod亲和力）和 PodAntiAffinity（Pod反亲和力）。

3.1 Node Affinity

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

nodeSelectorTerms：节点选择器配置，可以配置多个 matchExpressions，每个 matchExpressions 下可以配置多个key、value 类型的选择器，其中values可以配置多个。

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

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

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

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

💡

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

3.2 Pod Affinity和PodAntiAffinity

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

而 Pod 亲和力和反亲和力是根据其他Pod的标签进行匹配的，比如想要 A 服务的 Pod 不能和具有 service=b 标签的 Pod 部署在同一个节点上，此时可以使用 Pod 亲和力和反亲和力进行配置，该调度是基于 Pod 的标签进行选择的。

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

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

operator：配置和节点亲和力一致，但是没有 Gt 和 Lt。

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