上一篇【第24篇】Job和CronJob——一次性任务和定时任务下一篇【第26篇】Scheduler——Pod的婚介所是怎么工作的摘要手动扩缩容也太原始了吧——大促前扩到50个Pod促销一结束手动缩回5个半夜流量低谷机器全在空转烧钱。这不是运维是体力活。HPAHorizontal Pod Autoscaler就是K8s给你的自动驾驶仪设定好目标CPU利用率60%和上下限最少2个最多50个控制器自动采集指标、计算目标副本数、调用Deployment/StatefulSet扩缩容——全程不用你动一根手指。这篇文章从HPA的感知→决策→执行工作循环讲起先带你部署Metrics Server给集群装上心率监测然后配一个基于CPU的HPA看它自动扩缩容的魔法再讲minReplicas/maxReplicas怎么设不踩坑进阶到Prometheus自定义指标根据QPS扩容最后把HPA、VPA垂直扩缩容、ClusterAutoscaler节点扩缩容三兄弟摆在一起对比——看完你就知道弹性伸缩该怎么搭。一、HPA工作原理——“感知→决策→执行”1.1 扩缩容的三种维度【K8s弹性伸缩三级火箭】 ┌─────────────────────────────────────────────────────────┐ │ │ │ 第1级HPAHorizontal Pod Autoscaler │ │ ──────────────────────────────────────────── │ │ 水平扩缩容——增减Pod数量 │ │ CPU 80%了再加2个Pod → 4个Pod │ │ CPU 20%了停掉1个 → 3个Pod │ │ ┌───────────┐ ┌───────────┐ ┌───────────┐ │ │ │ Pod-1 │ │ Pod-2 │ │ Pod-3 │ → 4个 │ │ └───────────┘ └───────────┘ └───────────┘ │ │ │ │ 第2级VPAVertical Pod Autoscaler │ │ ──────────────────────────────────────────── │ │ 垂直扩缩容——调整单个Pod的CPU/内存配额 │ │ Pod一直用200m CPUrequest才100m提到300m │ │ ┌───────────────────┐ │ │ │ Pod │ │ │ │ CPU: 100m → 500m │ ← 容器资源变大 │ │ │ Mem: 256Mi → 1Gi │ │ │ └───────────────────┘ │ │ │ │ 第3级Cluster Autoscaler │ │ ──────────────────────────────────────────── │ │ 集群级扩缩容——增减Node │ │ Pod调度不下了加一台Node │ │ Node空转了回收掉 │ │ ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐ │ │ │Node-1│ │Node-2│ │Node-3│ │Node-4│ ← 新来的 │ │ └──────┘ └──────┘ └──────┘ └──────┘ │ └─────────────────────────────────────────────────────────┘要点这三种自治方式解决不同层面的问题HPA解决这个应用该跑几个PodVPA解决这个Pod该分配多少资源ClusterAutoscaler解决这个集群该有几台机器。三件套搭在一起才是完整的弹性伸缩方案——本文主要聚焦HPA。1.2 HPA的控制回路——15秒一个心跳【HPA 工作循环——每15秒一次体检决策】 ┌──────────────────────────────────────────────────────────┐ │ │ │ ① 采集指标 │ │ ┌──────────────────┐ │ │ │ Metrics Server │ ← 聚合所有Pod的CPU/内存数据 │ │ │ (kubelet内置) │ │ │ └────────┬─────────┘ │ │ │ REST API: /apis/metrics.k8s.io │ │ ▼ │ │ ② 计算利用率 │ │ ┌──────────────────────────────────────┐ │ │ │ 当前CPU利用率 实际使用量 / request │ │ │ │ 例Pod用200mrequest是500m │ │ │ │ 利用率 200/500 40% │ │ │ └────────┬─────────────────────────────┘ │ │ │ │ │ ▼ │ │ ③ 决定目标副本数 │ │ ┌──────────────────────────────────────┐ │ │ │ desiredReplicas ceil( │ │ │ │ currentReplicas × │ │ │ │ currentUtilization / targetUtil │ │ │ │ ) │ │ │ │ │ │ │ │ 例当前3个Pod利用率80%目标60% │ │ │ │ desired ceil(3 × 80/60) 4 │ │ │ │ → 扩容到4个 │ │ │ └────────┬─────────────────────────────┘ │ │ │ │ │ ▼ │ │ ④ 执行扩缩容 │ │ ┌──────────────────────────────────────┐ │ │ │ HPA → 修改 Deployment replicas 字段 │ │ │ │ Deployment Controller → 创建/删除Pod │ │ │ └──────────────────────────────────────┘ │ │ │ └──────────────────────────────────────────────────────────┘1.3 HPA的计算公式——“数学很简单参数很重要”# HPA核心公式desiredReplicasceil(currentReplicas × currentMetricValue / desiredMetricValue)# 举例# 当前5个Pod平均CPU使用率80%目标CPU使用率50%# desiredReplicas ceil(5 × 80 / 50) ceil(8) 8# → 扩容到8个Pod# 当前10个Pod平均CPU使用率20%目标CPU使用率50%# desiredReplicas ceil(10 × 20 / 50) ceil(4) 4# → 缩容到4个Pod要点HPA的数学很简单——就是个比例计算。但有两个关键限制(1) 扩容速率——每次最多翻倍3分钟内(2) 缩容速率——5分钟内不会缩容而且每次最多缩1/2。这些限制是为了防止抖动——指标短暂波动就疯狂扩缩。二、Metrics Server——给集群装上心率监测2.1 HPA的眼睛——没有Metrics ServerHPA就是瞎子【Metrics Server 在集群中的位置】 ┌─────────────────────────────────────────────────────────┐ │ │ │ 每个Node上的kubelet内置了cAdvisor │ │ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ │ │ Node-1 │ │ Node-2 │ │ Node-3 │ │ │ │ ┌─────────┐ │ │ ┌─────────┐ │ │ ┌─────────┐ │ │ │ │ │cAdvisor │ │ │ │cAdvisor │ │ │ │cAdvisor │ │ │ │ │ │(采集指标)│ │ │ │(采集指标)│ │ │ │(采集指标)│ │ │ │ │ └────┬────┘ │ │ └────┬────┘ │ │ └────┬────┘ │ │ │ └──────┼──────┘ └──────┼──────┘ └──────┼──────┘ │ │ │ │ │ │ │ └────────────────┼────────────────┘ │ │ │ │ │ ┌───────────▼───────────┐ │ │ │ Metrics Server │ ← 聚合器 │ │ │ (Deployment) │ │ │ │ 抓取所有kubelet指标 │ │ │ │ 聚合缓存 │ │ │ └───────────┬───────────┘ │ │ │ │ │ ┌───────────▼───────────┐ │ │ │ kube-apiserver │ │ │ │ /apis/metrics.k8s.io│ ← API端点 │ │ └───────────┬───────────┘ │ │ │ │ │ ┌───────────▼───────────┐ │ │ │ HPA Controller │ │ │ │ 每15秒拉一次指标 │ │ │ └───────────────────────┘ │ └─────────────────────────────────────────────────────────┘2.2 部署Metrics Server# 下载清单wgethttps://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml# 关键——如果集群用自签证书或非标准配置需要加参数# 编辑 components.yaml在 deployment 的 args 里加# metrics-server Deployment 关键参数apiVersion:apps/v1kind:Deploymentmetadata:name:metrics-servernamespace:kube-systemspec:template:spec:containers:-name:metrics-serverimage:registry.k8s.io/metrics-server/metrics-server:v0.7.0args:---cert-dir/tmp---secure-port4443---kubelet-preferred-address-typesInternalIP---kubelet-use-node-status-port---metric-resolution15s---kubelet-insecure-tls# 测试环境用这个跳过TLS验证# 生产环境应该正确配置CA证书而不是用insecure# 部署kubectl apply-fcomponents.yaml# 验证——等它Readykubectl get deployment metrics-server-nkube-system# NAME READY UP-TO-DATE AVAILABLE AGE# metrics-server 1/1 1 1 30s# 测试——查Pod/Node的CPU和内存指标kubectltoppods# NAME CPU(cores) MEMORY(bytes)# myapp-xxx 50m 128Mikubectltopnodes# NAME CPU(cores) CPU% MEMORY(bytes) MEMORY%# node-1 500m 25% 2Gi 30%# node-2 300m 15% 1Gi 15%# 如果 kubectl top 不工作检查kubectl get apiservice v1beta1.metrics.k8s.io# NAME SERVICE AVAILABLE AGE# v1beta1.metrics.k8s.io kube-system/metrics-server True 5m# 查看metrics-server日志kubectl logs-nkube-system deployment/metrics-server# 常见问题TLS证书报错# 临时解决加 --kubelet-insecure-tls# 正式解决配好 --kubelet-certificate-authority要点Metrics Server的正确性直接决定HPA的精确度。如果Metrics Server挂了或不正常HPA会失明——看不到指标无法做扩缩容决策现有的Pod数量会保持不变。kubectl top pods能正常工作是HPA可用的最基本前提。三、基于CPU/内存的HPA——“最常见的自动挡”3.1 部署一个带HPA的示例应用# 1. Deployment——一个简单的CPU密集型应用apiVersion:apps/v1kind:Deploymentmetadata:name:php-apachespec:replicas:1selector:matchLabels:app:php-apachetemplate:metadata:labels:app:php-apachespec:containers:-name:php-apacheimage:registry.k8s.io/hpa-exampleports:-containerPort:80resources:requests:cpu:200m# ← 这个值很重要HPA的基准memory:128Milimits:cpu:500mmemory:256Mi---# 2. ServiceapiVersion:v1kind:Servicemetadata:name:php-apachespec:selector:app:php-apacheports:-port:80---# 3. HPA——主角apiVersion:autoscaling/v2kind:HorizontalPodAutoscalermetadata:name:php-apache-hpaspec:scaleTargetRef:apiVersion:apps/v1kind:Deploymentname:php-apache# 管这个Deployment的副本数minReplicas:2# 最少2个PodmaxReplicas:10# 最多10个Podmetrics:-type:Resourceresource:name:cputarget:type:UtilizationaverageUtilization:50# 目标平均CPU利用率50%-type:Resourceresource:name:memorytarget:type:UtilizationaverageUtilization:80# 目标平均内存利用率80%behavior:# 自定义扩缩容行为v2才支持scaleDown:stabilizationWindowSeconds:300# 缩容前观察300秒policies:-type:Percentvalue:50# 每次最多缩50%periodSeconds:60scaleUp:stabilizationWindowSeconds:0# 扩容不需要观望policies:-type:Percentvalue:100# 每次最多翻倍periodSeconds:15-type:Podsvalue:4# 或每次最多加4个PodperiodSeconds:15selectPolicy:Max# 选两个策略中扩容更多的那个# 部署kubectl apply-fphp-apache-hpa.yaml# 查看HPA状态——初始状态kubectl get hpa php-apache-hpa# NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS# php-apache-hpa Deployment/php-apache 0%/50% 2 10 2# ↑# TARGETS: 当前值/目标值3.2 压测——看HPA自动扩缩容# 1. 开一个终端持续观察HPA变化kubectl get hpa php-apache-hpa-w# 2. 在另一个终端启动压测kubectl run-it--rmload-generator--imagebusybox--restartNever --\/bin/sh-cwhile true; do wget -q -O- http://php-apache; done# 3. 观察HPA自动扩容# 0%/50% 2 10 2 ← 初始基本没负载# 85%/50% 2 10 2 ← 压测开始CPU飙升# 85%/50% 2 10 4 ← HPA反应扩容到4# 72%/50% 2 10 4 ← 4个Pod分摊CPU下降# 62%/50% 2 10 8 ← 还不够继续扩到8# 48%/50% 2 10 8 ← 8个Pod接近目标了# 45%/50% 2 10 8 ← 稳定在目标附近# 4. 停止压测CtrlC# 5. 观察缩容——大约5分钟后# 20%/50% 2 10 8 ← 负载下降# 15%/50% 2 10 4 ← 缩容到4# 10%/50% 2 10 2 ← 回到2minReplicas【HPA自动扩缩容过程——可视化】 Pod 数量 10│ ___ │ / \ 8│ ┌─────────┐ └────┐ │ / │ │ 6│ / │ │ │ / │ │ 4│ ┌──────────┐ │ │ / │ │ 2│──────────┘ │ │ └────────── │ │ │ └───────────────────────┴─────────────┴─────────────────────► 时间 正常 |─── 压测开始自动扩容 ──| 压测结束自动缩容 CPU利用率 100%│ ▲ │ ╱ ╲ 50%│──────╱─────╲────────────────────────────────────── │ ╱ ╲ │ ╱ ╲ 0%│───┘ └────────────────────────────────────► 时间要点HPA有缩容保护期——默认stabilizationWindowSeconds: 3005分钟。即使CPU立刻降到10%HPA也会等5分钟确认这个低负载是持续的才会缩容。这是为了防止抖动——负载短暂下降就缩容过两秒负载回来又扩容反复横跳。3.3 behavior字段详解——调教HPA的脾气# 缩容behavoir——慢、稳、别冲动behavior:scaleDown:stabilizationWindowSeconds:300# 观察300秒再缩容policies:-type:Podsvalue:1# 每次最多减1个PodperiodSeconds:60# 每60秒-type:Percentvalue:10# 或每次最多减10%periodSeconds:60selectPolicy:Min# 选更保守的策略# 扩容behavoir——快、果断、扛住流量scaleUp:stabilizationWindowSeconds:0# 不需要观望立即扩容policies:-type:Percentvalue:100# 最多翻倍periodSeconds:15-type:Podsvalue:4# 或最多加4个periodSeconds:15selectPolicy:Max# 选扩容更多的策略参数扩容推荐缩容推荐原因stabilizationWindowSeconds0立刻扩容300等5分钟确认扩容不能等缩容别太急selectPolicyMax选扩最多的Min选缩最少的扩容要激进缩容要保守periodSeconds15快速反应60-120慢慢来CPU尖刺转瞬即逝要快缩容不急要点HPA默认的behavior在大多数场景都够用。如果你需要调整——记住一个原则扩容激进、缩容保守。扩容慢了用户体验受损缩容快了服务可能抖动。宁可多浪费几分钟CPU也别让服务因为缩容太快而崩溃。四、minReplicas/maxReplicas——“下限和上限怎么定”4.1 设置策略【minReplicas 和 maxReplicas 设置指南】 minReplicas保证最低服务能力 ┌──────────────────────────────────────────────┐ │ 设多少答案取决于 │ │ │ │ 1. 至少2个——单Pod挂了还有备份 │ │ 如果是StatefulSet且有ReadWriteOnce存储 │ │ 可能只能设1个 │ │ │ │ 2. 低峰时至少能处理基础流量 │ │ → 看历史监控凌晨3点的QPS多少 │ │ → 1个Pod能扛多少QPS │ │ → minReplicas ceil(凌晨QPS / 单Pod容量) │ │ │ │ 3. PodDisruptionBudget配合—— │ │ 主动驱逐Node维护时minReplicas能兜底 │ └──────────────────────────────────────────────┘ maxReplicas防无限膨胀 ┌──────────────────────────────────────────────┐ │ 设多少考虑 │ │ │ │ 1. 集群资源上限—— │ │ maxReplicas × Pod request 集群剩余资源 │ │ │ │ 2. 下游服务承载能力—— │ │ 你的服务扩到100个数据库扛得住吗 │ │ 别让HPA把你的数据库冲垮 │ │ │ │ 3. 预算限制—— │ │ 弹性是好事但不设上限云账单会爆炸 │ └──────────────────────────────────────────────┘# 典型配置apiVersion:autoscaling/v2kind:HorizontalPodAutoscalermetadata:name:api-server-hpaspec:minReplicas:3# 至少3个高可用 抗住基础流量maxReplicas:20# 最多20个别把数据库压垮metrics:-type:Resourceresource:name:cputarget:type:UtilizationaverageUtilization:60要点maxReplicas不是越大越好——你要考虑的不是K8s能管多少Pod而是下游能扛多少并发。你的API服务从10个Pod扩到100个数据库连接数暴涨Redis连接也没缓存好——这才是真正的瓶颈。HPA只管得了你的Pod数量管不了你的架构瓶颈。五、自定义指标HPA——“不只是CPU”5.1 为什么需要自定义指标CPU利用率有时候不够精确——你的应用可能在CPU 30%时就因为线程池满了而卡顿或者CPU 80%了但响应依然飞快。【HPA指标演进——从粗到细】 第一代CPU/内存Resource Metrics 第二代自定义指标Custom Metrics ┌────────────────────────────┐ ┌────────────────────────────┐ │ 只看CPU和内存 │ │ 看QPS、延迟、队列长度等 │ │ │ │ │ │ 粗粒度——CPU62%该扩容了 │ │ 精粒度——请求延迟500ms了 │ │ │ │ 该扩容了 │ │ 适用大多数Web应用 │ │ 适用对延迟敏感的服务 │ │ 成本只装Metrics Server │ │ 成本需要PrometheusAdapter │ └────────────────────────────┘ └────────────────────────────┘5.2 部署Prometheus Adapter——“连接Prometheus和HPA”【Prometheus Adapter 架构】 ┌─────────────┐ ┌──────────────────┐ ┌─────────────┐ │ Prometheus │────►│ Prometheus │────►│ kube-api │ │ (存储指标) │ │ Adapter │ │ server │ │ │ │ (翻译PromQL→ │ │ /apis/custom │ │ http_ │ │ K8s Metrics API) │ │ .metrics.k8s │ │ requests_ │ └──────────────────┘ │ .io │ │ total │ └──────┬──────┘ └─────────────┘ │ ▼ ┌─────────────┐ │ HPA │ │ Controller │ │ 根据QPS扩缩容 │ └─────────────┘# 基于QPS的HPAPrometheus自定义指标apiVersion:autoscaling/v2kind:HorizontalPodAutoscalermetadata:name:api-hpa-qpsspec:scaleTargetRef:apiVersion:apps/v1kind:Deploymentname:api-serverminReplicas:2maxReplicas:50metrics:-type:Podspods:metric:name:http_requests_per_second# Prometheus里存的指标名target:type:AverageValueaverageValue:1000# 每Pod每秒处理1000个请求# 同时监控CPU——多个条件取更需要扩容的-type:Resourceresource:name:cputarget:type:UtilizationaverageUtilization:70# 多个指标组合——HPA选需要最多Pod的那个apiVersion:autoscaling/v2kind:HorizontalPodAutoscalermetadata:name:multi-metric-hpaspec:scaleTargetRef:apiVersion:apps/v1kind:Deploymentname:api-serverminReplicas:3maxReplicas:30metrics:-type:Resourceresource:name:cputarget:type:UtilizationaverageUtilization:60# CPU到60%就扩-type:Resourceresource:name:memorytarget:type:UtilizationaverageUtilization:80# 内存到80%也扩-type:Podspods:metric:name:requests_per_secondtarget:type:AverageValueaverageValue:500# 或每Pod超过500 QPS就扩# HPA逻辑三个条件分别算目标副本数取最大值# CPU说扩到5个内存说扩到3个QPS说扩到8个 → 实际扩到8个5.3 常用自定义指标场景指标类型典型场景指标举例QPS/RPSWeb API、网关rate(http_requests_total[1m])延迟对延迟敏感的服务histogram_quantile(0.99, http_request_duration_seconds)队列长度消息队列消费rabbitmq_queue_messages{queueorders}连接数数据库代理、连接池pg_stat_database_numbackends业务指标订单积压、待处理任务pending_orders_count要点配置多个指标时HPA取所有指标中要求最多Pod的那个值。这是一种或逻辑——任何一个指标超标都触发扩容。但注意指标之间可能会有冲突——一个指标说扩容另一个说缩容。解决方式是给每个指标设合理的阈值范围避免互相打架。六、HPA VPA ClusterAutoscaler全家桶6.1 三件套分工组件扩缩容对象触发条件典型配置HPAPod数量CPU/内存/自定义指标minReplicas:2, maxReplicas:20, cpu:60%VPAPod资源配额CPU/Mem request实际使用 vs request差距大updateMode: Auto, minAllowed/maxAllowedClusterAutoscalerNode数量有Pending Pod调度不下--nodes2:10:node-group-1【三件套协同工作流程】 1. 用户请求流量上涨 │ ▼ 2. Pod CPU使用率飙到75% │ ▼ 3. HPA: 需要更多Pod 修改 replicas: 3 → 5 │ ▼ 4. Scheduler: 新Pod调度不下 Node-1和Node-2都满了 │ ▼ 5. ClusterAutoscaler: 我加一台Node 新Node加入集群 │ ▼ 6. 新Pod调度到新Node上 │ ▼ 7. VPA长期观察: 这些Pod的CPU request 设太低了实际都是超额使用调大 修改 300m → 500m# VPA 配置示例apiVersion:autoscaling.k8s.io/v1kind:VerticalPodAutoscalermetadata:name:api-server-vpaspec:targetRef:apiVersion:apps/v1kind:Deploymentname:api-serverupdatePolicy:updateMode:Auto# Auto: 自动调整Off: 只建议不执行resourcePolicy:containerPolicies:-containerName:*minAllowed:# 最低资源保证cpu:100mmemory:128MimaxAllowed:# 最高资源限制控成本cpu:2memory:4GicontrolledResources:[cpu,memory]要点HPA和VPA不要同时用Auto模式管理同一个Deployment——它们会打架。HPA根据CPU利用率扩缩Pod数量VPA改Pod的CPU request——两者互相影响对方计算基准可能导致振荡。推荐做法是HPA用Auto模式做水平伸缩VPA用Off模式只给建议或者只设minAllowed/maxAllowed当资源护栏。6.2 HPA ClusterAutoscaler 完美组合# 典型配置场景——云上自动伸缩集群# AWS EKS 示例eksctl create cluster\--nameauto-scaling-cluster\--nodegroup-nameworkers\--nodes2\# 初始2个节点--nodes-min2\# 最少2个--nodes-max20\# 最多20个--node-typet3.medium# 然后部署HPA管理应用Podkubectl autoscale deployment api-server\--cpu-percent60\--min2--max50# 完整验证链路# 1. 压测 → HPA扩容Pod → 新Pod调度不下 → ClusterAutoscaler加Node# 2. 停止压测 → HPA缩容Pod → Node空闲 → ClusterAutoscaler回收Nodekubectl get hpa-w# 看HPA扩缩kubectl get nodes-w# 看Node增减kubectl get pods-w# 看Pod生灭七、HPA常用命令和调试# 创建HPA一行命令kubectl autoscale deployment myapp --cpu-percent50--min2--max10# 查看HPA状态kubectl get hpa kubectl get hpa myapp-hpa-w# 实时观察# 查看HPA详细信息和历史kubectl describe hpa myapp-hpa# 重点看# Metrics: (当前指标值)# Conditions: AbleToScale/ScalingActive/ScalingLimited# Events: (扩缩容历史)# 查看HPA YAML看完整配置kubectl get hpa myapp-hpa-oyaml# 修改HPAkubectl edit hpa myapp-hpa# 或者kubectl patch hpa myapp-hpa--patch\{spec:{maxReplicas:20}}# 删除HPA不会删除Deploymentkubectl delete hpa myapp-hpa# 调试——为什么HPA不扩容kubectl describe hpa myapp-hpa# 看 Conditions# ScalingLimited: True, Reason: TooFewReplicas → minReplicas设置问题# ScalingLimited: True, Reason: TooManyReplicas → 已经到maxReplicas了# 检查Metrics Server是否正常kubectl get apiservice v1beta1.metrics.k8s.io kubectltoppods kubectltopnodes# 模拟HPA的计算逻辑——手动验证# 当前CPU: 80%, 目标: 50%, 当前Pod: 3# 预期ceil(3 × 80/50) 5# HPA事件——看它都在干什么kubectl get events --field-selectorinvolvedObject.kindHorizontalPodAutoscaler# 7m SuccessfulRescale New size: 4; reason: cpu resource utilization (percentage of request) above target# 5m SuccessfulRescale New size: 8; reason: cpu resource utilization (percentage of request) above target# 20m SuccessfulRescale New size: 2; reason: All metrics below target本篇小结HPA让K8s从手动挡升级为自动挡把运维从盯盘→手动扩缩的体力活中解放出来工作循环每15秒采集指标→计算目标副本数→修改Deployment replicas——全程自动化核心公式desiredReplicas ceil(current × currentUtil / targetUtil)简单但有保护机制防止抖动Metrics Server前置条件kubectl top pods能跑HPA才能工作——这是HPA的眼睛behavior调优扩容激进立刻翻倍、缩容保守观察5分钟再动——宁可多花点CPU也别让服务抖动自定义指标CPU不够精确时上PrometheusAdapter按QPS/延迟/队列长度扩容更精准三件套配合HPA水平扩Pod VPA垂直调资源 ClusterAutoscaler加机器 完整弹性方案下一篇咱们聊K8s调度器——Pod的房产中介。当你创建了一个PodScheduler是怎么从几百个Node里选一个最合适的打分算法、亲和性、污点容忍、拓扑分布约束——这些才是调度背后的黑科技。上一篇【第24篇】Job和CronJob——一次性任务和定时任务下一篇【第26篇】Scheduler——Pod的婚介所是怎么工作的 【Kubernetes从入门到精通】第25篇：HPA——K8s的“自动弹性伸缩“魔法
上一篇【第24篇】Job和CronJob——一次性任务和定时任务下一篇【第26篇】Scheduler——Pod的婚介所是怎么工作的摘要手动扩缩容也太原始了吧——大促前扩到50个Pod促销一结束手动缩回5个半夜流量低谷机器全在空转烧钱。这不是运维是体力活。HPAHorizontal Pod Autoscaler就是K8s给你的自动驾驶仪设定好目标CPU利用率60%和上下限最少2个最多50个控制器自动采集指标、计算目标副本数、调用Deployment/StatefulSet扩缩容——全程不用你动一根手指。这篇文章从HPA的感知→决策→执行工作循环讲起先带你部署Metrics Server给集群装上心率监测然后配一个基于CPU的HPA看它自动扩缩容的魔法再讲minReplicas/maxReplicas怎么设不踩坑进阶到Prometheus自定义指标根据QPS扩容最后把HPA、VPA垂直扩缩容、ClusterAutoscaler节点扩缩容三兄弟摆在一起对比——看完你就知道弹性伸缩该怎么搭。一、HPA工作原理——“感知→决策→执行”1.1 扩缩容的三种维度【K8s弹性伸缩三级火箭】 ┌─────────────────────────────────────────────────────────┐ │ │ │ 第1级HPAHorizontal Pod Autoscaler │ │ ──────────────────────────────────────────── │ │ 水平扩缩容——增减Pod数量 │ │ CPU 80%了再加2个Pod → 4个Pod │ │ CPU 20%了停掉1个 → 3个Pod │ │ ┌───────────┐ ┌───────────┐ ┌───────────┐ │ │ │ Pod-1 │ │ Pod-2 │ │ Pod-3 │ → 4个 │ │ └───────────┘ └───────────┘ └───────────┘ │ │ │ │ 第2级VPAVertical Pod Autoscaler │ │ ──────────────────────────────────────────── │ │ 垂直扩缩容——调整单个Pod的CPU/内存配额 │ │ Pod一直用200m CPUrequest才100m提到300m │ │ ┌───────────────────┐ │ │ │ Pod │ │ │ │ CPU: 100m → 500m │ ← 容器资源变大 │ │ │ Mem: 256Mi → 1Gi │ │ │ └───────────────────┘ │ │ │ │ 第3级Cluster Autoscaler │ │ ──────────────────────────────────────────── │ │ 集群级扩缩容——增减Node │ │ Pod调度不下了加一台Node │ │ Node空转了回收掉 │ │ ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐ │ │ │Node-1│ │Node-2│ │Node-3│ │Node-4│ ← 新来的 │ │ └──────┘ └──────┘ └──────┘ └──────┘ │ └─────────────────────────────────────────────────────────┘要点这三种自治方式解决不同层面的问题HPA解决这个应用该跑几个PodVPA解决这个Pod该分配多少资源ClusterAutoscaler解决这个集群该有几台机器。三件套搭在一起才是完整的弹性伸缩方案——本文主要聚焦HPA。1.2 HPA的控制回路——15秒一个心跳【HPA 工作循环——每15秒一次体检决策】 ┌──────────────────────────────────────────────────────────┐ │ │ │ ① 采集指标 │ │ ┌──────────────────┐ │ │ │ Metrics Server │ ← 聚合所有Pod的CPU/内存数据 │ │ │ (kubelet内置) │ │ │ └────────┬─────────┘ │ │ │ REST API: /apis/metrics.k8s.io │ │ ▼ │ │ ② 计算利用率 │ │ ┌──────────────────────────────────────┐ │ │ │ 当前CPU利用率 实际使用量 / request │ │ │ │ 例Pod用200mrequest是500m │ │ │ │ 利用率 200/500 40% │ │ │ └────────┬─────────────────────────────┘ │ │ │ │ │ ▼ │ │ ③ 决定目标副本数 │ │ ┌──────────────────────────────────────┐ │ │ │ desiredReplicas ceil( │ │ │ │ currentReplicas × │ │ │ │ currentUtilization / targetUtil │ │ │ │ ) │ │ │ │ │ │ │ │ 例当前3个Pod利用率80%目标60% │ │ │ │ desired ceil(3 × 80/60) 4 │ │ │ │ → 扩容到4个 │ │ │ └────────┬─────────────────────────────┘ │ │ │ │ │ ▼ │ │ ④ 执行扩缩容 │ │ ┌──────────────────────────────────────┐ │ │ │ HPA → 修改 Deployment replicas 字段 │ │ │ │ Deployment Controller → 创建/删除Pod │ │ │ └──────────────────────────────────────┘ │ │ │ └──────────────────────────────────────────────────────────┘1.3 HPA的计算公式——“数学很简单参数很重要”# HPA核心公式desiredReplicasceil(currentReplicas × currentMetricValue / desiredMetricValue)# 举例# 当前5个Pod平均CPU使用率80%目标CPU使用率50%# desiredReplicas ceil(5 × 80 / 50) ceil(8) 8# → 扩容到8个Pod# 当前10个Pod平均CPU使用率20%目标CPU使用率50%# desiredReplicas ceil(10 × 20 / 50) ceil(4) 4# → 缩容到4个Pod要点HPA的数学很简单——就是个比例计算。但有两个关键限制(1) 扩容速率——每次最多翻倍3分钟内(2) 缩容速率——5分钟内不会缩容而且每次最多缩1/2。这些限制是为了防止抖动——指标短暂波动就疯狂扩缩。二、Metrics Server——给集群装上心率监测2.1 HPA的眼睛——没有Metrics ServerHPA就是瞎子【Metrics Server 在集群中的位置】 ┌─────────────────────────────────────────────────────────┐ │ │ │ 每个Node上的kubelet内置了cAdvisor │ │ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ │ │ Node-1 │ │ Node-2 │ │ Node-3 │ │ │ │ ┌─────────┐ │ │ ┌─────────┐ │ │ ┌─────────┐ │ │ │ │ │cAdvisor │ │ │ │cAdvisor │ │ │ │cAdvisor │ │ │ │ │ │(采集指标)│ │ │ │(采集指标)│ │ │ │(采集指标)│ │ │ │ │ └────┬────┘ │ │ └────┬────┘ │ │ └────┬────┘ │ │ │ └──────┼──────┘ └──────┼──────┘ └──────┼──────┘ │ │ │ │ │ │ │ └────────────────┼────────────────┘ │ │ │ │ │ ┌───────────▼───────────┐ │ │ │ Metrics Server │ ← 聚合器 │ │ │ (Deployment) │ │ │ │ 抓取所有kubelet指标 │ │ │ │ 聚合缓存 │ │ │ └───────────┬───────────┘ │ │ │ │ │ ┌───────────▼───────────┐ │ │ │ kube-apiserver │ │ │ │ /apis/metrics.k8s.io│ ← API端点 │ │ └───────────┬───────────┘ │ │ │ │ │ ┌───────────▼───────────┐ │ │ │ HPA Controller │ │ │ │ 每15秒拉一次指标 │ │ │ └───────────────────────┘ │ └─────────────────────────────────────────────────────────┘2.2 部署Metrics Server# 下载清单wgethttps://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml# 关键——如果集群用自签证书或非标准配置需要加参数# 编辑 components.yaml在 deployment 的 args 里加# metrics-server Deployment 关键参数apiVersion:apps/v1kind:Deploymentmetadata:name:metrics-servernamespace:kube-systemspec:template:spec:containers:-name:metrics-serverimage:registry.k8s.io/metrics-server/metrics-server:v0.7.0args:---cert-dir/tmp---secure-port4443---kubelet-preferred-address-typesInternalIP---kubelet-use-node-status-port---metric-resolution15s---kubelet-insecure-tls# 测试环境用这个跳过TLS验证# 生产环境应该正确配置CA证书而不是用insecure# 部署kubectl apply-fcomponents.yaml# 验证——等它Readykubectl get deployment metrics-server-nkube-system# NAME READY UP-TO-DATE AVAILABLE AGE# metrics-server 1/1 1 1 30s# 测试——查Pod/Node的CPU和内存指标kubectltoppods# NAME CPU(cores) MEMORY(bytes)# myapp-xxx 50m 128Mikubectltopnodes# NAME CPU(cores) CPU% MEMORY(bytes) MEMORY%# node-1 500m 25% 2Gi 30%# node-2 300m 15% 1Gi 15%# 如果 kubectl top 不工作检查kubectl get apiservice v1beta1.metrics.k8s.io# NAME SERVICE AVAILABLE AGE# v1beta1.metrics.k8s.io kube-system/metrics-server True 5m# 查看metrics-server日志kubectl logs-nkube-system deployment/metrics-server# 常见问题TLS证书报错# 临时解决加 --kubelet-insecure-tls# 正式解决配好 --kubelet-certificate-authority要点Metrics Server的正确性直接决定HPA的精确度。如果Metrics Server挂了或不正常HPA会失明——看不到指标无法做扩缩容决策现有的Pod数量会保持不变。kubectl top pods能正常工作是HPA可用的最基本前提。三、基于CPU/内存的HPA——“最常见的自动挡”3.1 部署一个带HPA的示例应用# 1. Deployment——一个简单的CPU密集型应用apiVersion:apps/v1kind:Deploymentmetadata:name:php-apachespec:replicas:1selector:matchLabels:app:php-apachetemplate:metadata:labels:app:php-apachespec:containers:-name:php-apacheimage:registry.k8s.io/hpa-exampleports:-containerPort:80resources:requests:cpu:200m# ← 这个值很重要HPA的基准memory:128Milimits:cpu:500mmemory:256Mi---# 2. ServiceapiVersion:v1kind:Servicemetadata:name:php-apachespec:selector:app:php-apacheports:-port:80---# 3. HPA——主角apiVersion:autoscaling/v2kind:HorizontalPodAutoscalermetadata:name:php-apache-hpaspec:scaleTargetRef:apiVersion:apps/v1kind:Deploymentname:php-apache# 管这个Deployment的副本数minReplicas:2# 最少2个PodmaxReplicas:10# 最多10个Podmetrics:-type:Resourceresource:name:cputarget:type:UtilizationaverageUtilization:50# 目标平均CPU利用率50%-type:Resourceresource:name:memorytarget:type:UtilizationaverageUtilization:80# 目标平均内存利用率80%behavior:# 自定义扩缩容行为v2才支持scaleDown:stabilizationWindowSeconds:300# 缩容前观察300秒policies:-type:Percentvalue:50# 每次最多缩50%periodSeconds:60scaleUp:stabilizationWindowSeconds:0# 扩容不需要观望policies:-type:Percentvalue:100# 每次最多翻倍periodSeconds:15-type:Podsvalue:4# 或每次最多加4个PodperiodSeconds:15selectPolicy:Max# 选两个策略中扩容更多的那个# 部署kubectl apply-fphp-apache-hpa.yaml# 查看HPA状态——初始状态kubectl get hpa php-apache-hpa# NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS# php-apache-hpa Deployment/php-apache 0%/50% 2 10 2# ↑# TARGETS: 当前值/目标值3.2 压测——看HPA自动扩缩容# 1. 开一个终端持续观察HPA变化kubectl get hpa php-apache-hpa-w# 2. 在另一个终端启动压测kubectl run-it--rmload-generator--imagebusybox--restartNever --\/bin/sh-cwhile true; do wget -q -O- http://php-apache; done# 3. 观察HPA自动扩容# 0%/50% 2 10 2 ← 初始基本没负载# 85%/50% 2 10 2 ← 压测开始CPU飙升# 85%/50% 2 10 4 ← HPA反应扩容到4# 72%/50% 2 10 4 ← 4个Pod分摊CPU下降# 62%/50% 2 10 8 ← 还不够继续扩到8# 48%/50% 2 10 8 ← 8个Pod接近目标了# 45%/50% 2 10 8 ← 稳定在目标附近# 4. 停止压测CtrlC# 5. 观察缩容——大约5分钟后# 20%/50% 2 10 8 ← 负载下降# 15%/50% 2 10 4 ← 缩容到4# 10%/50% 2 10 2 ← 回到2minReplicas【HPA自动扩缩容过程——可视化】 Pod 数量 10│ ___ │ / \ 8│ ┌─────────┐ └────┐ │ / │ │ 6│ / │ │ │ / │ │ 4│ ┌──────────┐ │ │ / │ │ 2│──────────┘ │ │ └────────── │ │ │ └───────────────────────┴─────────────┴─────────────────────► 时间 正常 |─── 压测开始自动扩容 ──| 压测结束自动缩容 CPU利用率 100%│ ▲ │ ╱ ╲ 50%│──────╱─────╲────────────────────────────────────── │ ╱ ╲ │ ╱ ╲ 0%│───┘ └────────────────────────────────────► 时间要点HPA有缩容保护期——默认stabilizationWindowSeconds: 3005分钟。即使CPU立刻降到10%HPA也会等5分钟确认这个低负载是持续的才会缩容。这是为了防止抖动——负载短暂下降就缩容过两秒负载回来又扩容反复横跳。3.3 behavior字段详解——调教HPA的脾气# 缩容behavoir——慢、稳、别冲动behavior:scaleDown:stabilizationWindowSeconds:300# 观察300秒再缩容policies:-type:Podsvalue:1# 每次最多减1个PodperiodSeconds:60# 每60秒-type:Percentvalue:10# 或每次最多减10%periodSeconds:60selectPolicy:Min# 选更保守的策略# 扩容behavoir——快、果断、扛住流量scaleUp:stabilizationWindowSeconds:0# 不需要观望立即扩容policies:-type:Percentvalue:100# 最多翻倍periodSeconds:15-type:Podsvalue:4# 或最多加4个periodSeconds:15selectPolicy:Max# 选扩容更多的策略参数扩容推荐缩容推荐原因stabilizationWindowSeconds0立刻扩容300等5分钟确认扩容不能等缩容别太急selectPolicyMax选扩最多的Min选缩最少的扩容要激进缩容要保守periodSeconds15快速反应60-120慢慢来CPU尖刺转瞬即逝要快缩容不急要点HPA默认的behavior在大多数场景都够用。如果你需要调整——记住一个原则扩容激进、缩容保守。扩容慢了用户体验受损缩容快了服务可能抖动。宁可多浪费几分钟CPU也别让服务因为缩容太快而崩溃。四、minReplicas/maxReplicas——“下限和上限怎么定”4.1 设置策略【minReplicas 和 maxReplicas 设置指南】 minReplicas保证最低服务能力 ┌──────────────────────────────────────────────┐ │ 设多少答案取决于 │ │ │ │ 1. 至少2个——单Pod挂了还有备份 │ │ 如果是StatefulSet且有ReadWriteOnce存储 │ │ 可能只能设1个 │ │ │ │ 2. 低峰时至少能处理基础流量 │ │ → 看历史监控凌晨3点的QPS多少 │ │ → 1个Pod能扛多少QPS │ │ → minReplicas ceil(凌晨QPS / 单Pod容量) │ │ │ │ 3. PodDisruptionBudget配合—— │ │ 主动驱逐Node维护时minReplicas能兜底 │ └──────────────────────────────────────────────┘ maxReplicas防无限膨胀 ┌──────────────────────────────────────────────┐ │ 设多少考虑 │ │ │ │ 1. 集群资源上限—— │ │ maxReplicas × Pod request 集群剩余资源 │ │ │ │ 2. 下游服务承载能力—— │ │ 你的服务扩到100个数据库扛得住吗 │ │ 别让HPA把你的数据库冲垮 │ │ │ │ 3. 预算限制—— │ │ 弹性是好事但不设上限云账单会爆炸 │ └──────────────────────────────────────────────┘# 典型配置apiVersion:autoscaling/v2kind:HorizontalPodAutoscalermetadata:name:api-server-hpaspec:minReplicas:3# 至少3个高可用 抗住基础流量maxReplicas:20# 最多20个别把数据库压垮metrics:-type:Resourceresource:name:cputarget:type:UtilizationaverageUtilization:60要点maxReplicas不是越大越好——你要考虑的不是K8s能管多少Pod而是下游能扛多少并发。你的API服务从10个Pod扩到100个数据库连接数暴涨Redis连接也没缓存好——这才是真正的瓶颈。HPA只管得了你的Pod数量管不了你的架构瓶颈。五、自定义指标HPA——“不只是CPU”5.1 为什么需要自定义指标CPU利用率有时候不够精确——你的应用可能在CPU 30%时就因为线程池满了而卡顿或者CPU 80%了但响应依然飞快。【HPA指标演进——从粗到细】 第一代CPU/内存Resource Metrics 第二代自定义指标Custom Metrics ┌────────────────────────────┐ ┌────────────────────────────┐ │ 只看CPU和内存 │ │ 看QPS、延迟、队列长度等 │ │ │ │ │ │ 粗粒度——CPU62%该扩容了 │ │ 精粒度——请求延迟500ms了 │ │ │ │ 该扩容了 │ │ 适用大多数Web应用 │ │ 适用对延迟敏感的服务 │ │ 成本只装Metrics Server │ │ 成本需要PrometheusAdapter │ └────────────────────────────┘ └────────────────────────────┘5.2 部署Prometheus Adapter——“连接Prometheus和HPA”【Prometheus Adapter 架构】 ┌─────────────┐ ┌──────────────────┐ ┌─────────────┐ │ Prometheus │────►│ Prometheus │────►│ kube-api │ │ (存储指标) │ │ Adapter │ │ server │ │ │ │ (翻译PromQL→ │ │ /apis/custom │ │ http_ │ │ K8s Metrics API) │ │ .metrics.k8s │ │ requests_ │ └──────────────────┘ │ .io │ │ total │ └──────┬──────┘ └─────────────┘ │ ▼ ┌─────────────┐ │ HPA │ │ Controller │ │ 根据QPS扩缩容 │ └─────────────┘# 基于QPS的HPAPrometheus自定义指标apiVersion:autoscaling/v2kind:HorizontalPodAutoscalermetadata:name:api-hpa-qpsspec:scaleTargetRef:apiVersion:apps/v1kind:Deploymentname:api-serverminReplicas:2maxReplicas:50metrics:-type:Podspods:metric:name:http_requests_per_second# Prometheus里存的指标名target:type:AverageValueaverageValue:1000# 每Pod每秒处理1000个请求# 同时监控CPU——多个条件取更需要扩容的-type:Resourceresource:name:cputarget:type:UtilizationaverageUtilization:70# 多个指标组合——HPA选需要最多Pod的那个apiVersion:autoscaling/v2kind:HorizontalPodAutoscalermetadata:name:multi-metric-hpaspec:scaleTargetRef:apiVersion:apps/v1kind:Deploymentname:api-serverminReplicas:3maxReplicas:30metrics:-type:Resourceresource:name:cputarget:type:UtilizationaverageUtilization:60# CPU到60%就扩-type:Resourceresource:name:memorytarget:type:UtilizationaverageUtilization:80# 内存到80%也扩-type:Podspods:metric:name:requests_per_secondtarget:type:AverageValueaverageValue:500# 或每Pod超过500 QPS就扩# HPA逻辑三个条件分别算目标副本数取最大值# CPU说扩到5个内存说扩到3个QPS说扩到8个 → 实际扩到8个5.3 常用自定义指标场景指标类型典型场景指标举例QPS/RPSWeb API、网关rate(http_requests_total[1m])延迟对延迟敏感的服务histogram_quantile(0.99, http_request_duration_seconds)队列长度消息队列消费rabbitmq_queue_messages{queueorders}连接数数据库代理、连接池pg_stat_database_numbackends业务指标订单积压、待处理任务pending_orders_count要点配置多个指标时HPA取所有指标中要求最多Pod的那个值。这是一种或逻辑——任何一个指标超标都触发扩容。但注意指标之间可能会有冲突——一个指标说扩容另一个说缩容。解决方式是给每个指标设合理的阈值范围避免互相打架。六、HPA VPA ClusterAutoscaler全家桶6.1 三件套分工组件扩缩容对象触发条件典型配置HPAPod数量CPU/内存/自定义指标minReplicas:2, maxReplicas:20, cpu:60%VPAPod资源配额CPU/Mem request实际使用 vs request差距大updateMode: Auto, minAllowed/maxAllowedClusterAutoscalerNode数量有Pending Pod调度不下--nodes2:10:node-group-1【三件套协同工作流程】 1. 用户请求流量上涨 │ ▼ 2. Pod CPU使用率飙到75% │ ▼ 3. HPA: 需要更多Pod 修改 replicas: 3 → 5 │ ▼ 4. Scheduler: 新Pod调度不下 Node-1和Node-2都满了 │ ▼ 5. ClusterAutoscaler: 我加一台Node 新Node加入集群 │ ▼ 6. 新Pod调度到新Node上 │ ▼ 7. VPA长期观察: 这些Pod的CPU request 设太低了实际都是超额使用调大 修改 300m → 500m# VPA 配置示例apiVersion:autoscaling.k8s.io/v1kind:VerticalPodAutoscalermetadata:name:api-server-vpaspec:targetRef:apiVersion:apps/v1kind:Deploymentname:api-serverupdatePolicy:updateMode:Auto# Auto: 自动调整Off: 只建议不执行resourcePolicy:containerPolicies:-containerName:*minAllowed:# 最低资源保证cpu:100mmemory:128MimaxAllowed:# 最高资源限制控成本cpu:2memory:4GicontrolledResources:[cpu,memory]要点HPA和VPA不要同时用Auto模式管理同一个Deployment——它们会打架。HPA根据CPU利用率扩缩Pod数量VPA改Pod的CPU request——两者互相影响对方计算基准可能导致振荡。推荐做法是HPA用Auto模式做水平伸缩VPA用Off模式只给建议或者只设minAllowed/maxAllowed当资源护栏。6.2 HPA ClusterAutoscaler 完美组合# 典型配置场景——云上自动伸缩集群# AWS EKS 示例eksctl create cluster\--nameauto-scaling-cluster\--nodegroup-nameworkers\--nodes2\# 初始2个节点--nodes-min2\# 最少2个--nodes-max20\# 最多20个--node-typet3.medium# 然后部署HPA管理应用Podkubectl autoscale deployment api-server\--cpu-percent60\--min2--max50# 完整验证链路# 1. 压测 → HPA扩容Pod → 新Pod调度不下 → ClusterAutoscaler加Node# 2. 停止压测 → HPA缩容Pod → Node空闲 → ClusterAutoscaler回收Nodekubectl get hpa-w# 看HPA扩缩kubectl get nodes-w# 看Node增减kubectl get pods-w# 看Pod生灭七、HPA常用命令和调试# 创建HPA一行命令kubectl autoscale deployment myapp --cpu-percent50--min2--max10# 查看HPA状态kubectl get hpa kubectl get hpa myapp-hpa-w# 实时观察# 查看HPA详细信息和历史kubectl describe hpa myapp-hpa# 重点看# Metrics: (当前指标值)# Conditions: AbleToScale/ScalingActive/ScalingLimited# Events: (扩缩容历史)# 查看HPA YAML看完整配置kubectl get hpa myapp-hpa-oyaml# 修改HPAkubectl edit hpa myapp-hpa# 或者kubectl patch hpa myapp-hpa--patch\{spec:{maxReplicas:20}}# 删除HPA不会删除Deploymentkubectl delete hpa myapp-hpa# 调试——为什么HPA不扩容kubectl describe hpa myapp-hpa# 看 Conditions# ScalingLimited: True, Reason: TooFewReplicas → minReplicas设置问题# ScalingLimited: True, Reason: TooManyReplicas → 已经到maxReplicas了# 检查Metrics Server是否正常kubectl get apiservice v1beta1.metrics.k8s.io kubectltoppods kubectltopnodes# 模拟HPA的计算逻辑——手动验证# 当前CPU: 80%, 目标: 50%, 当前Pod: 3# 预期ceil(3 × 80/50) 5# HPA事件——看它都在干什么kubectl get events --field-selectorinvolvedObject.kindHorizontalPodAutoscaler# 7m SuccessfulRescale New size: 4; reason: cpu resource utilization (percentage of request) above target# 5m SuccessfulRescale New size: 8; reason: cpu resource utilization (percentage of request) above target# 20m SuccessfulRescale New size: 2; reason: All metrics below target本篇小结HPA让K8s从手动挡升级为自动挡把运维从盯盘→手动扩缩的体力活中解放出来工作循环每15秒采集指标→计算目标副本数→修改Deployment replicas——全程自动化核心公式desiredReplicas ceil(current × currentUtil / targetUtil)简单但有保护机制防止抖动Metrics Server前置条件kubectl top pods能跑HPA才能工作——这是HPA的眼睛behavior调优扩容激进立刻翻倍、缩容保守观察5分钟再动——宁可多花点CPU也别让服务抖动自定义指标CPU不够精确时上PrometheusAdapter按QPS/延迟/队列长度扩容更精准三件套配合HPA水平扩Pod VPA垂直调资源 ClusterAutoscaler加机器 完整弹性方案下一篇咱们聊K8s调度器——Pod的房产中介。当你创建了一个PodScheduler是怎么从几百个Node里选一个最合适的打分算法、亲和性、污点容忍、拓扑分布约束——这些才是调度背后的黑科技。上一篇【第24篇】Job和CronJob——一次性任务和定时任务下一篇【第26篇】Scheduler——Pod的婚介所是怎么工作的