要整体认识 Kubernetes（K8s）中的 PriorityClass 优先级调度与 HPA 自动扩缩容，需从核心定义、工作原理、使用场景、配置示例及关联逻辑五个维度展开。二者虽解决的问题不同（前者保障资源分配优先级，后者动态适配负载变化），但共同支撑 K8s 集群的资源高效利用与服务稳定性。

一、PriorityClass：Pod 优先级调度机制

在资源紧张（如节点内存 / CPU 不足）或集群需要优先保障核心服务时，PriorityClass 通过为 Pod 分配 “优先级权重”，决定 Pod 的调度顺序与 资源不足时的驱逐策略，核心目标是 “确保高优先级服务优先获得资源，低优先级服务作为‘资源缓冲’牺牲”。

1. 核心概念与作用

• PriorityClass：集群级别的 “优先级模板”，定义一个优先级数值（value，范围 0-1000000000，数值越大优先级越高），可关联 “抢占策略”（是否允许高优先级 Pod 驱逐低优先级 Pod）。

  注意：value ≥ 1000000000 的为 系统级优先级（仅用于 K8s 核心组件，如 etcd、kube-apiserver），用户自定义优先级需低于此值，避免影响集群运行。

• Pod 优先级：Pod 通过 spec.priorityClassName 关联某个 PriorityClass，从而获得对应的优先级数值，成为调度器（如 kube-scheduler）的决策依据。
• 核心作用：
  1. 调度优先：高优先级 Pod 优先被调度到满足资源需求的节点；
  2. 驱逐保护：资源不足时，低优先级 Pod 先被驱逐，释放资源给高优先级 Pod；
  3. 抢占机制：若高优先级 Pod 无节点可调度，可主动驱逐低优先级 Pod（需开启抢占配置）。

2. 工作原理

PriorityClass 的调度逻辑分为 调度阶段与 驱逐阶段，依赖 K8s 调度器与 kube-controller-manager 协同：

（1）调度阶段：优先分配资源

1. 当用户提交 Pod 时，K8s 会根据 priorityClassName 解析出优先级数值，写入 Pod 的 spec.priority 字段（不可手动修改）；
2. 调度器（kube-scheduler）的 优先级队列会按 Pod 优先级从高到低排序，优先处理高优先级 Pod 的调度请求；
3. 若高优先级 Pod 因资源不足无法调度，且开启了 “抢占模式”（默认开启），调度器会检查低优先级 Pod：
   • 计算 “驱逐低优先级 Pod 后能否满足高优先级 Pod 资源需求”；
   • 若满足，标记低优先级 Pod 为 “待驱逐”，并将高优先级 Pod 调度到该节点。

（2）驱逐阶段：资源不足时的清理

当节点资源（CPU / 内存）达到 “硬限制”（如 resource.limits），kubelet 会触发 节点级驱逐，驱逐逻辑按优先级排序：

1. 优先驱逐 优先级最低的 Pod；
2. 若优先级相同，驱逐 资源请求率最高（如内存使用率超阈值）的 Pod；
3. 系统级 Pod（如 kube-proxy）默认受保护，不会被驱逐（除非配置特殊参数）。

二、HPA：Horizontal Pod Autoscaler 自动扩缩容

HPA（水平 Pod 自动扩缩容）是 K8s 中基于负载动态调整 Pod 副本数的机制 —— 当服务 CPU 使用率过高、请求量激增时，自动增加 Pod 副本（扩容）；当负载下降时，自动减少副本（缩容），核心目标是 “以最少的资源成本，保障服务性能稳定”。

对比：HPA 是 “水平扩缩容”（增加 / 减少 Pod 数量），而 “垂直扩缩容”（VPA，调整单个 Pod 的 CPU / 内存限额）需重启 Pod，适用于资源需求长期变化的场景，二者可配合使用。

1. 核心概念与依赖

• HPA 资源对象：定义扩缩容的 “规则”（如目标 CPU 使用率、最小 / 最大副本数），通过控制器（horizontal-pod-autoscaler-controller）持续监控 Pod 负载并执行调整；
• 指标来源：HPA 依赖 Metrics Server（K8s 官方轻量级指标采集组件）获取 Pod 的 CPU / 内存使用率，若需自定义指标（如请求 QPS、并发连接数），需集成 Prometheus + Adapter；
• 扩缩容目标：HPA 只能作用于 Deployment/StatefulSet/ReplicaSet 等 “有副本控制器” 的资源，无法直接控制单个 Pod。

2. 工作原理

HPA 的核心逻辑是 “周期检查指标 → 计算目标副本数 → 执行扩缩容”，具体流程如下：

1. 指标采集：

   • HPA 控制器每隔 --horizontal-pod-autoscaler-sync-period（默认 15s）向 Metrics Server 请求目标资源（如 Deployment）下所有 Pod 的指标（CPU / 内存使用率、自定义指标）；
   • 过滤 “未就绪” 或 “正在终止” 的 Pod，仅计算健康 Pod 的指标平均值。

2. 副本数计算：
   以 “CPU 使用率” 为例，HPA 按以下公式计算目标副本数：
   目标副本数 = 当前副本数 × (当前指标平均值 / 目标指标值)

   • 示例：当前副本数 = 2，目标 CPU 使用率 = 50%，实际平均使用率 = 80% → 目标副本数 = 2×(80%/50%)=3.2 → 向上取整为 4（扩容）；
   • 若计算结果与当前副本数差异小于 --horizontal-pod-autoscaler-tolerance（默认 10%），则不触发扩缩容（避免频繁调整）。

3. 扩缩容执行：

   • 扩容：若目标副本数 > 当前副本数，且未超过 maxReplicas，HPA 向 Deployment 发送请求，增加 replicas 字段值；
   • 缩容：若目标副本数 < 当前副本数，且未低于 minReplicas，HPA 减少 replicas 字段值；
   • 缩容有 “冷却时间”（默认 3 分钟）：避免因负载短暂下降导致频繁缩容，影响服务稳定性。

三、PriorityClass 与 HPA 的关联逻辑

二者虽独立工作，但在实际集群中需协同设计，避免 “高优先级服务扩缩容受资源限制” 或 “低优先级服务无序扩容抢占资源”：

1. 高优先级服务优先扩缩容：
   核心服务（如支付）需配置 高 PriorityClass + HPA，确保：

   • 扩容时，高优先级 Pod 优先获得节点资源（低优先级 Pod 可能被驱逐）；
   • 缩容时，低优先级服务先缩容，高优先级服务的副本数优先保留。

2. 资源限额控制：
   为避免低优先级服务（如测试环境）通过 HPA 无限扩容抢占资源，可结合 ResourceQuota（资源配额）：

   • 为低优先级命名空间设置 limits.cpu/limits.memory，限制总资源使用；
   • 高优先级命名空间配置更高的资源配额，保障 HPA 扩容需求。

3. 避免 “优先级反转”：
   若低优先级 Pod 占用关键资源（如节点本地存储），可能导致高优先级 Pod 无法调度（即使驱逐低优先级 Pod，资源也无法释放）。需通过 Pod 亲和性 / 反亲和性 或 存储优先级 避免此类问题。