1. HPA 基础概念
1.1 HPA 的定义与作用
Horizontal Pod Autoscaler(HPA) 是 Kubernetes 内置的弹性伸缩控制器,用于根据工作负载的实时资源使用率或自定义指标,自动调整工作负载(如 Deployment、StatefulSet)的 Pod 副本数量。HPA 的核心目标是:在保证服务质量的前提下,实现资源供给与业务需求的动态匹配。
关键作用:
- 削峰填谷:流量高峰时自动扩容 Pod,保障响应延迟;低谷时自动缩容,节省资源成本。
- 运维自动化:替代人工手动调整副本数,减少运维干预,提升系统自愈能力。
- 资源利用率优化:通过精确的指标驱动,避免过度预留资源,提升集群整体利用率。
1.2 HPA 工作原理
HPA 以控制循环(Control Loop)方式运行,默认每 15 秒(由 --horizontal-pod-autoscaler-sync-period 控制)执行一次以下流程:
- 指标采集:HPA Controller 通过 Metrics Server 或自定义 API 获取目标工作负载的当前指标值。
- 期望副本计算:根据当前指标值与目标值的比值,计算期望副本数。公式为:
期望副本数 = ceil(当前指标总值 / 目标值 × 当前副本数)。 - 决策与执行:将期望副本数与当前副本数比较,若差异超过容忍阈值(默认 0.1),则通过 Scale API 更新工作负载的副本数。
- 冷却与回退:执行扩容或缩容后,进入冷却窗口(Cooldown),防止频繁抖动。
1.3 核心组件
1.3.1 Metrics Server
Metrics Server 是 Kubernetes 集群的资源指标聚合器,负责从每个节点的 Kubelet 收集 CPU、内存等核心资源指标,并通过 metrics.k8s.io API 对外暴露。它是 HPA 默认的指标来源。
| 特性 | 说明 |
|---|---|
| 数据来源 | Kubelet 内置的 cAdvisor,采集 Pod 级别的资源使用数据 |
| 存储方式 | 仅保留最近 1-2 分钟的内存数据,不提供历史查询 |
| 部署方式 | 作为集群插件(Addon)部署,通常以 Deployment 形式运行 |
| API 版本 | metrics.k8s.io/v1beta1 |
| 资源消耗 | 极低,通常只需 0.1 CPU / 64Mi 内存 |
注意:Metrics Server 仅支持 CPU 和内存指标。若需要使用自定义指标(如 QPS、请求延迟),需额外部署 Prometheus Adapter 或 Custom Metrics API 实现。
1.3.2 Controller Manager
kube-controller-manager 是 Kubernetes 控制平面的核心组件之一,其中内置了 HPA Controller。HPA Controller 是 HPA 功能的实际执行者,负责:
- 监听 HPA 资源对象的创建、更新、删除事件。
- 定期执行控制循环,调用 Metrics Server 获取指标数据。
- 根据算法计算期望副本数,并通过 Scale API 调整工作负载。
- 管理冷却窗口、容忍阈值等伸缩策略参数。
1.4 HPA 资源定义示例
以下是一个基于 CPU 利用率的 HPA 配置示例,目标是将 Pod 的平均 CPU 使用率维持在 50%:
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: web-app-hpa
namespace: production
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: web-app
minReplicas: 2
maxReplicas: 10
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 50
关键参数说明:
minReplicas / maxReplicas:定义副本数的上下限,防止无限扩容或缩容到 0。averageUtilization:目标利用率百分比,HPA 会确保所有 Pod 的平均值接近此值。autoscaling/v2:推荐使用 v2 版本,支持多种指标类型(Resource、Pods、Object、External)。
1.5 指标类型对比
| 指标类型 | 数据来源 | 典型场景 | 示例 |
|---|---|---|---|
| Resource | Metrics Server | CPU / 内存利用率 | averageUtilization: 50 |
| Pods | 自定义指标 API | 每个 Pod 的 QPS、请求延迟 | averageValue: 1000 |
| Object | 自定义指标 API | Ingress 网关的请求速率 | value: 500 |
| External | 外部监控系统 | 队列长度、数据库连接数 | value: 200 |
最佳实践:生产环境中建议同时使用 CPU 和自定义指标(如 QPS)进行混合伸缩,既能保证基础资源不超限,又能根据业务流量精确调整副本数。