Jimmy Song – 调度与弹性

调度与弹性概述

Jimmy Song — Mon, 13 Oct 2025 00:00:00 +0000

灵活的调度与资源管理，是 Kubernetes 实现弹性、高可用和高效资源利用的核心竞争力。

Kubernetes 通过灵活的调度与资源管理机制，实现了高效的工作负载分布与资源利用。本文作为本章概览，系统梳理调度流程、资源分配、自动扩缩容、优先级抢占、节点压力驱逐等核心内容；每个主题在本章后续文章中都有专门的深入讨论。

调度与资源管理概述

Kubernetes 需要复杂的系统来决定工作负载的运行位置及资源分配方式。这些系统确保：

Pod 被调度到合适的节点
资源分配高效且公平
高优先级工作负载在资源紧张时能优先运行
系统可根据资源需求动态调整

下图展示了调度与资源管理的主要组件关系：

图 1: 调度与资源管理核心组件

Kubernetes 调度器原理

Kubernetes 调度器（kube-scheduler）负责为新建 Pod 分配节点。它持续监听未分配节点的 Pod，并为每个 Pod 选择最优节点。

调度流程

调度分为两大阶段：

过滤（Filtering）：筛选出可运行 Pod 的节点集合
打分（Scoring）：对候选节点评分，选出最优节点

图 2: 调度流程：调度周期与绑定周期

调度框架与插件机制

调度器采用可插拔架构（Scheduling Framework），支持多种扩展点，便于自定义调度逻辑。

图 3: 调度框架扩展点

默认调度插件

下表列举了常用内置调度插件及其作用：

插件	说明	扩展点
NodeResourcesFit	检查节点资源是否充足	preFilter, filter, score
PodTopologySpread	实现拓扑分布约束	preFilter, filter, preScore, score
NodeAffinity	节点亲和性与选择器	filter, score
TaintToleration	污点与容忍度	filter, preScore, score
NodeName	节点名匹配	filter
NodePorts	检查端口可用性	preFilter, filter
NodeUnschedulable	过滤不可调度节点	filter
InterPodAffinity	Pod 间亲和/反亲和	preFilter, filter, preScore, score
PrioritySort	优先级排序	queueSort
DefaultBinder	默认绑定机制	bind
DefaultPreemption	抢占逻辑	postFilter

表 1: Kubernetes 默认调度插件及扩展点

资源管理机制

Kubernetes 支持为 Pod 中的容器指定资源请求（requests）与限制（limits），用于调度与资源分配。

资源类型

主要资源类型如下：

资源类型	说明	单位
CPU	计算资源	核心数（1、0.5、100m 等）
Memory	内存	字节（Ki、Mi、Gi 等）
Ephemeral Storage	临时存储	字节（Ki、Mi、Gi 等）
Huge Pages	大页内存（Linux）	指定大小（如 hugepages-2Mi）
Extended Resources	自定义扩展资源	整数单位

表 2: Kubernetes 支持的资源类型

Requests 与 Limits

每个容器可指定资源请求与限制。下图展示了 Pod 内多容器资源汇总关系：

图 4: Pod 资源请求与限制示意

Requests：调度时保证的最小资源
Limits：运行时允许的最大资源

调度器依据 requests 进行节点选择，kubelet 依据 limits 强制资源上限。

资源限制的强制机制

kubelet 与容器运行时协作，强制资源限制：

CPU 限制：通过限流实现，超出部分被限制
内存限制：超限时触发 OOM 杀手，容器被终止

若容器超出 requests 但未超 limits，且节点资源紧张，Pod 可能被驱逐。

Pod 调度策略

Kubernetes 提供多种机制控制 Pod 在节点间的分布。

拓扑分布约束（Topology Spread Constraints）

拓扑分布约束可控制 Pod 在不同故障域（如区域、可用区、节点）间的分布。

图 5: 拓扑分布约束示意

常用字段包括：

maxSkew：最大分布偏差
topologyKey：节点标签键
whenUnsatisfiable：无法满足约束时的处理方式
labelSelector：约束作用的 Pod 选择器

污点与容忍（Taints & Tolerations）

污点与容忍机制确保 Pod 不会被调度到不合适的节点。

图 6: 污点与容忍调度示意

常见场景包括专用节点、特殊硬件节点、节点压力驱逐等。

优先级与抢占

Kubernetes 支持通过优先级（Priority）指定 Pod 重要性。高优先级 Pod 无法调度时，调度器可抢占低优先级 Pod。

Pod 优先级

通过 PriorityClass 对象和 priorityClassName 字段指定。优先级值越高，Pod 越重要。

图 7: Pod 优先级示意

内置优先级类包括 system-cluster-critical 和 system-node-critical。

抢占机制

抢占流程如下：

高优先级 Pod 无法调度
调度器查找可抢占节点
选择低优先级 Pod 进行驱逐
高优先级 Pod 获得调度机会

节点压力驱逐

kubelet 监控节点资源压力，主动驱逐 Pod 以防节点故障。

驱逐信号与阈值

kubelet 依据多种信号判断资源压力：

驱逐信号	说明
memory.available	节点可用内存
nodefs.available	节点文件系统可用空间
nodefs.inodesFree	节点文件系统可用 inode
imagefs.available	镜像存储可用空间
pid.available	可用进程数

表 3: 节点驱逐信号说明

阈值分为软阈值（有宽限期）和硬阈值（立即驱逐）。驱逐顺序依次考虑 QoS 类别、资源使用与优先级。

Pod 中断预算（PDB）

Pod Disruption Budget（PDB）用于限制自愿中断（如节点维护、升级）时可同时中断的 Pod 数量。

图 8: PDB 保护机制示意

PDB 可指定 minAvailable 或 maxUnavailable，仅保护自愿中断，不防止节点故障或资源驱逐。

自动扩缩容（Autoscaling）

Kubernetes 支持基于指标的自动扩缩容，提升资源利用率。

水平 Pod 自动扩缩容（HPA）

HPA 控制器根据指标自动调整副本数。下图展示了 HPA 工作流程：

图 9: HPA 工作流程

HPA 支持 CPU、内存、自定义与外部指标。核心算法如下：

desiredReplicas = ceil[currentReplicas * (currentMetricValue / desiredMetricValue)]

可配置扩缩容策略

HPA 支持分别配置扩容与缩容策略：

behavior:
 scaleDown:
 stabilizationWindowSeconds: 300
 policies:
 - type: Percent
 value: 10
 periodSeconds: 60
 scaleUp:
 stabilizationWindowSeconds: 0
 policies:
 - type: Percent
 value: 100
 periodSeconds: 15
 - type: Pods
 value: 4
 periodSeconds: 15
 selectPolicy: Max

可控制扩缩容速度、窗口期与单次变更幅度。v1.37 起还可在 behavior.scaleUp/scaleDown.tolerance 中为单个 HPA 设置容差（默认集群级 10%），并以 minReplicas: 0（Beta，仅自定义/外部指标）实现缩容到零。

垂直扩缩容与原地调整

垂直 Pod 自动扩缩容（VPA）根据历史用量推荐并调整容器的 requests/limits。v1.35 GA 的 Pod 原地资源调整让 VPA 的 InPlaceOrRecreate 模式可以在不重建 Pod 的情况下生效，有状态服务的垂直弹性由此成为可能。同一工作负载不要让 HPA 与 VPA 同时基于 CPU/内存做决策。

节点级弹性

HPA 扩出的 Pod 若无节点可调度，由 Cluster Autoscaler（基于节点组）或 Karpenter（按 Pending Pod 需求实时创建合适规格节点）补充节点；两者均依赖 Pod 的 requests 做容量计算，这也是"始终设置 requests"的又一理由。

资源装箱（Bin Packing）策略

Kubernetes 支持多种资源装箱策略，提升集群利用率。

MostAllocated 策略

MostAllocated 策略倾向于将 Pod 调度到资源利用率高的节点。

apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration
profiles:
- pluginConfig:
 - args:
 scoringStrategy:
 resources:
 - name: cpu
 weight: 1
 - name: memory
 weight: 1
 type: MostAllocated
 name: NodeResourcesFit

RequestedToCapacityRatio 策略

该策略可更细粒度控制资源分配比例，适用于复杂场景。

多调度器支持

Kubernetes 支持同时运行多个调度器，满足特殊调度需求。

图 10: 多调度器调度示意

通过 Pod 的 schedulerName 字段指定调度器。

集群规模与可扩展性

Kubernetes 支持大规模集群，常见上限如下：

节点数：5000
总 Pod 数：150,000
总容器数：300,000
单节点最大 Pod 数：110

大集群需关注控制面容量、资源配额、云厂商限制、网络与存储性能等。

本章导读

本章其余文章按"调度 → 资源管理 → 弹性"的顺序展开：

主题	文章
调度器工作原理与调度框架	kube-scheduler 资源调度
nodeSelector、亲和性、拓扑分布约束	调度约束
PriorityClass、抢占与 PDB 的交互	优先级与抢占
Guaranteed/Burstable/BestEffort 与驱逐顺序	服务质量等级
命名空间级配额与默认资源	ResourceQuota 与 LimitRange
资源预留、节点压力驱逐、CPU/内存/拓扑管理器	kubelet 节点资源管理
基于指标的水平扩缩	Horizontal Pod Autoscaling、自定义 Pod 自动扩缩容器
纵向扩缩与事件驱动扩缩	VPA 与 KEDA
节点层弹性	节点自动扩缩
批处理与 AI 的成组调度	Volcano 批处理调度器

表 4: 调度与弹性章节导读

总结

Kubernetes 通过灵活的调度与资源管理体系，实现了高效的工作负载分布、资源利用与弹性伸缩。合理配置调度策略、资源限制、优先级与自动扩缩容机制，可显著提升集群的性能、可靠性与可维护性。

参考文献

资源调度

Jimmy Song — Sat, 21 May 2022 00:00:00 +0800

资源调度是 Kubernetes 实现弹性伸缩与高效资源利用的核心能力，合理配置调度策略可显著提升集群稳定性与业务连续性。

Kubernetes 作为现代容器编排调度平台，资源调度是其核心功能之一。本节将深入探讨 Kubernetes 中的资源调度机制，包括调度器的工作原理、调度策略以及高级调度场景。

调度器组件

Kubernetes 的调度器（kube-scheduler）负责将新建的 Pod 分配到合适的节点上。理解其工作原理有助于优化资源分配和业务弹性。

kube-scheduler 工作原理

kube-scheduler 是 Kubernetes 集群中负责 Pod 调度的核心组件，其主要职责包括：

监听 kube-apiserver 中未调度的 Pod
根据调度算法为 Pod 选择合适的节点
通过预选和优选两个阶段完成调度决策

调度流程

Kubernetes 调度流程分为以下三个阶段：

预选阶段（Filtering）：过滤掉不满足 Pod 运行条件的节点
优选阶段（Scoring）：对候选节点进行评分，选择最优节点
绑定阶段（Binding）：将 Pod 分配到选定的节点上

调度策略

Kubernetes 支持多种调度策略，适配不同类型的工作负载和业务需求。下表总结了常见工作负载的调度特性。

资源类型	调度特性	典型场景
Deployment	副本分散调度	无状态服务
DaemonSet	每节点运行一个 Pod 副本	节点级守护进程
StatefulSet	有序调度，稳定标识	有状态服务

表 1: Kubernetes 工作负载调度策略对比

高级调度功能

通过为节点和 Pod 添加标签（Labels）和污点（Taints），可以实现更精细的调度控制。常见高级调度机制包括：

节点选择器（NodeSelector）：通过标签选择目标节点
节点亲和性（Node Affinity）：表达更复杂的节点选择规则
Pod 亲和性和反亲和性（Pod Affinity/Anti-Affinity）：控制 Pod 之间的调度关系
污点和容忍（Taints and Tolerations）：实现节点隔离与专用资源分配
拓扑分布约束（Topology Spread Constraints）：按可用区、节点等拓扑域均匀分布 Pod，是跨可用区高可用的首选手段
优先级与抢占（PriorityClass）：高优先级 Pod 在资源不足时可抢占低优先级 Pod
调度门控（Scheduling Gates，v1.30 GA）：Pod 创建时带有 spec.schedulingGates，在外部控制器移除门控前调度器不会处理它，为配额、预算等外部准入提供挂钩
动态资源分配（DRA，v1.34 GA）：调度器根据 ResourceClaim 为 Pod 挑选同时满足 CPU/内存与 GPU 等设备约束的节点
成组调度（Gang Scheduling）：Workload/PodGroup API（v1.35 Alpha，v1.37 Beta 但默认关闭）让一组 Pod 要么全部调度、要么全部等待，面向分布式训练等场景

以下示例展示了拓扑分布约束与调度门控的用法：

apiVersion: v1
kind: Pod
metadata:
 name: web
 labels:
 app: web
spec:
 schedulingGates:
 - name: example.com/quota-check  # 由外部控制器在校验通过后移除
 topologySpreadConstraints:
 - maxSkew: 1
 topologyKey: topology.kubernetes.io/zone
 whenUnsatisfiable: DoNotSchedule
 labelSelector:
 matchLabels:
 app: web
 containers:
 - name: web
 image: nginx:1.27

动态调度扩展

在实际生产环境中，调度需求常常随着业务变化而动态调整。Kubernetes 支持多种扩展方式以满足复杂场景。

重调度场景

当需要对已调度的 Pod 进行重新分配时，常见场景包括集群负载均衡和数据本地性优化。

集群负载均衡

当集群中新增节点时，可能需要重新平衡各节点的资源利用率。原生 kube-scheduler 不支持 Pod 的重调度，可借助如下工具：

Descheduler：用于驱逐过载节点上的 Pod，实现集群负载重平衡

数据本地性优化

对于大数据和批处理应用，Pod 的调度需要考虑数据分布：

Volcano（原 kube-batch）：专为批处理和机器学习工作负载设计的调度器，支持队列管理、资源配额和任务调度
Kueue：Kubernetes SIG 维护的作业排队系统，不替换调度器，而是通过调度门控控制 Job/JobSet 何时进入调度，实现配额与公平共享
Karpenter：按待调度 Pod 的实际需求实时创建合适规格的节点，取代传统 Cluster Autoscaler 的节点组模型

扩展调度器

Kubernetes 支持多调度器和调度器扩展，便于自定义调度逻辑和策略。

多调度器：同时运行多个调度器实例，Pod 通过 spec.schedulerName 选择
调度器扩展：通过 Scheduler Framework 插件机制在 PreFilter、Filter、Score、Bind 等扩展点自定义调度流程
调度器配置：通过 KubeSchedulerConfiguration（kubescheduler.config.k8s.io/v1）启用/禁用插件、配置多个 profile

调度器框架与插件开发详见调度架构与 Framework 扩展。

最佳实践

为提升调度效率和集群稳定性，建议遵循以下实践：

合理设置资源请求和限制，确保调度器能够做出正确的调度决策
使用节点标签和选择器，实现精确的节点选择
跨可用区部署优先使用拓扑分布约束，而不是只靠 Pod 反亲和性
为关键系统组件设置 PriorityClass，保证资源紧张时优先运行
监控 scheduler_pending_pods、scheduler_scheduling_attempt_duration_seconds 等指标，及时发现和解决调度瓶颈

总结

Kubernetes 资源调度机制通过灵活的调度策略和可扩展的调度框架，实现了高效的资源分配与业务弹性。掌握调度原理与高级功能，有助于构建稳定、可扩展的云原生集群环境。

参考文献

调度约束：节点选择、亲和性与拓扑分布

Jimmy Song — Sun, 01 Nov 2026 00:00:00 +0800

调度约束表达的是业务对"在哪里运行"的意图：高可用要分散、低延迟要聚合、特殊硬件要匹配——四种机制各管一段，组合起来才是完整答案。

默认情况下 kube-scheduler 只保证 Pod 落到有足够资源的节点上，不关心 Pod 之间的相对位置。但真实的生产需求远不止于此：数据库副本必须分布在不同可用区，GPU 任务必须落到带特定型号显卡的节点，缓存应与访问它的服务同处一个机架，同一服务的副本要尽量均匀铺开而不是挤在一台机器上。Kubernetes 提供了四类调度约束来表达这些意图，本文逐一介绍并说明如何组合使用。

四类约束概览

机制	字段	决策依据	支持软约束	典型用途
节点选择器	`spec.nodeSelector`	节点标签精确匹配	否	简单的"只能跑在某类节点"
节点亲和性	`spec.affinity.nodeAffinity`	节点标签表达式（In/NotIn/Exists/Gt/Lt）	是	复杂节点选择、偏好某类节点
Pod 亲和/反亲和	`spec.affinity.podAffinity` / `podAntiAffinity`	拓扑域内是否已有匹配标签的 Pod	是	与某服务同置、副本互斥
拓扑分布约束	`spec.topologySpreadConstraints`	各拓扑域内匹配 Pod 的数量差	是	跨可用区/节点均匀分布

表 1: Kubernetes 调度约束对比

除这四类外，污点与容忍（见 Taint 和 Toleration）从节点侧"排斥"Pod，与亲和性从 Pod 侧"选择"节点互为补充；spec.nodeName 则完全绕过调度器直接绑定节点，仅用于静态 Pod 等特殊场景。

节点选择器

nodeSelector 是最简单的约束：Pod 只会被调度到拥有全部指定标签的节点。

apiVersion: v1
kind: Pod
metadata:
 name: gpu-job
spec:
 nodeSelector:
 nvidia.com/gpu.product: NVIDIA-H100-80GB-HBM3
 topology.kubernetes.io/zone: cn-beijing-a
 containers:
 - name: train
 image: my-trainer:1.0

Kubernetes 为每个节点自动维护一组众所周知的标签，是编写约束时最常用的拓扑键：

标签	含义	设置者
`kubernetes.io/hostname`	节点主机名	kubelet
`kubernetes.io/os`、`kubernetes.io/arch`	操作系统与 CPU 架构（linux/amd64、arm64 等）	kubelet
`topology.kubernetes.io/zone`	可用区	云控制器 / 管理员
`topology.kubernetes.io/region`	地域	云控制器 / 管理员
`node.kubernetes.io/instance-type`	云实例规格	云控制器
`node-role.kubernetes.io/control-plane`	控制面节点	kubeadm

表 2: 常用的内建节点标签

GPU 型号、内核特性等硬件标签通常由 Node Feature Discovery（NFD）或 NVIDIA GPU Feature Discovery 自动打上。

节点亲和性

节点亲和性是 nodeSelector 的超集，支持集合运算符、多组条件以及"尽量满足"的软约束：

spec:
 affinity:
 nodeAffinity:
 requiredDuringSchedulingIgnoredDuringExecution: # 硬约束：不满足则不调度
 nodeSelectorTerms:
 - matchExpressions:
 - key: topology.kubernetes.io/zone
 operator: In
 values: [cn-beijing-a, cn-beijing-b]
 - key: node.kubernetes.io/instance-type
 operator: NotIn
 values: [ecs.t6-c1m1.large]
 preferredDuringSchedulingIgnoredDuringExecution: # 软约束：按权重加分
 - weight: 80
 preference:
 matchExpressions:
 - key: karpenter.sh/capacity-type
 operator: In
 values: [spot]
 - weight: 20
 preference:
 matchExpressions:
 - key: node.kubernetes.io/instance-type
 operator: In
 values: [ecs.g8i.xlarge]

语义要点：

nodeSelectorTerms 中的多个条目是或关系，单个条目内的 matchExpressions 是与关系
IgnoredDuringExecution 表示约束只在调度时评估，Pod 运行后节点标签变化不会触发驱逐；RequiredDuringExecution 变体至今未实现，需要该语义时可用污点的 NoExecute 效果
软约束的 weight 取值 1 – 100，调度器把所有满足的偏好权重相加作为该节点的亲和性得分，再与其他打分插件的结果合并
运算符 Gt/Lt 只对整数字符串有效，常用于按 CPU 核数、显存大小等数值标签筛选
matchFields 可按节点字段（目前仅 metadata.name）匹配

Pod 亲和性与反亲和性

Pod 亲和性依据其他 Pod 的位置做决策：在某个拓扑域（由 topologyKey 指定的节点标签划分）内，若已存在匹配 labelSelector 的 Pod，则该域对当前 Pod 具有亲和（吸引）或反亲和（排斥）效果。

spec:
 affinity:
 podAffinity:
 requiredDuringSchedulingIgnoredDuringExecution:
 - labelSelector:
 matchLabels:
 app: redis-cache
 topologyKey: topology.kubernetes.io/zone  # 与缓存同可用区
 podAntiAffinity:
 requiredDuringSchedulingIgnoredDuringExecution:
 - labelSelector:
 matchLabels:
 app: web
 topologyKey: kubernetes.io/hostname  # 同一节点不放两个 web 副本
 preferredDuringSchedulingIgnoredDuringExecution:
 - weight: 100
 podAffinityTerm:
 labelSelector:
 matchLabels:
 app: web
 topologyKey: topology.kubernetes.io/zone  # 尽量跨可用区

几个实践中容易踩坑的细节：

labelSelector 默认只匹配同命名空间的 Pod，跨命名空间需显式写 namespaces 或 namespaceSelector
硬反亲和 + topologyKey: kubernetes.io/hostname 意味着副本数不能超过节点数，扩容时会出现 Pending；跨可用区分散更推荐用拓扑分布约束
Pod 亲和性需要扫描所有节点上的 Pod，在数千节点集群中开销显著高于节点亲和性，应避免在大规模 DaemonSet 类工作负载上使用
matchLabelKeys（v1.33 GA）可把当前 Pod 自身的某些标签值自动合并进 labelSelector，典型用法是加上 pod-template-hash，让反亲和只在同一次 Deployment 版本的副本间生效，避免滚动更新时新旧版本互相排斥导致卡住：

podAntiAffinity:
 requiredDuringSchedulingIgnoredDuringExecution:
 - labelSelector:
 matchLabels:
 app: web
 matchLabelKeys: [pod-template-hash]
 topologyKey: kubernetes.io/hostname

mismatchLabelKeys 则相反，用于"与标签值不同的 Pod 共置"，例如多租户场景中让不同 tenant 的 Pod 分开。

拓扑分布约束

拓扑分布约束（Topology Spread Constraints）解决的是"均匀铺开"问题：以 topologyKey 划分拓扑域，要求各域内匹配 Pod 的数量之差不超过 maxSkew。相比反亲和性的"要么同域要么不同域"二元语义，它能表达"3 个可用区各放 2 个副本"这样的量化分布，且在域数少于副本数时仍可正常工作。

apiVersion: apps/v1
kind: Deployment
metadata:
 name: web
spec:
 replicas: 6
 selector:
 matchLabels:
 app: web
 template:
 metadata:
 labels:
 app: web
 spec:
 topologySpreadConstraints:
 - maxSkew: 1
 topologyKey: topology.kubernetes.io/zone
 whenUnsatisfiable: DoNotSchedule  # 硬约束
 labelSelector:
 matchLabels:
 app: web
 matchLabelKeys: [pod-template-hash]  # 只在同一版本内计算倾斜
 minDomains: 3 # 至少铺开到 3 个可用区
 - maxSkew: 2
 topologyKey: kubernetes.io/hostname
 whenUnsatisfiable: ScheduleAnyway  # 软约束：尽量按节点均匀
 labelSelector:
 matchLabels:
 app: web
 containers:
 - name: web
 image: nginx:1.27

字段	说明	状态
`maxSkew`	任意两个拓扑域内匹配 Pod 数量的最大允许差值，必须 ≥ 1	GA
`topologyKey`	划分拓扑域的节点标签键	GA
`whenUnsatisfiable`	`DoNotSchedule`（硬）或 `ScheduleAnyway`（软，尽量减小倾斜）	GA
`labelSelector`	统计哪些 Pod	GA
`matchLabelKeys`	把当前 Pod 的指定标签值并入选择器，滚动更新时避免新旧版本混算	v1.27 Beta，v1.34 起与 `labelSelector` 合并语义 Beta
`minDomains`	拓扑域少于该值时视为倾斜，迫使调度器"撑开"域数；仅 `DoNotSchedule` 时有效	v1.30 GA
`nodeAffinityPolicy`	计算倾斜时是否只统计满足 Pod 节点亲和性的节点（默认 `Honor`）	v1.33 GA
`nodeTaintsPolicy`	计算倾斜时是否排除有不可容忍污点的节点（默认 `Ignore`）	v1.33 GA

表 3: 拓扑分布约束字段说明

两个经常被忽视的默认行为：

拓扑域的集合由集群中存在的节点标签值决定。若某可用区暂时没有节点（例如节点池缩容到零），该域不会被计入，minDomains 正是为此而设
默认 nodeTaintsPolicy: Ignore 会把带污点的节点（如控制面节点）也算进拓扑域，可能导致"控制面所在可用区副本为 0"被判定为倾斜而无法调度，生产中通常应设为 Honor

集群级默认约束

管理员可以在调度器配置中为所有未声明 topologySpreadConstraints 的 Pod 设置默认约束。Kubernetes 自身的内建默认值是：按可用区 maxSkew: 3 软约束、按主机名 maxSkew: 5 软约束，均只统计同一 Service/ReplicaSet/StatefulSet 下的 Pod。可通过 PodTopologySpread 插件参数覆盖：

apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration
profiles:
- schedulerName: default-scheduler
 pluginConfig:
 - name: PodTopologySpread
 args:
 defaultConstraints:
 - maxSkew: 1
 topologyKey: topology.kubernetes.io/zone
 whenUnsatisfiable: ScheduleAnyway
 defaultingType: List

目标	推荐做法	不推荐
跨可用区高可用	`topologySpreadConstraints`（zone，`DoNotSchedule`，`minDomains`）+ 按节点的软分布	硬 Pod 反亲和（域数不足即 Pending）
同节点最多一个副本	拓扑分布按 `hostname`、`maxSkew: 1`、`DoNotSchedule`；或硬反亲和 + `matchLabelKeys`	不带 `matchLabelKeys` 的硬反亲和（滚动更新易卡住）
必须使用特定硬件	`nodeAffinity` 硬约束 + 节点污点让其他 Pod 远离；GPU 场景优先用 DRA 按属性申请	仅靠 `nodeSelector` 而不加污点，普通 Pod 会挤占昂贵节点
与依赖服务就近	软 Pod 亲和（zone），配合 Service `trafficDistribution: PreferSameZone` 让流量也就近	硬亲和（依赖服务不可用时自身也无法调度）
偏好 Spot 节点但允许回退	`preferredDuringScheduling` 节点亲和 + 容忍 Spot 污点	硬约束到 Spot（容量不足时 Pending）
关键系统组件独占节点	节点污点 `NoSchedule` + 组件容忍 + `nodeAffinity`	仅靠亲和性（无法阻止其他 Pod 进入）

排查调度失败

Pod 因约束无法调度时会停留在 Pending，kubectl describe pod 的事件中会给出各插件的过滤结果：

Warning FailedScheduling 0/12 nodes are available: 3 node(s) didn't match pod topology spread constraints,
4 node(s) didn't match Pod's node affinity/selector, 5 node(s) had untolerated taint {dedicated: gpu}.
preemption: 0/12 nodes are available: 12 Preemption is not helpful for scheduling.

依据消息逐项核对标签、拓扑域与污点，通常即可定位。kubectl get nodes -L topology.kubernetes.io/zone 可快速查看拓扑分布，kubectl get pods -o wide --sort-by=.spec.nodeName 查看实际落点。

总结

nodeSelector 与节点亲和性回答"能去哪些节点"，Pod 亲和/反亲和回答"和谁在一起或分开"，拓扑分布约束回答"如何均匀铺开"。生产中最常见的高可用部署应以拓扑分布约束为主、辅以 matchLabelKeys 避免滚动更新干扰，并把硬约束留给真正不可妥协的场景；对 GPU 等异构资源，则逐步把选择逻辑从节点标签迁移到 DRA 的属性选择器。

参考文献

Pod 优先级与抢占

Jimmy Song — Sun, 01 Nov 2026 00:00:00 +0800

优先级决定了资源紧张时谁先上车、谁被请下车；用好它能保护关键业务，用错了会让集群陷入互相抢占的内耗。

集群资源总有耗尽的时候。没有优先级机制时，Pod 只能按到达顺序排队，一个低价值的批处理任务可能占着节点让核心服务的新副本永远 Pending。Pod 优先级（Priority）与抢占（Preemption）为此提供了两层能力：优先级决定调度队列中的先后顺序，抢占允许高优先级 Pod 在没有可用节点时驱逐低优先级 Pod 腾出空间。该机制自 v1.14 GA，是生产集群容量治理的基础设施。

PriorityClass

优先级通过集群级资源 PriorityClass 定义，Pod 用 spec.priorityClassName 引用，准入控制器据此填充 spec.priority 整数值：

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
 name: business-critical
value: 1000000
globalDefault: false
preemptionPolicy: PreemptLowerPriority  # 默认值；设为 Never 则不抢占
description: "面向客户的核心服务，资源不足时可抢占低优先级工作负载"
---
apiVersion: v1
kind: Pod
metadata:
 name: checkout-api
spec:
 priorityClassName: business-critical
 containers:
 - name: api
 image: checkout-api:2.3

字段语义如下：

字段	说明
`value`	32 位整数，越大优先级越高；用户可用范围上限为 10 亿（1000000000），更高的值保留给系统
`globalDefault`	为 `true` 时作为未指定 `priorityClassName` 的 Pod 的默认优先级；集群中只能有一个，且只影响之后创建的 Pod
`preemptionPolicy`	`PreemptLowerPriority`（默认，可抢占）或 `Never`（只排队不抢占）
`description`	供人阅读的用途说明

表 1: PriorityClass 字段说明

未设置 globalDefault 时，没有指定优先级类的 Pod 优先级为 0。PriorityClass 创建后 value 不可修改；删除后已有 Pod 保留其整数优先级，新 Pod 引用该名称会被拒绝。

内建系统优先级类

Kubernetes 预置两个只允许在 kube-system 命名空间使用的优先级类，值高于用户上限，保证控制面组件与关键插件不会被业务 Pod 抢占：

名称	值	用途
`system-node-critical`	2000001000	节点正常运行所必需：kube-proxy、CNI 插件、CSI 节点插件等
`system-cluster-critical`	2000000000	集群正常运行所必需：CoreDNS、metrics-server、云控制器等

表 2: 内建 PriorityClass

自建的 Operator、监控代理若确属关键组件，应在 kube-system 以外创建自己的高优先级类（如 platform-critical: 900000000），而不是直接复用系统类。

优先级对调度的影响

优先级首先影响调度队列：待调度 Pod 按优先级降序排列，高优先级 Pod 先被尝试调度。这意味着即便不发生抢占，关键服务的新副本也总是先于批处理任务拿到刚释放的资源。

其次影响kubelet 的准入与驱逐：节点资源压力驱逐时，kubelet 在用量超出请求的 Pod 中优先驱逐低优先级者；节点优雅关机（GracefulNodeShutdownBasedOnPodPriority）也按优先级分批终止 Pod，给关键 Pod 更长的宽限期。

抢占机制

当高优先级 Pod P 找不到任何可调度节点时，调度器进入抢占流程：

遍历节点，模拟"移除该节点上优先级低于 P 的 Pod"后 P 是否可调度，筛出候选节点
在候选节点中选择代价最小者：优先选择违反 PDB 最少、被驱逐 Pod 最高优先级最低、被驱逐 Pod 总优先级和最小、被驱逐 Pod 数量最少、最新启动 Pod 最晚的节点
只驱逐必要的 Pod（按优先级从低到高，直到 P 能放下为止），对这些 Pod 发起优雅删除
在 P 的 status.nominatedNodeName 记录提名节点，被抢占的 Pod 走正常的 terminationGracePeriodSeconds
节点资源释放后 P 重新进入调度；若此时出现了更合适的节点，P 仍可能落到其他节点，提名并非绑定

下图展示了抢占的决策过程：

P (priority 1000000) 无可用节点
 │
 ├─ 节点 A：驱逐 2 个 priority=100 的 Pod 可容纳 P，不违反 PDB
 ├─ 节点 B：驱逐 1 个 priority=500 的 Pod 可容纳 P，但违反 PDB
 └─ 节点 C：即使驱逐所有低优先级 Pod 也放不下
 → 选择节点 A，优雅删除 2 个 Pod，P.status.nominatedNodeName = A

关于抢占的几个重要事实：

抢占不会驱逐优先级等于或高于 P 的 Pod
抢占只在 P 完全无法调度时触发；若 P 因亲和性无法满足而非资源不足，抢占也无济于事，事件中会显示 Preemption is not helpful for scheduling
被抢占的 Pod 若由 Deployment 等控制器管理，会在别处重建；裸 Pod 则直接消失
调度器尽量尊重 PDB，但 PDB 不是硬保证：当所有候选节点都会违反 PDB 时，仍会选择违反最少的那个
v1.33 起 Beta 的异步抢占（SchedulerAsyncPreemption）把驱逐 API 调用移出调度主循环，避免大规模抢占阻塞其他 Pod 的调度

非抢占优先级

preemptionPolicy: Never 定义的优先级类让 Pod 在队列中享受高优先级，但不会抢占任何运行中的 Pod。这对批处理与数据科学场景尤为重要：一个高优先级的训练任务应该比其他任务先拿到空闲 GPU，但不该把正在运行的长任务踢掉而浪费其已完成的计算。

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
 name: high-priority-nonpreempting
value: 500000
preemptionPolicy: Never
description: "高优先级排队但不抢占，用于批处理作业"

非抢占 Pod 自身仍可能被更高优先级的可抢占 Pod 驱逐。

与其他机制的交互

机制	交互方式
PodDisruptionBudget	抢占尽量不违反 PDB，但不保证；PDB 的 `DisruptionTarget` 条件会标记被抢占的 Pod，Job 可据此不计入重试
优雅终止	被抢占 Pod 按 `terminationGracePeriodSeconds` 优雅退出，调度器会等待；因此抢占不是瞬时的
ResourceQuota	`scopeSelector` 可按优先级类限制配额，例如禁止普通命名空间使用高优先级类
节点压力驱逐	kubelet 驱逐与调度器抢占互相独立；两者都参考优先级
Kueue / 批调度器	Kueue 在配额层面实现基于优先级的排队与抢占（`preemption.reclaimWithinCohort`），通常把 Job 设为非抢占优先级，避免核心调度器与 Kueue 双重抢占
集群自动扩缩容	Cluster Autoscaler 可配置 `--expendable-pods-priority-cutoff`，低于该优先级的 Pending Pod 不触发扩容；Karpenter 的调度模拟同样尊重优先级

表 3: 优先级与抢占同其他机制的交互

用配额限制优先级类的使用

若不加限制，任何用户都可以给自己的 Pod 指定最高优先级，抢占机制便失去意义。ResourceQuota 的 scopeSelector 可以把优先级类的使用权限定在特定命名空间：

apiVersion: v1
kind: ResourceQuota
metadata:
 name: critical-priority-quota
 namespace: payments  # 只有该命名空间可用 business-critical
spec:
 hard:
 pods: "50"
 scopeSelector:
 matchExpressions:
 - operator: In
 scopeName: PriorityClass
 values: [business-critical]

配合 API Server 的 --admission-control-config-file 中 ResourceQuota 插件的 limitedResources 配置，可以要求"凡使用 business-critical 的 Pod 所在命名空间必须存在覆盖该优先级类的配额"，未配置配额的命名空间将无法使用该类。更灵活的做法是用 ValidatingAdmissionPolicy 按命名空间标签校验 priorityClassName。

实践建议

为集群设计 3 – 5 个层次清晰的优先级类（如 platform-critical、business-critical、default、batch、best-effort），用 globalDefault 把未声明的 Pod 归入 default
批处理与训练任务使用 preemptionPolicy: Never 的类，由 Kueue 等排队系统负责配额层面的抢占
为所有关键工作负载配置 PDB，并把 unhealthyPodEvictionPolicy 设为 AlwaysAllow，降低抢占对可用性的影响
用 ResourceQuota 的 scopeSelector 或准入策略限制高优先级类的使用范围
监控 scheduler_preemption_attempts_total 与 scheduler_preemption_victims 指标，抢占频繁意味着容量规划不足，而不是靠抢占常态化运转
设计 terminationGracePeriodSeconds 时考虑被抢占的可能，让应用能在宽限期内完成检查点保存

总结

PriorityClass 让集群在资源紧张时有章可循：调度队列按优先级排序保证关键服务先行，抢占机制在必要时为其腾出空间，非抢占优先级则为批处理提供"先排队、不打断"的折中。优先级必须与 PDB、ResourceQuota、排队系统配合使用，并以容量规划为前提——抢占是最后的安全阀，而不是日常的调度手段。

参考文献

服务质量等级（QoS）

Jimmy Song — Sat, 21 May 2022 00:00:00 +0800

合理配置 QoS 等级是保障 Kubernetes 集群资源高效利用与关键业务稳定运行的基础。

在 Kubernetes 中，QoS（Quality of Service，服务质量等级）是作用于 Pod 的核心机制。Kubernetes 会根据容器的资源配置自动为 Pod 分配 QoS 等级，这直接影响调度优先级和资源回收策略。

QoS 等级分类

Kubernetes 将 Pod 的 QoS 等级分为三类，分别适用于不同业务场景。下表总结了各等级的特征和适用场景。

等级	配置要求	适用场景
Guaranteed	每个容器都设置 `limits` 和 `requests`，且值相等	关键业务应用
Burstable	至少有一个容器设置了 `requests` 或 `limits`，但不完全相等	一般业务、开发测试
BestEffort	所有容器都未设置 `limits` 和 `requests`	非关键、批处理任务

表 1: Kubernetes QoS 等级对比

Guaranteed（保证级）

Guaranteed 等级要求 Pod 中每个容器都同时设置 CPU 和内存的 limits 与 requests，且两者数值完全一致。

配置示例：

spec:
 containers:
 - name: app
 resources:
 limits:
 cpu: 100m
 memory: 128Mi
 requests:
 cpu: 100m
 memory: 128Mi

Burstable（突发级）

Burstable 等级适用于部分资源有保障、部分可突发的场景。只要有一个容器设置了 requests 或 limits，但不满足 Guaranteed 的全部要求，即为 Burstable。

配置示例：

spec:
 containers:
 - name: app
 resources:
 limits:
 memory: 180Mi
 requests:
 memory: 100Mi
 cpu: 50m

BestEffort（尽力而为级）

BestEffort 等级适用于资源要求最低的场景。所有容器都未设置任何 limits 或 requests，即为 BestEffort。

配置示例：

spec:
 containers:
 - name: app
 resources: {}

QoS 的作用机制

QoS 等级不仅影响调度优先级，还决定了资源回收的顺序。合理配置 QoS，有助于提升集群整体资源利用率和业务弹性。

调度优先级

Guaranteed：最高优先级，优先分配到资源充足的节点
Burstable：中等优先级，满足基本资源需求后调度
BestEffort：最低优先级，通常调度到剩余资源较多的节点

资源回收策略

当节点资源不足时，kubelet 首先依据 Pod 的实际用量是否超出 requests 以及 PriorityClass 决定驱逐顺序，QoS 等级在其中起到间接作用：

首先回收 BestEffort 级别的 Pod（没有 requests，任何用量都视为超额）
其次回收超出 requests 资源使用量的 Burstable 级别 Pod
最后回收 Guaranteed 级别的 Pod（仅在系统组件需要资源时）

在内核层面，kubelet 还会为不同 QoS 的容器设置不同的 oom_score_adj：Guaranteed 为 -997，BestEffort 为 1000，Burstable 介于两者之间并随 requests 占比变化。节点触发内核 OOM 时，分值越高的进程越先被杀死。

cgroup v2 与内存 QoS

Kubernetes 自 v1.25 起将 cgroup v2 支持 GA，并在 v1.31 把 cgroup v1 置于维护模式，新的资源管理特性只面向 cgroup v2。v1.35 起 cgroup v1 被正式弃用，kubelet 默认拒绝在仅有 cgroup v1 的节点上启动（可用 failCgroupV1: false 临时放行）。在 cgroup v2 节点上，kubelet 可启用内存 QoS（特性门控 MemoryQoS，v1.37 Beta 并默认开启）：把 requests.memory 映射为 memory.min 以保护 Guaranteed/Burstable 容器的内存不被回收，并通过 memory.high 在接近 limits 时提前触发限流，而不是直接 OOM。

与原地资源调整的关系

Pod 的 QoS 等级在创建时确定且不可变。自 v1.35 起 GA 的原地资源调整允许修改运行中容器的 requests/limits，但 API Server 会拒绝导致 QoS 等级变化的调整：Guaranteed Pod 调整后必须仍保持 requests == limits，Burstable Pod 不能被调整为完全不设资源的 BestEffort。

交换分区

v1.34 起 kubelet 对 Linux swap 的支持进入 GA（NodeSwap），默认行为为 NoSwap，且仅支持 cgroup v2 节点。管理员可在 kubelet 配置中设置 memorySwap.swapBehavior: LimitedSwap，此时仅 Burstable 级别的 Pod 可以按其内存 requests 占节点内存的比例使用 swap；Guaranteed 与 BestEffort Pod 均不允许使用 swap，以保证高优先级工作负载的性能可预测。

查看 Pod 的 QoS 等级

可以通过以下命令查看 Pod 的 QoS 等级：

kubectl get pod <pod-name> -o yaml | grep qosClass

或使用 describe 命令：

kubectl describe pod <pod-name>

最佳实践

生产环境关键应用建议使用 Guaranteed 等级，确保资源稳定性
开发测试环境可采用 Burstable 等级，提高资源利用率
批处理任务适合使用 BestEffort 等级，充分利用集群闲置资源
合理设置资源请求，避免设置过高的 requests 值造成资源浪费
为新节点统一启用 cgroup v2（主流发行版默认已启用），避免同一集群混用 v1/v2 导致资源语义不一致

总结

Kubernetes QoS 机制通过资源配置自动分级，实现了资源分配的弹性与业务优先级保障。合理利用 QoS 等级，有助于提升集群资源利用率、保障关键业务稳定，并优化整体运维体验。

参考文献

ResourceQuota 与 LimitRange：命名空间级资源治理

Jimmy Song — Sun, 01 Nov 2026 00:00:00 +0800

没有配额的多租户集群只是"大家一起用的集群"；ResourceQuota 划定每个团队的总盘子，LimitRange 保证每个 Pod 都带着合理的资源声明进来。

Kubernetes 用命名空间划分团队与环境，但命名空间本身并不限制资源使用——任何人都可以在自己的命名空间里创建无限多的 Pod、申请无限多的 CPU。ResourceQuota 与 LimitRange 这两个核心 API 对象补上了这块缺口：前者作用于命名空间总量，后者作用于单个对象。它们由同名的内建准入控制器实施，在对象创建或更新时同步校验，是多租户治理、成本控制与防止"吵闹邻居"的基础。

ResourceQuota

ResourceQuota 为一个命名空间声明若干资源的硬上限，准入控制器在每次创建对象时累计已用量并拒绝超额请求。一个命名空间可以有多个 ResourceQuota，所有配额必须同时满足。

可限制的资源

类别	资源名示例	说明
计算资源	`requests.cpu`、`requests.memory`、`limits.cpu`、`limits.memory`、`cpu`（等价于 `requests.cpu`）、`memory`	统计所有非终态 Pod 的容器资源之和；Init 容器按最大值计入，Sidecar 容器按累加计入
扩展资源	`requests.nvidia.com/gpu`、`requests.hugepages-2Mi`	扩展资源只能限制 `requests.` 前缀（扩展资源不允许超售，requests 必等于 limits）
存储	`requests.storage`、`persistentvolumeclaims`、`<storageclass>.storageclass.storage.k8s.io/requests.storage`、`<storageclass>.storageclass.storage.k8s.io/persistentvolumeclaims`、`requests.ephemeral-storage`	可按 StorageClass 分别限额，例如限制高性能 SSD 的总容量
对象数量	`pods`、`services`、`services.loadbalancers`、`services.nodeports`、`configmaps`、`secrets`、`persistentvolumeclaims`、`replicationcontrollers`、`resourcequotas`；通用语法 `count/<resource>.<group>`，如 `count/deployments.apps`、`count/jobs.batch`、`count/widgets.example.com`	对象数量配额可以作用于任何内建或自定义资源

表 1: ResourceQuota 可限制的资源类型

以下示例为一个团队命名空间设置了典型配额：

apiVersion: v1
kind: ResourceQuota
metadata:
 name: team-a-quota
 namespace: team-a
spec:
 hard:
 requests.cpu: "40"
 requests.memory: 160Gi
 limits.cpu: "80"
 limits.memory: 320Gi
 requests.nvidia.com/gpu: "8"
 requests.storage: 2Ti
 fast-ssd.storageclass.storage.k8s.io/requests.storage: 500Gi
 pods: "200"
 services.loadbalancers: "2"
 count/deployments.apps: "50"
 count/jobs.batch: "100"

kubectl describe quota -n team-a 可查看每项资源的已用/上限；kubectl get quota -o yaml 的 status.used 字段同样包含实时用量。

配额与资源请求的强制关系

一旦命名空间对 requests.cpu、requests.memory、limits.cpu 或 limits.memory 任一项设置了配额，该命名空间内所有新建 Pod 的每个容器都必须显式声明对应的 requests/limits，否则会被拒绝：

Error from server (Forbidden): pods "web" is forbidden: failed quota: team-a-quota:
must specify limits.cpu for: app; limits.memory for: app

这正是 LimitRange 存在的理由之一——用默认值自动补齐，避免每个开发者都手写资源声明。

配额作用域

scopes 与 scopeSelector 让一个配额只统计特定类别的 Pod，从而实现差异化治理：

作用域	匹配的 Pod	可限制的资源
`Terminating` / `NotTerminating`	设置了 / 未设置 `activeDeadlineSeconds` 的 Pod（通常对应 Job 与长期服务）	计算资源、`pods`
`BestEffort` / `NotBestEffort`	QoS 为 / 不为 BestEffort 的 Pod	BestEffort 作用域只能限制 `pods`
`PriorityClass`	通过 `scopeSelector` 按优先级类名匹配（`In`/`NotIn`/`Exists`/`DoesNotExist`）	计算资源、`pods`
`CrossNamespacePodAffinity`	使用了跨命名空间 Pod 亲和/反亲和（`namespaces` 或 `namespaceSelector`）的 Pod	`pods`

表 2: ResourceQuota 作用域

以下示例限制 team-a 中 BestEffort Pod 最多 20 个、批处理（Terminating）Pod 最多占用 10 核，并禁止使用跨命名空间亲和性：

apiVersion: v1
kind: ResourceQuota
metadata:
 name: besteffort-quota
 namespace: team-a
spec:
 hard:
 pods: "20"
 scopes: [BestEffort]
---
apiVersion: v1
kind: ResourceQuota
metadata:
 name: batch-quota
 namespace: team-a
spec:
 hard:
 requests.cpu: "10"
 scopes: [Terminating]
---
apiVersion: v1
kind: ResourceQuota
metadata:
 name: no-cross-ns-affinity
 namespace: team-a
spec:
 hard:
 pods: "0"
 scopeSelector:
 matchExpressions:
 - scopeName: CrossNamespacePodAffinity
 operator: Exists

CrossNamespacePodAffinity 作用域配合 API Server 准入配置中的 limitedResources，可以在集群层面要求所有使用跨命名空间亲和的 Pod 必须被配额覆盖，防止租户通过反亲和"霸占"其他团队的节点。

对象配额与 CRD

count/<resource>.<group> 语法对自定义资源同样有效，这让平台团队可以限制每个租户能创建多少 Application、Certificate 或 InferencePool：

spec:
 hard:
 count/certificates.cert-manager.io: "20"
 count/inferencepools.inference.networking.k8s.io: "5"

LimitRange

LimitRange 作用于命名空间内的单个 Pod、容器或 PVC，提供三种能力：为未声明资源的容器填充默认 requests/limits、限制单个对象的最小/最大值、约束 limits 与 requests 的比例。

apiVersion: v1
kind: LimitRange
metadata:
 name: team-a-limits
 namespace: team-a
spec:
 limits:
 - type: Container
 default: # 未声明 limits 时的默认值
 cpu: "500m"
 memory: 512Mi
 defaultRequest: # 未声明 requests 时的默认值
 cpu: "100m"
 memory: 128Mi
 min:
 cpu: "50m"
 memory: 64Mi
 max:
 cpu: "8"
 memory: 32Gi
 maxLimitRequestRatio: # limits 不得超过 requests 的 4 倍，抑制过度超售
 cpu: "4"
 memory: "2"
 - type: Pod
 max: # 单个 Pod 所有容器之和的上限
 cpu: "16"
 memory: 64Gi
 - type: PersistentVolumeClaim
 min:
 storage: 1Gi
 max:
 storage: 1Ti

LimitRange 的生效规则需要特别留意：

默认值只在容器完全未声明对应字段时注入；若只声明了 limits 而没有 requests，Kubernetes 会把 requests 设为与 limits 相同，而不是使用 defaultRequest
校验与注入发生在准入阶段，LimitRange 的修改不影响已存在的 Pod
min/max 同时对注入后的默认值生效，因此 default 必须落在 [min, max] 区间内，否则所有未声明资源的 Pod 都会被拒绝
type: Pod 的约束按 Pod 内所有容器（含 Sidecar）之和计算
一个命名空间可以有多个 LimitRange，但多个 LimitRange 对同一字段设置不同默认值时行为未定义，应避免

ResourceQuota 与 LimitRange 的协作

两者通常成对出现：LimitRange 保证每个 Pod 都带着合理的资源声明进入集群，ResourceQuota 则把这些声明累加起来与团队总盘子比对。一个常见的落地模式是命名空间供给流程（GitOps 或 Operator）在创建命名空间时同时下发三件套——ResourceQuota、LimitRange 与默认 NetworkPolicy：

apiVersion: v1
kind: Namespace
metadata:
 name: team-a
 labels:
 pod-security.kubernetes.io/enforce: baseline
 team: a
---
apiVersion: v1
kind: LimitRange
metadata:
 name: defaults
 namespace: team-a
spec:
 limits:
 - type: Container
 defaultRequest: {cpu: 100m, memory: 128Mi}
 default: {cpu: 1, memory: 1Gi}
---
apiVersion: v1
kind: ResourceQuota
metadata:
 name: compute
 namespace: team-a
spec:
 hard:
 requests.cpu: "20"
 requests.memory: 64Gi
 limits.cpu: "40"
 limits.memory: 128Gi
 pods: "100"

对集群级的层次化配额（例如"部门 → 团队"两级、团队之间可借用闲置配额），核心 API 没有提供，需要借助 Kueue 的 ClusterQueue/Cohort（面向批处理作业）、Hierarchical Namespace Controller 或 Capsule 等多租户项目（见多租户与虚拟集群）。

常见问题

现象	原因	处理
Deployment 副本数不足但没有 Pending Pod	ReplicaSet 创建 Pod 被配额拒绝，错误只出现在 ReplicaSet 事件中	`kubectl describe rs` 查看 `FailedCreate` 事件
`must specify limits.cpu`	命名空间有计算配额但 Pod 未声明资源	添加 LimitRange 默认值或在清单中声明
已删除 Pod 仍占用配额	配额控制器异步同步，终态 Pod 不计入但有短暂延迟；带 finalizer 的 Pod 未真正删除	等待同步或检查 finalizer
GPU 配额设置 `limits.nvidia.com/gpu` 无效	扩展资源只支持 `requests.` 前缀	改为 `requests.nvidia.com/gpu`
PVC 扩容被拒	`requests.storage` 配额按 PVC 请求总量计算，扩容也计入	调整配额或清理闲置 PVC
Job 的 Pod 因 `Terminating` 作用域配额被拒	设置了 `activeDeadlineSeconds` 的 Pod 被归入 Terminating 作用域	检查作用域配额是否合理

表 3: 配额相关的常见问题与处理

实践建议

所有业务命名空间都应有 LimitRange 默认值，避免 BestEffort Pod 泛滥导致节点 OOM
配额以 requests 为主、limits 为辅：调度与节点容量规划依据 requests，limits 配额主要用于抑制超售比例
按 StorageClass 单独限制昂贵存储的容量，按 services.loadbalancers 限制云负载均衡器数量以控制成本
用 PriorityClass 作用域配额防止租户滥用高优先级类
把配额用量（kube_resourcequota 指标）接入监控与告警，用量长期低于 50% 或接近 100% 都应触发容量评审
配额变更通过 GitOps 审批，避免在集群中手工调整

总结

ResourceQuota 与 LimitRange 是 Kubernetes 命名空间多租户的基石：LimitRange 在对象层面注入默认值并限定范围，ResourceQuota 在命名空间层面累计并设置上限，作用域机制则让配额可以按 QoS、优先级与作业类型差异化施策。二者配合 Pod 安全准入与 NetworkPolicy，构成了命名空间级隔离的"三件套"；更复杂的层次化与可借用配额，则交由 Kueue 等上层项目实现。

参考文献

kubelet 节点资源管理：资源预留、节点压力驱逐、垃圾回收与资源管理器

Jimmy Song — Sun, 01 Nov 2026 00:00:00 +0800

调度器只看"节点声称有多少资源"，而节点能不能真的兑现这些承诺，取决于 kubelet 如何预留、如何驱逐、如何在 NUMA 之间摆放 CPU 和内存。

Kubernetes 的资源模型分两层：调度器在控制面按节点的可分配资源（Allocatable）做全局决策，kubelet 在节点侧负责把这些决策落实到 cgroup，并在资源真正紧张时保护节点不被压垮。本文聚焦后者——kubelet 的资源预留、节点压力驱逐、垃圾回收、优雅关机以及 CPU/内存/拓扑三大资源管理器，这些配置决定了节点的稳定性，也是 AI 训练与低延迟应用性能调优的关键。

Node Allocatable 与资源预留

节点的物理容量（Capacity）不能全部交给 Pod：操作系统守护进程、kubelet、容器运行时都需要资源，还要为驱逐留出缓冲。kubelet 据此计算 Allocatable：

Allocatable = Capacity − kube-reserved − system-reserved − eviction-threshold

三项预留通过 KubeletConfiguration 声明：

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
kubeReserved: # 为 kubelet、容器运行时等 Kubernetes 系统组件预留
 cpu: "500m"
 memory: "1Gi"
 ephemeral-storage: "5Gi"
 pid: "1000"
systemReserved: # 为 sshd、journald 等操作系统守护进程预留
 cpu: "500m"
 memory: "1Gi"
 pid: "1000"
evictionHard: # 硬驱逐阈值，同样从 Allocatable 中扣除
 memory.available: "500Mi"
 nodefs.available: "10%"
enforceNodeAllocatable: [pods]  # 只对 Pod 的 cgroup 强制执行 Allocatable 上限

enforceNodeAllocatable 默认只包含 pods，即 kubelet 为所有 Pod 所在的顶层 cgroup（kubepods）设置资源上限等于 Allocatable。若把 kube-reserved/system-reserved 也加入列表，kubelet 会为对应的 cgroup（需通过 kubeReservedCgroup/systemReservedCgroup 指定）设置上限；这会在系统进程超出预留时直接 OOM 它们，官方建议只有在非常清楚各守护进程实际用量时才启用。

实际用量可用 kubectl describe node 查看 Capacity/Allocatable 两组值，以及 Allocated resources 中 Pod 请求的占用比例。云厂商托管节点池通常已按节点规格预设了阶梯式的预留公式，自建集群则需要依据节点上系统进程的实际用量压测后确定。

节点压力驱逐

当节点的内存、磁盘、inode 或 PID 低于阈值时，kubelet 会主动终止 Pod 回收资源，这一过程称为节点压力驱逐（Node-pressure Eviction）。它与 API 发起的驱逐（kubectl drain、抢占）不同：不经过 API Server 的 Eviction 子资源，因此不受 PDB 约束，Pod 会直接被置为 Failed 并带上 DisruptionTarget 条件。

驱逐信号

信号	含义	说明
`memory.available`	节点可用内存（Capacity − 工作集）	基于 cgroup 的 `memory.workingSet`，不含 `active_file` 页缓存
`nodefs.available` / `nodefs.inodesFree`	kubelet 根目录所在文件系统（日志、emptyDir、可写层）的可用空间与 inode
`imagefs.available` / `imagefs.inodesFree`	容器运行时存放镜像的文件系统	与 nodefs 同盘时两者等价
`containerfs.available` / `containerfs.inodesFree`	容器可写层所在文件系统（v1.31 起 Beta 的分离磁盘场景）	`KubeletSeparateDiskGC` 允许镜像与可写层分别位于不同磁盘
`pid.available`	节点剩余可用 PID 数	防止 fork 炸弹耗尽进程号

表 1: kubelet 驱逐信号

硬阈值与软阈值

硬阈值（evictionHard）一旦触及立即驱逐，Pod 不享受宽限期。Linux 节点的默认值为：

evictionHard:
 memory.available: "100Mi"
 nodefs.available: "10%"
 imagefs.available: "15%"
 nodefs.inodesFree: "5%"
 imagefs.inodesFree: "5%"

需要特别注意：只要修改了其中任何一项，其余项的默认值都会被置为零而不是继承默认，必须完整列出所有阈值；或者在 KubeletConfiguration 中设置 mergeDefaultEvictionSettings: true，让未指定的信号继承默认值。

软阈值（evictionSoft）触及后需持续超过 evictionSoftGracePeriod 才触发驱逐，且 Pod 可获得最多 evictionMaxPodGracePeriod 的终止宽限，适合把驱逐前移到更温和的水位：

evictionSoft:
 memory.available: "1Gi"
 nodefs.available: "15%"
evictionSoftGracePeriod:
 memory.available: "1m30s"
 nodefs.available: "2m"
evictionMaxPodGracePeriod: 60
evictionMinimumReclaim: # 每次驱逐至少回收的量，避免在阈值附近反复驱逐
 memory.available: "500Mi"
 nodefs.available: "1Gi"
evictionPressureTransitionPeriod: 5m  # 节点条件从 Pressure 恢复的最短观察期，防止抖动

Pod 选择顺序

kubelet 驱逐时先尝试回收节点级资源（删除已退出容器、未使用镜像），仍不足再按以下顺序选择 Pod：

用量是否超过 requests：超出请求的 Pod 排在前面；BestEffort Pod 没有 requests，任何用量都视为超额
Pod 优先级：同为超额的 Pod 中，优先级低者先被驱逐
超出量相对 requests 的比例：超出越多越先驱逐

因此 QoS 等级只是间接影响驱逐顺序：Guaranteed 与 Burstable Pod 只要用量不超过 requests，就不会因其他 Pod 的内存压力而被驱逐（系统守护进程超出预留的极端情况除外）。静态 Pod 与 system-node-critical 优先级的 Pod 同样可能被驱逐，关键组件应设置准确的 requests 并避免超额使用。

驱逐后的 Pod 处于 Failed 状态并保留在 API 中供排障，由控制器在其他节点重建；节点会带上 MemoryPressure/DiskPressure/PIDPressure 条件及对应污点，调度器在条件清除前不再向其调度 BestEffort（内存压力）或任何新 Pod（磁盘压力）。

与内核 OOM 的关系

驱逐是 kubelet 的主动行为，默认每 10 秒评估一次；若内存消耗在两次评估之间急剧飙升，内核 OOM Killer 会先于 kubelet 介入。OOM Killer 依据 oom_score_adj 选择牺牲者，kubelet 为不同 QoS 的容器预设了该值：Guaranteed 为 −997、BestEffort 为 1000、Burstable 按 requests 占比在 2 – 999 之间。容器被 OOM 杀死后按 restartPolicy 原地重启，不会迁移到其他节点。v1.37 起 Beta 并默认开启的内存 QoS（cgroup v2 的 memory.min/memory.high）可以在接近 limits 时提前限流，减少硬 OOM。

垃圾回收

kubelet 定期清理节点上不再使用的镜像与容器，防止磁盘耗尽。

镜像垃圾回收

基于磁盘用量阈值：当镜像文件系统使用率超过 imageGCHighThresholdPercent（默认 85%）时，按最近最少使用的顺序删除未被任何容器引用的镜像，直到降至 imageGCLowThresholdPercent（默认 80%）。v1.35 GA 的 imageMaximumGCAge 额外提供基于时间的回收：超过该时长未使用的镜像即使磁盘充足也会被删除。

imageGCHighThresholdPercent: 85
imageGCLowThresholdPercent: 80
imageMinimumGCAge: 2m  # 镜像拉取后至少保留的时间
imageMaximumGCAge: 168h  # 一周未使用即回收（v1.35 GA，0 表示禁用）

运行大模型镜像的节点应结合镜像卷的使用情况调高阈值或禁用基于时间的回收，避免数十 GB 的模型层被反复拉取。

容器垃圾回收

已退出的容器实例按 maxPerPodContainerCount（每个 Pod 每个容器保留的已退出实例数，默认 1）与 maxContainerCount（节点总数，默认 −1 不限）清理，保留的实例用于 kubectl logs --previous 查看崩溃日志。

节点优雅关机

GracefulNodeShutdown（v1.21 起 Beta 并默认开启）让 kubelet 通过 systemd inhibitor 锁拦截节点关机，在 shutdownGracePeriod 内按优先级分批终止 Pod：先终止普通 Pod，为 shutdownGracePeriodCriticalPods 保留的时间内再终止关键 Pod。

shutdownGracePeriod: 60s
shutdownGracePeriodCriticalPods: 20s
# 或按优先级类精细分配（GracefulNodeShutdownBasedOnPodPriority）
shutdownGracePeriodByPodPriority:
- priority: 2000000000 # system-cluster-critical 及以上
 shutdownGracePeriodSeconds: 20
- priority: 1000000
 shutdownGracePeriodSeconds: 30
- priority: 0
 shutdownGracePeriodSeconds: 60

这对使用 Spot/抢占式实例的集群尤为重要：云厂商的回收通知通常只给 30 – 120 秒，优雅关机保证应用能在这一窗口内完成检查点与连接排空。

资源管理器：CPU、内存与拓扑

默认情况下，Linux 的 CFS 调度器会让容器进程在所有 CPU 核之间漂移，内存也可能分配在任意 NUMA 节点上。对数据库、网络功能虚拟化、分布式训练等延迟敏感或带宽敏感的负载，跨 NUMA 访问内存与 PCIe 设备会带来显著的性能抖动。kubelet 提供三个协同工作的资源管理器解决这一问题，它们都只对 Guaranteed QoS 且 requests 为整数核 的容器生效。

管理器	配置字段	作用	状态
CPU 管理器	`cpuManagerPolicy: static`	为符合条件的容器分配独占 CPU 核（cpuset），其余容器共享剩余核	GA（v1.26），策略选项 GA（v1.33）
内存管理器	`memoryManagerPolicy: Static`	保证容器的内存与 hugepages 来自指定 NUMA 节点	GA（v1.32）
拓扑管理器	`topologyManagerPolicy`	协调 CPU、内存、设备插件/DRA 设备的 NUMA 亲和性，使它们落在同一 NUMA 节点	GA（v1.27），策略选项 GA（v1.32）

表 2: kubelet 资源管理器

典型的高性能节点配置如下：

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
cpuManagerPolicy: static
cpuManagerPolicyOptions:
 full-pcpus-only: "true" # 只分配完整物理核，避免超线程兄弟核被其他容器占用
 distribute-cpus-across-numa: "true"
reservedSystemCPUs: "0-1" # 系统与 kubelet 固定使用的核，与 kubeReserved/systemReserved 的 cpu 互斥
memoryManagerPolicy: Static
reservedMemory:
- numaNode: 0
 limits:
 memory: 1Gi
topologyManagerPolicy: single-numa-node
topologyManagerScope: pod  # 以 Pod 为单位对齐，而非逐容器
topologyManagerPolicyOptions:
 prefer-closest-numa-nodes: "true"

拓扑管理器的四种策略决定了对齐失败时的行为：

none：不做对齐（默认）
best-effort：尽量对齐，失败也准入
restricted：要求首选对齐（如单 NUMA）可满足，否则拒绝 Pod（TopologyAffinityError）
single-numa-node：要求所有资源来自同一个 NUMA 节点，否则拒绝

拓扑管理器通过 Hint Provider 接口从 CPU 管理器、内存管理器和设备插件收集每种资源可用的 NUMA 位掩码，再求交集选出共同的 NUMA 节点。DRA 驱动可以在 ResourceSlice 中以设备属性的形式暴露 NUMA 位置，但 DRA 与拓扑管理器的原生集成仍在 WG Device Management 推进中，当前需要由驱动或调度器插件自行处理对齐。topologyManagerScope: pod 让多容器 Pod（如训练进程 + RDMA Sidecar）整体落在同一 NUMA 节点，是 AI 训练节点的推荐设置。

与原地资源调整、Pod 级资源的关系

使用静态 CPU 管理器或内存管理器策略的 Pod 目前不能原地调整资源（独占资源的在线调整在 v1.37 仍为 Alpha）。Pod 级资源（spec.resources）与资源管理器的对齐需要开启 PodLevelResourceManagers（v1.37 Beta，默认关闭），否则管理器仍按容器级资源计算。

实践建议

所有节点显式配置 kubeReserved/systemReserved 与完整的 evictionHard，并开启 mergeDefaultEvictionSettings 避免漏项
为关键 Pod 设置准确的 requests 并避免运行时超额，这是免于节点压力驱逐的唯一保证
增加 evictionSoft 与 evictionMinimumReclaim，让驱逐发生在仍有余量时并一次回收足够资源
Spot 节点开启优雅关机并按优先级分配宽限期
延迟敏感与 AI 节点池单独配置静态 CPU/内存管理器与 single-numa-node 拓扑策略，普通节点池保持默认以免浪费核
监控 kubelet_evictions、kubelet_pod_resources_endpoint_*、container_oom_events_total 等指标，驱逐与 OOM 频发意味着预留或 requests 需要修正

总结

kubelet 的资源管理决定了节点能否兑现调度器的承诺：预留模型划出系统与 Pod 的边界，驱逐机制在压力下有序牺牲低优先级与超额 Pod，垃圾回收与优雅关机维护节点的长期健康，CPU/内存/拓扑管理器则为高性能负载提供 NUMA 级的确定性。理解这些机制，才能把"节点有多少资源"与"应用实际能用多少"真正对齐。

参考文献

Horizontal Pod Autoscaling

Jimmy Song — Sat, 21 May 2022 00:00:00 +0800

HPA（Horizontal Pod Autoscaler）让 Kubernetes 集群中的 Pod 数量能够根据负载自动扩缩容，实现资源的弹性管理，是自动化运维的核心能力之一。

应用的资源使用率通常都有高峰和低谷的时候，如何削峰填谷，提高集群的整体资源利用率，让 service 中的 Pod 个数自动调整呢？这就有赖于 Horizontal Pod Autoscaling 了，顾名思义，使 Pod 水平自动缩放。

HPA 是最能体现 Kubernetes 相比传统运维价值的功能之一，不再需要手动扩容，真正实现了自动化运维，还可以基于自定义指标进行扩缩容。

概述

HPA 属于 Kubernetes 中的 autoscaling SIG（Special Interest Group），其下有两个主要特性：

版本演进

Kubernetes HPA 的功能随着版本不断演进，主要里程碑如下：

Kubernetes 1.2：引入 HPA 机制
Kubernetes 1.6：从 kubelet 获取指标转为通过 API server、Heapster 或 kube-aggregator 获取，并支持自定义指标
Kubernetes 1.8：Heapster 弃用，资源指标统一由 metrics-server 通过 metrics.k8s.io 提供
Kubernetes 1.23：autoscaling/v2 API GA，v2beta2 已于 1.26 移除
Kubernetes 1.27：支持按容器粒度的资源指标（ContainerResource）GA
Kubernetes 1.37：metrics.k8s.io API 规范在 Beta 近九年后定义 v1 版本（metrics-server 需升级到提供 v1 的版本才会注册）；HPA 扩缩容容差（默认 10%）可在单个 HPA 对象上通过 behavior.scaleUp/scaleDown.tolerance 配置（v1.33 Alpha，v1.37 GA）；缩容到零（minReplicas: 0，仅限自定义/外部指标）进入 Beta 并默认开启

架构原理

Horizontal Pod Autoscaling 适用于任何实现了 scale 子资源的工作负载，包括 Deployment、ReplicaSet、StatefulSet 以及启用了 scale 子资源的自定义资源（DaemonSet 除外），由 API server 和 controller 共同实现。

下图展示了 HPA 的整体架构：

图 1: HPA 示意图

工作机制

HPA 通过控制循环实现自动扩缩容，循环周期由 controller manager 的 --horizontal-pod-autoscaler-sync-period 参数指定（默认 30 秒）。

每个周期内，controller manager 会执行以下步骤：

查询指标：从 resource metric API 或自定义 metric API 获取指标。
计算利用率：
- Resource metrics：计算与容器 resource request 的百分比。
- 自定义 metrics：使用原始值进行比较。
- Object metrics：获取单个对象的指标与目标值比较。
计算副本数：基于所有指标计算新的副本数，取最大值。
执行扩缩容：通过 Scale 子资源调整副本数。

注意

如果 Pod 的容器没有设置 resource request，则无法定义 CPU 利用率，HPA 不会对该指标采取任何操作。

支持的指标类型

Kubernetes HPA 支持多种指标类型，具体如下：

API 版本对比

下表对比了不同 API 版本下 HPA 支持的指标类型。

API 版本	支持的指标
autoscaling/v1	CPU 利用率
autoscaling/v2	CPU、内存、自定义指标、多指标组合

表 1: HPA 不同 API 版本支持的指标类型

指标获取方式

HPA 控制器可通过以下两种方式获取指标：

直接 Heapster 访问：通过 API 服务器的服务代理查询 Heapster。
REST 客户端访问：通过 metrics API 获取指标。

基本使用

在实际运维中，HPA 的使用非常灵活，支持命令行和 YAML 配置两种方式。

kubectl 命令

以下是常用的 HPA 管理命令：

# 基本管理命令
kubectl create hpa
kubectl get hpa
kubectl describe hpa
kubectl delete hpa

# 快速创建 HPA
kubectl autoscale deployment nginx --min=2 --max=10 --cpu-percent=80

命令参数说明

kubectl autoscale 命令的参数说明如下：

kubectl autoscale (-f FILENAME | TYPE NAME | TYPE/NAME) [--min=MINPODS] --max=MAXPODS [--cpu-percent=CPU] [flags]

示例：为 Deployment foo 创建 autoscaler，CPU 利用率达到 80% 时扩缩容，副本数在 2-5 之间：

kubectl autoscale deployment foo --min=2 --max=5 --cpu-percent=80

YAML 配置示例

通过 YAML 文件可以更灵活地配置 HPA，支持多指标扩缩容。

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
 name: nginx-hpa
spec:
 scaleTargetRef:
 apiVersion: apps/v1
 kind: Deployment
 name: nginx
 minReplicas: 2
 maxReplicas: 10
 metrics:
 - type: Resource
 resource:
 name: cpu
 target:
 type: Utilization
 averageUtilization: 80
 - type: Resource
 resource:
 name: memory
 target:
 type: Utilization
 averageUtilization: 80

滚动更新注意事项

HPA 应绑定到 Deployment / StatefulSet 这类上层控制器，而不是直接绑定 ReplicaSet：滚动更新会创建新的 ReplicaSet，直接绑定旧 ReplicaSet 的 HPA 不会自动跟随。同时，使用 HPA 时不要在 Deployment 清单里写死 replicas，否则每次 kubectl apply 都会把副本数重置为清单值。

自定义指标配置

HPA 支持基于自定义指标的扩缩容，需满足一定的前提条件。

前提条件

要使用自定义指标，需完成如下配置：

Controller Manager 配置：

--horizontal-pod-autoscaler-use-rest-clients=true
--master=http://API_SERVER_ADDRESS:8080

API Server 配置（Kubernetes 1.7+）：

--requestheader-client-ca-file=/etc/kubernetes/ssl/ca.pem
--requestheader-allowed-names=aggregator
--requestheader-extra-headers-prefix=X-Remote-Extra-
--requestheader-group-headers=X-Remote-Group
--requestheader-username-headers=X-Remote-User
--proxy-client-cert-file=/etc/kubernetes/ssl/kubernetes.pem
--proxy-client-key-file=/etc/kubernetes/ssl/kubernetes-key.pem

APIService 配置

创建自定义指标 API 服务的 YAML 示例：

apiVersion: apiregistration.k8s.io/v1
kind: APIService
metadata:
 name: v1beta2.custom-metrics.metrics.k8s.io
spec:
 insecureSkipTLSVerify: true
 group: custom-metrics.metrics.k8s.io
 groupPriorityMinimum: 1000
 versionPriority: 5
 service:
 name: custom-metrics-apiserver
 namespace: custom-metrics
 version: v1beta2

Prometheus 集成

通过 Prometheus Operator 可以实现自定义指标的采集与暴露。

部署 Prometheus Operator：

kubectl apply -f prometheus-operator.yaml

验证自定义指标 API：

kubectl get --raw="/apis/custom-metrics.metrics.k8s.io/v1beta2" | jq .

自定义指标 HPA 示例：

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
 name: nginx-custom-hpa
spec:
 scaleTargetRef:
 apiVersion: apps/v1
 kind: Deployment
 name: nginx
 minReplicas: 2
 maxReplicas: 10
 metrics:
 - type: Pods
 pods:
 metric:
 name: http_requests_per_second
 target:
 type: AverageValue
 averageValue: "100"
 - type: Object
 object:
 metric:
 name: requests-per-second
 describedObject:
 apiVersion: networking.k8s.io/v1
 kind: Ingress
 name: main-route
 target:
 type: Value
 value: "10k"

多指标支持

Kubernetes 1.6 及以上版本支持基于多个指标的扩缩容。

HPA 会根据每个指标分别计算所需副本数
取所有指标计算结果中的最大值作为最终扩缩容结果
需确保所有指标都满足要求

指标类型说明

下表总结了 HPA 支持的指标类型及其用途。

指标类型	描述	用途
Resource	CPU、内存等资源指标	基础资源监控
Pods	Pod 级别的自定义指标	应用特定指标
Object	Kubernetes 对象指标	外部资源监控
External	外部系统指标	云服务指标

表 2: HPA 支持的指标类型及用途

最佳实践

在实际生产环境中，建议遵循以下最佳实践：

资源请求设置

合理设置 Pod 的资源请求和限制，有助于 HPA 精确扩缩容。

resources:
 requests:
 cpu: 100m
 memory: 128Mi
 limits:
 cpu: 500m
 memory: 512Mi

合理的扩缩容参数

通过配置 behavior 字段，可以优化扩缩容的平滑性，避免频繁波动。

behavior:
 scaleDown:
 stabilizationWindowSeconds: 300
 tolerance: 0.05 # v1.37：缩容容差 5%，覆盖集群默认的 10%
 policies:
 - type: Percent
 value: 10
 periodSeconds: 60
 scaleUp:
 stabilizationWindowSeconds: 60
 tolerance: 0.02 # 扩容更敏感
 policies:
 - type: Percent
 value: 50
 periodSeconds: 60

tolerance 字段（特性门控 HPAConfigurableTolerance）让"扩容要快、缩容要稳"这类不对称策略无需再修改 kube-controller-manager 全局参数即可实现。

监控和告警

监控 HPA 状态和扩缩容事件
设置合理的告警阈值
定期检查指标的准确性

与其他弹性机制的配合

KEDA：基于消息队列长度、HTTP 请求数等外部事件源驱动扩缩容，并支持缩容到 0；KEDA 在底层仍然创建并管理 HPA 对象
VPA 与原地资源调整：v1.35 起 Pod 原地资源调整 GA，VPA 的 InPlaceOrRecreate 模式可在不重建 Pod 的情况下调整 CPU/内存；同一工作负载上不要让 HPA 与 VPA 同时基于 CPU/内存做决策
Cluster Autoscaler / Karpenter：HPA 扩出的 Pod 若无节点可调度，由节点级弹性组件补充节点

故障排除

在使用 HPA 过程中，常见问题及排查方法如下：

常见问题

HPA 不生效
- 检查 Pod 是否设置了 resource requests
- 验证 metrics-server 是否正常运行
- 确认 HPA 配置正确
自定义指标无法获取
- 检查自定义指标 API 是否注册
- 验证 APIService 配置
- 确认指标数据源正常
频繁扩缩容
- 调整 stabilizationWindowSeconds
- 优化指标阈值设置
- 检查应用负载模式

调试命令

以下命令可用于排查 HPA 相关问题：

# 查看 HPA 状态
kubectl describe hpa <hpa-name>

# 查看 HPA 事件
kubectl get events --field-selector involvedObject.kind=HorizontalPodAutoscaler

# 查看可用指标
kubectl get --raw "/apis/metrics.k8s.io/v1beta1/nodes" | jq . # metrics-server 提供 v1 后可改为 /v1/
kubectl get --raw "/apis/custom-metrics.metrics.k8s.io/v1beta2" | jq .

总结

HPA 是 Kubernetes 自动化运维的核心能力之一，能够根据多种指标实现 Pod 的自动扩缩容。通过合理配置资源请求、自定义指标和扩缩容策略，可以显著提升集群资源利用率和应用弹性。实际生产中，建议结合监控和告警体系，持续优化 HPA 策略，确保系统稳定高效运行。

参考文献

自定义 Pod 自动扩缩容器

Jimmy Song — Mon, 27 Oct 2025 20:10:00 +0800

只有理解业务，才能让自动扩缩容真正服务于系统弹性和成本优化。

随着 Kubernetes 在云原生架构中的广泛应用，自动扩缩容（Autoscaling）成为了保障系统弹性和性能的关键机制。标准的 水平 Pod 自动扩缩容（Horizontal Pod Autoscaler，HPA） 为基于 CPU 和内存的扩缩容提供了便捷方案。然而，随着业务场景的复杂化，单一资源维度的自动扩缩容往往难以满足实际需求。此时，自定义 Pod 自动扩缩容器（Custom Autoscaler） 提供了灵活的工具，让用户能够根据业务指标自定义扩缩容策略，进一步扩展 Kubernetes 的自动化能力。

本文将介绍如何通过自定义 Pod 自动扩缩容器扩展 Kubernetes 的标准自动扩缩容机制，并探讨如何在集群中实现更高效、动态的资源管理。

概述

自定义 Pod 自动扩缩容器基于 Kubernetes 的自定义指标（Custom Metrics）和事件进行扩缩容。它不仅支持标准的资源利用率（如 CPU、内存），还可以结合应用特定的指标（如请求数、响应时间等）实现自动扩缩容。通过扩展 Kubernetes 控制器和 API 机制，自定义扩缩容器能够支持更灵活的自动化管理和更智能的集群调度。

Kubernetes 提供了多种扩展机制来实现自定义功能，包括自定义资源定义（Custom Resource Definition，CRD）、API 聚合层、Admission Webhook 等。开发者可以利用这些机制，将 Kubernetes 扩展为适应特定工作负载的自动化管理系统。

工作原理

自定义 Pod 自动扩缩容器的核心原理与 Kubernetes 内建的 HPA 类似，通常包括以下四个步骤：

观察：通过 Kubernetes 的监控组件（如 Prometheus、Metrics Server）获取集群中各类指标（如自定义应用指标）。
分析：分析当前状态与期望状态的差异，判断是否需要扩展或缩减 Pod 副本。
调节：执行扩缩容操作，通过调整 Pod 副本数实现资源的自动调整。
重复：控制器持续循环上述过程，确保集群始终保持在期望的资源状态。

自定义扩缩容的关键组件

自定义 Pod 自动扩缩容涉及多个核心组件，下面分别介绍其作用和实现方式。

自定义资源定义（CRD）

自定义资源定义（CRD）是扩展 Kubernetes API 的核心机制之一，允许用户创建新的资源类型并定义特定控制逻辑。通过 CRD，用户可以创建适合自身应用的扩展控制器，使其能够基于自定义指标进行扩缩容。

例如，可以创建一个 CRD 定义 AppMetrics 资源，用于描述应用的自定义监控数据。该 CRD 可包含如“请求数”“错误率”等业务特定指标，并将这些指标作为扩缩容的依据。

APIService 与 Metrics Server

Kubernetes 的 API 聚合层允许将外部 API 与主 API 集成。在自定义自动扩缩容场景中，APIService 用于注册新的 API 服务，如自定义指标 API 服务。

Metrics Server 是获取集群资源使用情况的插件，通常与 HPA 等组件配合使用。在自定义扩缩容中，用户可结合自定义指标与标准资源指标，制定更灵活的扩缩容策略。

Admission Webhook 与 Validating Webhook

Admission Webhook 是 Kubernetes 的扩展机制，用于拦截请求并在资源对象创建或修改时执行策略检查。通过自定义 Admission Webhook，可以在 Pod 创建时校验资源请求是否合理。

Validating Webhook 可用于动态验证 Pod 配置，确保自定义指标满足扩缩容要求。

控制器与 Operator 模式

控制器是 Kubernetes 实现自愈和自动化管理的核心。在自定义 Pod 自动扩缩容中，控制器负责监听指标变化、计算新副本数并调整 Pod 数量。结合 Operator 模式，可以将扩缩容逻辑与应用管理（如版本控制、故障恢复等）统一到一个自定义控制器中，实现更高层次的自动化。

实现步骤

实现自定义 Pod 自动扩缩容器通常包括以下步骤：

安装与配置 Metrics Server

首先需确保 Kubernetes 集群已安装并配置 Metrics Server，以便获取 Pod 资源使用情况（如 CPU、内存等）。这为集成自定义扩缩容提供基础数据支持。

创建自定义指标

通过创建自定义 API 服务（如 AppMetrics CRD），并结合 Prometheus 等监控工具收集、暴露自定义指标。这些指标可作为扩缩容决策的依据。

定义自定义扩缩容策略

基于自定义指标，可以通过 YAML 配置文件定义自定义扩缩容器。例如，结合 HorizontalPodAutoscaler 和 autoscaling/v2 API，可同时基于 CPU、内存与自定义指标进行扩缩容。

下面的 YAML 示例展示了如何配置基于自定义指标和资源利用率的自动扩缩容策略：

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
 name: custom-hpa
spec:
 scaleTargetRef:
 apiVersion: apps/v1
 kind: Deployment
 name: app-deployment
 minReplicas: 2
 maxReplicas: 10
 metrics:
 - type: Pods
 pods:
 metric:
 name: http_requests_per_second
 target:
 type: AverageValue
 averageValue: "100"
 - type: Resource
 resource:
 name: cpu
 target:
 type: Utilization
 averageUtilization: 80

监控与告警

为确保系统高效运行，建议结合 Prometheus 进行全面监控，并设置合理的告警阈值。通过监控和告警配置，可以在资源使用异常时及时响应，保障系统稳定性。

最佳实践

在实现自定义 Pod 自动扩缩容时，建议遵循以下最佳实践：

合理设置资源请求和限制：为每个 Pod 设置合适的资源请求（requests）和限制（limits），确保 HPA 基于准确数据进行扩缩容。
定义平滑的扩缩容策略：为避免频繁波动，建议在 scaleUp 和 scaleDown 策略中配置 stabilizationWindowSeconds 等参数，平滑扩缩容过程。
集成 Prometheus 和自定义指标：结合 Prometheus 采集自定义指标，可实现更灵活的扩缩容策略，不局限于 CPU 和内存。
定期检查和优化扩缩容配置：随着负载模式变化，定期检查扩缩容策略并优化，以适应新的应用需求。

总结

自定义 Pod 自动扩缩容器为 Kubernetes 带来了更高的灵活性和可扩展性。通过自定义指标、外部系统和应用特定需求，能够自动调整集群资源，提高资源利用率，简化运维，减少手动干预。合理配置和持续优化自定义扩缩容，将为复杂业务场景提供强大支持。

参考资料

VPA 与 KEDA：纵向扩缩与事件驱动扩缩

Jimmy Song — Sun, 01 Nov 2026 00:00:00 +0800

HPA 回答"要几个副本"，VPA 回答"每个副本该多大"，KEDA 回答"该不该从零唤醒"——三者合在一起才是完整的工作负载弹性。

HPA 是 Kubernetes 内置的水平扩缩器，但它依赖 CPU/内存等资源指标或需要自建指标适配器，且副本数最少为 1（HPAScaleToZero 在 v1.37 仍为 Beta 且默认关闭）。两个 SIG Autoscaling 与 CNCF 项目补足了这些空白：Vertical Pod Autoscaler（VPA）自动校准容器的资源 requests，KEDA 以事件源驱动水平扩缩并支持缩容到零。本文介绍两者的原理、配置与组合方式。

Vertical Pod Autoscaler

资源 requests 决定调度、驱逐顺序、配额与节点扩缩的一切计算，但大多数团队要么凭经验填写、要么长期不更新，导致集群整体利用率普遍只有 20% – 40%。VPA 通过观察容器的历史用量持续生成推荐值，并可选地自动应用。

架构

VPA 由三个组件组成：

Recommender：从 metrics-server（或 Prometheus）读取各容器的 CPU/内存用量，用衰减直方图计算 P50/P90/P95 等分位数，生成 target（推荐值）、lowerBound、upperBound 与 uncappedTarget；OOM 事件会使内存推荐立即上调
Updater：比较运行中 Pod 的 requests 与推荐值，偏差超出阈值时驱逐 Pod（或在新模式下原地调整），遵守 PDB 与最小副本限制
Admission Controller：变更准入 Webhook，在 Pod 创建时把推荐值写入 requests（与 limits 按原比例缩放）

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
 name: api
spec:
 targetRef:
 apiVersion: apps/v1
 kind: Deployment
 name: api
 updatePolicy:
 updateMode: "InPlaceOrRecreate" # Off | Initial | Recreate | InPlaceOrRecreate | InPlace
 minReplicas: 2 # 至少保留 2 个副本不被同时驱逐
 resourcePolicy:
 containerPolicies:
 - containerName: "*"
 minAllowed: { cpu: 100m, memory: 128Mi }
 maxAllowed: { cpu: "4", memory: 8Gi }
 controlledResources: ["cpu", "memory"]
 controlledValues: RequestsAndLimits  # 或 RequestsOnly，保留手工设置的 limits
 - containerName: istio-proxy
 mode: "Off" # 排除 Sidecar

更新模式

模式	行为	适用
`Off`	只生成推荐写入 `status.recommendation`，不改变 Pod	观察与容量规划，所有工作负载的起点
`Initial`	仅在 Pod 创建时应用推荐，运行中不改	不能容忍重启但部署频繁的服务
`Recreate`	偏差过大时驱逐 Pod 让其以新 requests 重建	批处理、可容忍重启的无状态服务
`InPlaceOrRecreate`	优先通过原地资源调整修改 requests，不可行时回退到驱逐（VPA 1.5+ Beta）	大多数生产服务的推荐模式（Kubernetes 1.33+）
`InPlace`	只做原地调整，永不驱逐，不可行时推迟重试（VPA 1.7+ Alpha，需 `--feature-gates=InPlace=true`）	完全不能接受中断的有状态服务

表 1: VPA 更新模式

InPlaceOrRecreate 把 VPA 从"周期性重启应用的工具"变成了近乎无感的持续调优：对配置了 resizePolicy: NotRequired 的容器，CPU 与内存上调不需要重启；内存 limit 下调在 PreferNoRestart 策略下仍会回退到重建；若调整会改变 Pod 的 QoS 等级（如从 Burstable 变为 Guaranteed）、被 kubelet 判定不可行、推迟超过 5 分钟或进行中超过 1 小时，同样回退。--in-place-skip-disruption-budget 标志允许对所有容器都无需重启的调整跳过 PDB 检查。

使用要点

VPA 与 HPA 不能同时控制同一资源维度：HPA 按 CPU 利用率扩缩时，VPA 调整 CPU requests 会改变利用率计算基准导致震荡；常见组合是 HPA 用自定义指标（QPS、队列长度）或 KEDA 控制副本数，VPA 只管 requests
JVM 等启动时按固定堆大小分配内存的应用，内存推荐应配合 minAllowed 并关注 upperBound
推荐值基于至少 8 天的历史（可配置），新部署的工作负载前几天的推荐不可靠
Recommender 默认依赖 metrics-server，大集群建议改用 Prometheus 作为历史存储（--storage=prometheus）以在 Recommender 重启后保留历史
kubectl describe vpa api 可查看推荐与各容器的上下界，Goldilocks 等工具提供集群级仪表盘

KEDA：事件驱动扩缩

KEDA（Kubernetes Event-driven Autoscaling，CNCF 毕业项目，当前 v2.21）让工作负载按外部事件源的指标扩缩——消息队列积压、数据库行数、HTTP 请求率、云监控指标、Cron 时间表等——并支持缩容到零与从零激活。它不替代 HPA，而是作为 HPA 的外部指标提供者：

KEDA Operator 监听 ScaledObject，为目标工作负载自动创建并管理一个 HPA（minReplicaCount 到 maxReplicaCount 区间）
KEDA Metrics Server 把各 Scaler 的指标通过 external.metrics.k8s.io 聚合 API 暴露给 HPA
在 0 与 1 副本之间的切换由 KEDA 自己完成（HPA 不能管理 0 副本）：事件源出现待处理项时 KEDA 把副本从 0 拉到 1（激活），之后交给 HPA；无事件持续 cooldownPeriod 后再缩回 0

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
 name: order-worker
 namespace: prod
spec:
 scaleTargetRef:
 name: order-worker  # Deployment / StatefulSet / 任意带 scale 子资源的 CR
 pollingInterval: 30 # 查询事件源的间隔（秒）
 cooldownPeriod: 300 # 最后一次活跃后多久缩到 0
 idleReplicaCount: 0 # 空闲时的副本数（必须小于 minReplicaCount）
 minReplicaCount: 1
 maxReplicaCount: 50
 fallback: # 事件源不可达时的保底副本数
 failureThreshold: 3
 replicas: 5
 advanced:
 horizontalPodAutoscalerConfig:
 behavior: # 直接透传给 HPA 的 behavior
 scaleDown:
 stabilizationWindowSeconds: 120
 triggers:
 - type: kafka
 metadata:
 bootstrapServers: kafka.prod.svc:9092
 consumerGroup: order-worker
 topic: orders
 lagThreshold: "100" # 每副本期望处理的积压量
 activationLagThreshold: "1" # 积压 ≥ 1 即从 0 激活
 authenticationRef:
 name: kafka-creds
 - type: prometheus
 metadata:
 serverAddress: http://prometheus.monitoring.svc:9090
 query: sum(rate(http_requests_total{service="order-worker"}[2m]))
 threshold: "50"
---
apiVersion: keda.sh/v1alpha1
kind: TriggerAuthentication
metadata:
 name: kafka-creds
 namespace: prod
spec:
 secretTargetRef:
 - parameter: sasl
 name: kafka-secret
 key: sasl
 - parameter: username
 name: kafka-secret
 key: username
 - parameter: password
 name: kafka-secret
 key: password

多个触发器默认取各自计算出的副本数的最大值，advanced.scalingModifiers 可用公式组合多个指标。TriggerAuthentication/ClusterTriggerAuthentication 把凭据从 ScaledObject 中分离，支持 Secret、环境变量、Vault、云 Pod 身份（AWS IRSA/Pod Identity、Azure Workload Identity、GCP Workload Identity）。

ScaledJob

对"每条消息一个任务"的批处理模式，ScaledJob 按队列长度直接创建 Job 而非扩缩 Deployment：每个 Job 处理完即退出，不存在长驻消费者被缩容时打断处理的问题，适合视频转码、报表生成、AI 批量推理等长任务。

apiVersion: keda.sh/v1alpha1
kind: ScaledJob
metadata:
 name: transcode
spec:
 jobTargetRef:
 parallelism: 1
 completions: 1
 backoffLimit: 2
 template:
 spec:
 restartPolicy: Never
 containers:
 - name: worker
 image: registry.example.com/transcoder:1.0
 pollingInterval: 15
 maxReplicaCount: 100
 successfulJobsHistoryLimit: 5
 scalingStrategy:
 strategy: accurate  # 按队列长度减去运行中 Job 数精确创建
 triggers:
 - type: aws-sqs-queue
 metadata:
 queueURL: https://sqs.us-west-2.amazonaws.com/123456789012/transcode
 queueLength: "1"
 awsRegion: us-west-2
 authenticationRef:
 name: aws-pod-identity

常用 Scaler

KEDA 内置 70 余种 Scaler，覆盖消息系统（Kafka、RabbitMQ、NATS、Pulsar、SQS、Azure Service Bus、Pub/Sub）、数据库（PostgreSQL、MySQL、MongoDB、Redis、Elasticsearch）、监控系统（Prometheus、Datadog、CloudWatch、Azure Monitor、Stackdriver）、CI 系统（GitHub Runner、GitLab Runner、Azure Pipelines）、以及 cron（按时间表预扩）、cpu/memory（与 HPA 相同的资源指标）和 kubernetes-workload（按另一个工作负载的 Pod 数）。HTTP 请求驱动的缩容到零需要额外的 KEDA HTTP Add-on，它在请求路径上插入拦截器缓冲冷启动期间的请求——这与 Knative Serving 的 Activator 思路相同，后者在 Serverless 章节介绍。

三者的组合策略

需求	方案
按 CPU/内存利用率扩缩副本	HPA（或 KEDA 的 cpu/memory Scaler，便于统一管理）
按队列积压、请求率、业务指标扩缩	KEDA（自动创建 HPA）
空闲时缩到零	KEDA（`idleReplicaCount: 0`）；HTTP 服务加 HTTP Add-on 或改用 Knative
校准 requests、消除过度申请	VPA（`Off` 观察 → `InPlaceOrRecreate` 自动）
副本数与 requests 同时自动化	KEDA/HPA 用非资源指标控制副本，VPA 控制 requests，避免同一维度冲突
批处理任务按事件创建	KEDA ScaledJob，或 Kueue 配合 Job
定时预扩容应对可预期高峰	KEDA `cron` Scaler 叠加其他触发器

表 2: HPA、VPA 与 KEDA 的分工

所有工作负载层的扩缩最终都要落到节点容量上，副本增加导致 Pending 时由节点自动扩缩补充节点；VPA 上调 requests 同样可能触发节点扩容。把 VPA 的 maxAllowed 设在节点可分配资源以内，可以避免推荐出任何节点都放不下的 Pod。

总结

VPA 与 KEDA 分别从纵向与事件两个维度补全了 Kubernetes 的工作负载弹性：VPA 用持续观测取代手工估算 requests，借助原地资源调整在不重启的前提下自动校准；KEDA 让副本数跟随业务事件而非资源利用率变化，并补上 HPA 缺失的缩容到零能力。实践中应以"HPA/KEDA 控制副本数、VPA 控制单副本大小、两者不触碰同一指标"为原则，再由节点自动扩缩兜底容量，形成从事件到节点的完整弹性链路。

参考文献

节点自动扩缩：Cluster Autoscaler 与 Karpenter

Jimmy Song — Sun, 01 Nov 2026 00:00:00 +0800

工作负载自动扩缩解决"要多少 Pod"，节点自动扩缩解决"这些 Pod 放在哪台机器上"——后者直接决定账单。

HPA、VPA 与 KEDA 调整的是 Pod 的数量与大小，而当集群现有节点容纳不下新的 Pod 时，就需要节点自动扩缩器（Node Autoscaler）向云平台申请新节点；反过来，当节点长期空闲或低利用率时，自动缩容与整合是云上成本优化最直接的手段。SIG Autoscaling 目前维护两个节点自动扩缩实现：Cluster Autoscaler 与 Karpenter。

节点自动扩缩的两个方向

扩容（Provisioning）由 Pending 状态的 Pod 驱动。自动扩缩器监听带有 Unschedulable 条件的 Pod，用调度器相同的约束（资源 requests、节点选择器、亲和性、污点容忍、拓扑分布）模拟判断"如果新增某种节点，这些 Pod 能否被调度"，然后向云平台发起创建请求。节点就绪并注册后，调度器正常把 Pod 调度上去。这意味着：

自动扩缩器只看 requests，不看实际用量——requests 设置失真会直接导致扩容过度或不足
不满足任何节点类型约束的 Pod（如请求的 GPU 类型没有对应节点池）会一直 Pending
扩容延迟 = 决策周期（10 秒级） + 云平台创建实例（1 – 3 分钟） + 节点引导与镜像拉取

整合（Consolidation）则试图在满足所有 Pod 约束的前提下减少节点数或替换为更便宜的节点。自动扩缩器会选择候选节点、模拟其上的 Pod 能否全部迁移到其他节点（或迁移到一台新的更小节点），通过则先设置污点、再逐个驱逐 Pod（遵守 PDB），最后删除节点。整合的激进程度与业务中断风险直接相关，是最需要精细配置的部分。

Cluster Autoscaler

Cluster Autoscaler（CA）是最早的实现，版本号与 Kubernetes 小版本对齐（v1.37 集群对应 CA 1.37.x），支持 30 余种云平台与 Cluster API。它的核心抽象是节点组（Node Group）：预先定义的、同构的实例集合（AWS Auto Scaling Group、GCP MIG、Azure VMSS、Cluster API 的 MachineDeployment），每个节点组有最小/最大节点数，CA 只在这些边界内调整数量。

# 以 AWS 为例的关键启动参数
- ./cluster-autoscaler
- --cloud-provider=aws
- --node-group-auto-discovery=asg:tag=k8s.io/cluster-autoscaler/enabled,k8s.io/cluster-autoscaler/my-cluster
- --expander=least-waste  # 多个节点组都能容纳时的选择策略
- --balance-similar-node-groups  # 跨可用区的同构节点组均衡扩容
- --skip-nodes-with-local-storage=false
- --scale-down-utilization-threshold=0.5  # 利用率低于 50% 的节点成为缩容候选
- --scale-down-unneeded-time=10m  # 持续低利用 10 分钟后缩容
- --scale-down-delay-after-add=10m  # 扩容后 10 分钟内不缩容
- --max-node-provision-time=15m

扩展器（Expander）决定多个节点组都能满足时选哪个：random、most-pods、least-waste（浪费最少的资源）、price（最便宜，需云平台支持）、priority（按 ConfigMap 中的优先级正则），可用逗号组合形成多级决策。CA 的缩容基于利用率阈值且只能删除整台节点，不会主动把两台半满的节点合并到一台更合适的机型上。

CA 的优势在于成熟、云平台覆盖广、与托管服务（EKS Managed Node Groups、GKE 节点池、AKS 节点池）深度集成——GKE 与 AKS 的内置自动扩缩即基于 CA。它的局限是"节点组"模型要求管理员预先枚举机型组合：要支持 10 种机型 × 3 个可用区 × 按需/Spot 就需要 60 个节点组，且每个节点组内部不能混用机型。

Karpenter

Karpenter 由 AWS 发起、2023 年捐赠给 SIG Autoscaling，核心库 kubernetes-sigs/karpenter 当前为 v1.15，云平台实现包括 AWS（GA）、Azure（GA）以及社区维护的 GCP、阿里云、Cluster API 等。它放弃了节点组，直接面向云平台的实例 API 做"即时供应"：根据 Pending Pod 的聚合需求，在允许的机型范围内挑选最合适、最便宜的实例类型逐台创建，并用 NodeClaim 对象跟踪每个节点的生命周期。

两个核心 CRD 是 NodePool（供应约束与中断策略，云无关）与云平台特定的 NodeClass（如 EC2NodeClass，定义 AMI、子网、安全组、磁盘）：

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
 name: general
spec:
 template:
 metadata:
 labels:
 team: platform
 spec:
 nodeClassRef:
 group: karpenter.k8s.aws
 kind: EC2NodeClass
 name: default
 requirements: # 允许的机型范围，Karpenter 在其中按价格择优
 - key: karpenter.sh/capacity-type
 operator: In
 values: ["spot", "on-demand"]
 - key: kubernetes.io/arch
 operator: In
 values: ["amd64", "arm64"]
 - key: karpenter.k8s.aws/instance-category
 operator: In
 values: ["c", "m", "r"]
 - key: karpenter.k8s.aws/instance-generation
 operator: Gt
 values: ["5"]
 expireAfter: 720h  # 节点最长存活 30 天，强制轮换以更新 AMI
 terminationGracePeriod: 48h  # 中断时给 Pod 的最长排空时间
 disruption:
 consolidationPolicy: WhenEmptyOrUnderutilized
 consolidateAfter: 1m
 budgets:
 - nodes: "10%" # 任意时刻最多中断 10% 节点
 - schedule: "0 9 * * mon-fri" # 工作日白天禁止主动整合
 duration: 8h
 nodes: "0"
 limits:
 cpu: "1000"
 memory: 4000Gi
 weight: 10
---
apiVersion: karpenter.k8s.aws/v1
kind: EC2NodeClass
metadata:
 name: default
spec:
 amiSelectorTerms:
 - alias: al2023@latest
 role: KarpenterNodeRole-my-cluster
 subnetSelectorTerms:
 - tags: { karpenter.sh/discovery: my-cluster }
 securityGroupSelectorTerms:
 - tags: { karpenter.sh/discovery: my-cluster }
 blockDeviceMappings:
 - deviceName: /dev/xvda
 ebs: { volumeSize: 100Gi, volumeType: gp3, encrypted: true }

Karpenter 的几个关键特性：

装箱式供应：一批 Pending Pod 会被聚合后选择一台或少数几台恰好容纳的实例，而不是按固定机型逐台加；Spot 场景下自动在多种机型中选择中断率低、价格优的组合
主动整合：WhenEmptyOrUnderutilized 策略下，Karpenter 会持续评估能否删除节点或把节点替换为更便宜的机型（如把 m5.2xlarge 换成当前更便宜的 m6a.xlarge + 迁移 Pod），Balanced 则在成本与中断之间折中；配合 budgets 控制速度与时间窗口
节点到期与漂移：expireAfter 强制定期轮换节点以应用新的 AMI 与补丁；修改 NodeClass 后现有节点被标记为"漂移"（Drift）并按预算逐步替换，实现声明式的节点生命周期管理
Spot 中断处理：通过云平台事件（EC2 Spot 中断通知、计划维护）提前排空节点，与节点优雅关机配合

选型对比

维度	Cluster Autoscaler	Karpenter
节点模型	预定义节点组，组内同构	无节点组，按约束范围即时选择机型
扩容速度	依赖节点组 API，通常 2 – 4 分钟	直接调用实例 API，通常 1 – 2 分钟
机型灵活性	需为每种机型/区/容量类型建组	一个 NodePool 覆盖数百种机型
缩容/整合	按利用率阈值删除整台节点	删除或替换为更便宜机型，预算与时间窗控制
节点生命周期	不管理，由节点组/托管服务负责	到期轮换、漂移替换、AMI 声明式更新
云平台支持	30+（含私有云、Cluster API）	AWS、Azure GA；GCP、阿里云、CAPI 等社区实现
与托管服务集成	GKE/AKS 内置；EKS Managed Node Groups	EKS Auto Mode 内置；AKS Node Autoprovisioning（NAP）内置
成熟度	2016 年起，极为成熟	2021 年起，AWS 上大规模生产验证

表 1: Cluster Autoscaler 与 Karpenter 对比

实践中的建议：在 AWS 或 Azure 上的新集群优先选择 Karpenter，其机型灵活性与整合能力带来的成本节省通常在 20% – 40%；多云、私有云或依赖 Cluster API 的环境使用 CA；GKE 直接使用内置的节点自动供应（NAP）即可。两者可以共存但不应管理同一批节点，常见组合是系统组件所在的固定节点池由 CA/托管服务管理，弹性工作负载由 Karpenter 供应。

与工作负载扩缩的配合

节点扩缩与 Pod 扩缩是两个独立但相互触发的回路：HPA/KEDA 增加副本 → 新 Pod Pending → 节点扩容；HPA 减少副本 → 节点利用率下降 → 整合回收。配合时需注意：

requests 准确性是一切的前提，VPA 推荐模式可持续校准
扩容预热：对延迟敏感的服务，可部署低优先级（负 PriorityClass 值）的"占位 Pod"预留一台空闲节点，真正的业务 Pod 到来时抢占占位 Pod 立即调度，节点扩缩器随后为被抢占的占位 Pod 补充节点，详见优先级与抢占
PDB 是整合时的安全网，没有 PDB 的多副本应用可能在整合中被同时驱逐；但过于严格的 PDB（如 maxUnavailable: 0）会让节点永远无法回收，Karpenter 与 CA 都会在日志与事件中报告被 PDB 阻塞的节点
DaemonSet 与系统 Pod 不会阻止缩容；带本地存储（emptyDir 外的 hostPath/local PV）的 Pod、未被控制器管理的裸 Pod、以及带 cluster-autoscaler.kubernetes.io/safe-to-evict: "false" 或 karpenter.sh/do-not-disrupt: "true" 注解的 Pod 会阻止其所在节点被回收

GPU 与 AI 工作负载

GPU 节点昂贵且启动慢（驱动与 CUDA 镜像拉取），自动扩缩需要额外考虑：

在 NodePool/节点组上设置 nvidia.com/gpu 等污点，确保只有显式请求 GPU 的 Pod 落到 GPU 节点；Karpenter 可按 karpenter.k8s.aws/instance-gpu-name 等标签精确约束 GPU 型号
扩容器依赖设备插件或 DRA 驱动在节点上报告 GPU 容量；节点就绪到 GPU 可用之间有延迟，CA 需配置 --gpu-total 相关的节点组标签让其在模拟时预知 GPU 数量，Karpenter 则从实例类型元数据直接获知
训练任务通常以 Job/JobSet 形式成组启动，配合 Kueue 等队列系统做准入后再触发节点扩容，避免部分 Pod 就绪、部分等待节点的"半启动"浪费；GenericWorkload/成组调度的进展也将改善这一点
GPU 节点的整合要格外保守：训练中的 Pod 被驱逐意味着丢失检查点以来的进度，应设置 karpenter.sh/do-not-disrupt 注解或更长的 terminationGracePeriod

总结

节点自动扩缩把"有多少机器"从容量规划变成了由工作负载需求实时驱动的闭环。Cluster Autoscaler 以节点组为单位稳健地增减节点，覆盖几乎所有基础设施；Karpenter 则跳过节点组直接按 Pod 需求选择最优实例，并以到期、漂移与整合预算实现声明式的节点生命周期管理。无论选择哪一个，准确的资源 requests、合理的 PDB 与明确的中断预算，都是让自动扩缩既省钱又不伤业务的前提。

参考文献

Volcano：Kubernetes 上的批处理和高性能计算调度器

Jimmy Song — Thu, 20 Jun 2024 08:00:00 +0000

Volcano 是 Kubernetes 生态中专为批处理和高性能计算（HPC）场景设计的调度器扩展，支持 Gang 调度、资源公平分配和多种插件机制，极大提升了集群在 AI、科研和大数据领域的调度能力。

项目背景与设计目标

Kubernetes 默认调度器主要面向服务型负载，存在以下局限：

每个 Pod 独立调度，缺乏任务组（JobGroup）概念；
不支持 Gang Scheduling（成组调度）和资源公平共享（Fair Share）。

Volcano 通过自定义资源（CRD）和可插拔调度插件，补齐了这些短板，目标是为 AI/ML 分布式训练、HPC 批处理、大数据计算和科研仿真等场景提供原生支持。

架构总览

Volcano 控制平面由多个组件构成，负责批量任务调度、资源分配与生命周期管理。下图展示了主要架构组件及其交互关系。

图 1: Volcano 架构总览

组件	作用
vc-scheduler	主调度器，负责 Pod 分配、抢占、回收等动作
vc-controller-manager	管理 CRD 生命周期（Job、Queue、PodGroup）
vc-webhook-manager	Admission 校验与变更
vc-agent	节点级管理（部分版本可选）

表 1: Volcano 核心组件职责

自定义资源（CRD）模型

Volcano 通过自定义资源扩展了 Kubernetes 的原生对象模型。下图展示了各 CRD 之间的关系。

图 2: Volcano CRD 模型

资源类型	功能说明
Job	定义批量任务、任务组、资源需求
PodGroup	实现 Gang Scheduling，保证任务组原子调度
Queue	定义资源配额与优先级
JobFlow	支持任务依赖与有向执行图（DAG）
JobTemplate	模板化任务定义，方便重用

表 2: Volcano CRD 功能说明

调度流程与执行机制

Volcano 的调度流程分为多个阶段，确保批量任务高效分配和资源利用。下图展示了调度循环的主要流程。

图 3: Volcano 调度流程

调度循环（Scheduling Cycle）包括：

Enqueue：将待调度的 Job 加入队列
Allocate：根据 Queue 配额分配资源
Preempt：抢占低优先级任务
Reclaim：回收闲置资源
Bind：分配 Pod 至节点

插件体系（Plugin System）

Volcano 的插件系统高度可扩展，支持在调度周期多个阶段注入自定义逻辑。下图展示了插件分类及其与核心框架的关系。

图 4: Volcano 插件体系

插件	功能说明
Gang	实现任务组全量调度
DRF	多资源公平共享
Proportion	队列配额分配
Predicates	节点资源匹配
NodeOrder	节点优先级排序
BinPack	紧密打包，提升利用率
Overcommit	超卖调度
Topology	NUMA / 网络拓扑感知

表 3: 常见内置插件功能

安装与使用

Volcano 支持 Helm 和原生 YAML 安装方式。安装后会在 volcano-system 命名空间创建核心组件。

通过 Helm 安装

helm repo add volcano-sh https://volcano-sh.github.io/helm-charts
helm install volcano volcano-sh/volcano -n volcano-system --create-namespace

使用原生 YAML 安装

kubectl apply -f https://raw.githubusercontent.com/volcano-sh/volcano/master/installer/volcano-development.yaml

安装后主要组件包括：

volcano-scheduler
volcano-controllers
volcano-admission

典型使用场景

Volcano 适用于多种批处理和高性能计算场景。下表列举了典型应用框架及其调度特性。

场景	框架	调度特性
AI 训练	TensorFlow、PyTorch、Ray	Gang 调度 + GPU 绑定
大数据计算	Spark、Flink	队列隔离 + Fair Share
HPC 仿真	MPI、Horovod	NUMA 拓扑 + 低延迟通信
Bioinformatics	Cromwell、KubeGene	工作流依赖调度
ML Pipeline	Kubeflow、Argo	JobFlow + 模板复用

表 4: Volcano 典型使用场景

使用时，只需在 Pod 或 Job 中指定 schedulerName: volcano，即可启用 Volcano 调度。

与原生 Kubernetes 的区别

下表对比了 Volcano 与 kube-scheduler 的主要差异。

对比维度	kube-scheduler	Volcano
调度粒度	Pod	Job / PodGroup
资源公平性	基于优先级	支持 DRF、比例调度
调度策略	简单优先级	Gang、Backfill、Preemption
CRD 支持	无	Job / Queue / PodGroup
插件扩展	有限	完整可插拔插件系统
应用场景	长期服务	批处理 / HPC / AI 训练

表 5: Volcano 与 kube-scheduler 对比

总结

Volcano 让 Kubernetes 从“服务编排平台”进化为“通用计算平台”，特别适用于分布式训练、资源公平调度、异构硬件感知和大规模批量作业管理。结合 Argo、Kubeflow、Ray 等生态系统，Volcano 使 Kubernetes 成为统一的高性能计算基础设施。

Jimmy Song – 调度与弹性

调度与弹性概述

调度与资源管理概述

Kubernetes 调度器原理

调度流程

调度框架与插件机制

默认调度插件

资源管理机制

资源类型

Requests 与 Limits

资源限制的强制机制

Pod 调度策略

拓扑分布约束（Topology Spread Constraints）

污点与容忍（Taints & Tolerations）

优先级与抢占

Pod 优先级

抢占机制

节点压力驱逐

驱逐信号与阈值

Pod 中断预算（PDB）

自动扩缩容（Autoscaling）

水平 Pod 自动扩缩容（HPA）

可配置扩缩容策略

垂直扩缩容与原地调整

节点级弹性

资源装箱（Bin Packing）策略

MostAllocated 策略

RequestedToCapacityRatio 策略

多调度器支持

集群规模与可扩展性

本章导读

总结

参考文献

资源调度

调度器组件

kube-scheduler 工作原理

调度流程

调度策略

高级调度功能

动态调度扩展

重调度场景

集群负载均衡

数据本地性优化

扩展调度器

最佳实践

总结

参考文献

调度约束：节点选择、亲和性与拓扑分布

四类约束概览

节点选择器

节点亲和性

Pod 亲和性与反亲和性

拓扑分布约束

集群级默认约束

推荐组合

排查调度失败

总结

参考文献

Pod 优先级与抢占

PriorityClass

内建系统优先级类

优先级对调度的影响

抢占机制

非抢占优先级

与其他机制的交互

用配额限制优先级类的使用

实践建议

总结

参考文献

服务质量等级（QoS）

QoS 等级分类

Guaranteed（保证级）

Burstable（突发级）

BestEffort（尽力而为级）

QoS 的作用机制

调度优先级

资源回收策略

cgroup v2 与内存 QoS

与原地资源调整的关系

交换分区