HPA与Helm实战：Kubernetes自动扩缩容与模板化部署-北京尧图网络

如果你负责维护一个 Kubernetes 集群或者正打算把业务往容器平台上迁移那么 HPA 和 Helm 这两样东西早晚会一起出现在你的工作清单里。HPA 干的事情比较纯粹让应用的副本数跟着流量自动变化流量大了自动扩容闲下来自动缩容Helm 干的事情是另一层把一堆散落的 YAML 从“手写的点状文件”变成“可以整体安装、升级、回滚的部署包”。一个管运行动态一个管交付形态两者其实天然就是搭档。我在实际项目里经常看到有人把这两个话题分开讨论但多数时候它们是同一个需求的两面。比如某个业务要上线部署文档是十几个 YAML流量波动又大夜里 CPU 一打满就得有人爬起来手动扩副本。两件事其实是一件事既要自动化部署也要自动化弹性。这篇文章就从我实际使用 HPA 和 Helm 的经验出发把它们的原理、配置、常见坑完整过一遍适合正在接触这两个组件、或者已经在用但总碰到奇怪问题的同学。1. 为什么总把 HPA 和 Helm 放在一起聊1.1 HPA 解决的是“运行时的弹性”HPA 的全称是 Horizontal Pod Autoscaler水平 Pod 自动扩缩容。这里的“水平”指的是通过增加或减少 Pod 副本数来改变整体处理能力而不是给单个 Pod 加 CPU 内存。它做的事情可以理解成一个带反馈的循环控制器每隔一段时间观察 Pod 的指标比如 CPU 利用率、内存占用、QPS然后和目标值做比较根据差值决定把副本数调大还是调小。这套机制的价值在于你不用提前预估峰值流量。以前做容量管理大家习惯按双十一或者大促时的流量去预留资源结果平时大量浪费。有了 HPA业务可以按平时的低水位配置副本流量起来后自动补副本峰值过去再自动释放。对成本敏感的场景来说这一个功能就能省下一笔不小的资源账单。但 HPA 不是万能的。它只管“Pod 够不够”不管“节点够不够”。如果集群里的空闲节点不足以容纳扩容出来的 PodHPA 完成的扩容会一直处于 Pending 状态这时候需要配合集群层面的自动扩容工具比如节点组扩容才能形成闭环。这两个概念经常被混淆后面排错部分我会专门说。1.2 Helm 解决的是“部署时的编排”Helm 是 Kubernetes 的包管理工具跟操作系统的包管理器思路类似。一个应用涉及的所有资源——Deployment、Service、ConfigMap、Secret、HPA、Ingress——都可以打成一个 Chart这个 Chart 可以整体安装、升级、回滚、卸载。为什么要用它我举一个很常见的场景一个服务要部署到开发、测试、生产三套环境三个环境的副本数、资源配置、域名都不一样。如果你手写 YAML就得维护三份几乎相同但又有细微差别的文件改一个参数要同步改三遍漏一次就出事故。用 Helm 的话一份模板加一份 values 文件values 里按环境区分参数渲染出来的内容交给模板引擎处理就能一套 Chart 吃遍所有环境。更关键的是Helm 升级不是简单地把 YAML 重新 apply 一遍。它内部会计算新旧版本的差异生成一个升级策略默认情况下只更新变化的部分。配合 helm rollback可以把整个应用恢复到任意历史版本。这点在生产环境做发布变更时非常实用后面我会讲具体用法。1.3 两者结合以后的工作流把 HPA 和 Helm 组合起来会得到一个比较完整的闭环Helm 负责把应用、配置、HPA 规则一起打包发布HPA 负责在运行阶段根据真实负载调整副本数需要调整弹性策略时直接改 Helm 的 values 文件再升级而不是手动执行 kubectl edit 改 HPA 配置。这么做的好处是所有弹性相关的参数——最小副本数、最大副本数、目标指标类型和阈值——都集中在一个可版本化的 Chart 里。团队协作时别人看一眼 values.yaml 就能知道这个服务的伸缩策略是什么不需要翻监控系统猜。我自己的习惯是把 HPA 的配置直接模板化用 values 里的一个 autoscaling 块控制这样每个服务都能用同一套 Chart 快速拉起一套带自动伸缩能力的部署。2. HPA 扩缩容原理拆解搞清楚再动手2.1 HPA 到底在控制什么很多新手刚开始用 HPA 时会搞错一个概念HPA 不能直接控制 Pod它控制的是一类实现了 scale 子资源的对象比如 Deployment、StatefulSet、ReplicaSet。HPA 在创建时通过 scaleTargetRef 指定要控制的对象控制器会查询该对象当前的副本数然后根据指标计算出期望副本数再调用它对应的 scale 接口去更新。这意味着如果你的应用是用一个裸 Pod 跑的那 HPA 是管不了的因为裸 Pod 没有 scale 子资源。正常情况下应用都应该通过 Deployment 或 StatefulSet 管理HPA 挂在这些工作负载上才有意义。另一个容易踩的点是HPA 启动后它会接管目标工作负载的 replicas 字段。如果你在 HPA 运行期间手动执行 kubectl scale 去改副本数大概率会被 HPA 在下一个调协周期内改回来。手动扩容只能应急一两分钟真正要改预期容量应该去改 HPA 的 minReplicas 或 maxReplicas 参数。2.2 副本数背后的计算逻辑HPA 的扩缩容算法并不复杂核心是一句话期望副本数等于当前副本数乘以当前指标值与目标指标值的比值向上取整。期望副本数 ceil[当前副本数 × (当前指标值 / 目标指标值)]我举个例子。某个 Deployment 配置了 3 个副本每个 Pod 的 CPU request 是 1 核1000mHPA 目标设置为 CPU 平均利用率 50%也就是每个 Pod 的目标用量是 500m。假设当前采集到的所有副本平均 CPU 用量是 600m那么计算过程就是期望副本数 ceil(3 × (600 / 500)) ceil(3 × 1.2) 4也就是需要从 3 个副本扩到 4 个。注意这里“当前指标值”用的是所有就绪 Pod 的平均值。如果采集到了多个指标HPA 会分别用每个指标算出一个期望副本数然后取最大值作为最终结果因为要保证最紧张的指标得到满足。这里有个细节容易忽略CPU 利用率类型的指标HPA 计算时依赖 Pod 的 CPU request。如果你在 Deployment 里没写 resources.requests.cpuHPA 就不知道 100% 对应多少核得到的是 Unknown也就无法触发扩缩容。这是新手报错里最常见的一种后面排查部分还会再强调。2.3 指标来源metrics-server 和自定义指标HPA 默认使用的指标类型主要是 Resource 类型也就是 CPU 和内存。这类指标来自集群的 metrics-server 组件它从每个节点的 kubelet 周期采集 Pod 的用量数据再通过 Metrics API 暴露出来。所以要让基础的 CPU/内存 HPA 正常工作你必须在集群里部署好 metrics-server否则 HPA 拿不到任何数据。如果你的业务需要按 QPS、请求延迟这类业务指标伸缩那就得引入自定义指标管道了。常见方案是 Prometheus 抓取业务指标通过 Prometheus Adapter 暴露成 Custom Metrics APIHPA 再从这套 API 里读取数据。这类配置比 CPU/内存复杂不少涉及指标名映射、命名空间匹配等一堆细节一般只有对弹性要求比较精细的业务才会用到。我个人的建议是大多数 Web 服务用 CPU 利用率做主要扩缩依据就够用了因为 QPS 和 CPU 之间通常强相关。先保证基础版本稳定运行再考虑把更贴近业务的指标接进去避免一上来就被复杂的指标链路纠缠住。3. Helm 的工作机制用模板解决部署一致性3.1 一个 Chart 里到底装了什么Helm 的包结构叫 Chart。一个标准的 Chart 目录长这样demo-chart/ ├── Chart.yaml ├── values.yaml └── templates/ ├── deployment.yaml ├── service.yaml ├── hpa.yaml ├── _helpers.tpl └── NOTES.txtChart.yaml 是元信息文件记录名称、版本、依赖信息values.yaml 是参数入口所有可能变动的配置都集中在这里templates 目录放各种资源的模板文件里面是带模板函数和占位符的 YAML_helpers.tpl 存放命名辅助函数用于生成统一规范的资源名和标签。部署的时候Helm 把 values.yaml 里的键值对注入模板渲染成 Kubernetes 认得的标准 YAML然后一次提交给 API Server。整个过程不会修改你本来的模板文件所以可以反复渲染、反复检查直到确定无误再真正部署。3.2 参数注入规则和优先级Helm 的模板引擎基于 Go 模板它的核心机制是{{ 和 }} 里面的内容是表达式外面的内容是普通字符串。最常用的几个语法点如下变量注入{{ .Values.replicaCount }} 会把 values.yaml 里的 replicaCount 值渲染进模板条件判断{{- if .Values.autoscaling.enabled }} 配合 {{- end }}控制某段模板是否渲染循环遍历{{- range .Values.env }}对列表类型的配置逐项生成内容。values 的覆盖优先级需要搞清楚默认 values.yaml 的优先级最低通过 helm upgrade -f 指定的文件优先级更高用 --set 直接传的键值对优先级最高。实际发布的时候我习惯把环境差异放到单独的 values-dev.yaml、values-prod.yaml 里用 -f 按环境加载不让 --set 承担太多复杂参数。还有个容易被忽视的细节是模板函数。比如 quote 用于给值加引号default 用于给缺省值兜底toYaml 用于把复杂结构转换成多行 YAMLinclude 和 nindent 用于复用命名模板。这几个函数基本能覆盖日常 90% 的编写需求。3.3 为什么用模板“生成”HPA 而不是直接写死HPA 的 YAML 本身不复杂很多人一开始直接在 templates 下写一个固定的 HPA 文件里面写死 minReplicas 和 maxReplicas。这种做法在服务数量少时没问题但只要你有三五个服务每个服务的弹性策略又不太一样问题就来了要么复制粘贴改参数要么忘记更新。用模板后HPA 的所有参数都从 values.yaml 读取改弹性策略不需要动结构只需要改配置这个差别在维护多个服务时感受特别明显。更进一步你可以用条件判断控制 HPA 是否生成。比如开发环境不需要自动伸缩就在 values 里设置 autoscaling.enabled: false渲染出来的 YAML 里就不会有 HPA 对象生产环境设为 trueHPA 自动出现。同一份模板面向多种场景这就是模板化的价值所在。4. 实操用 Helm 模板化 HPA跑通一次完整发布4.1 准备一个可以产生负载的测试应用为了看得见扩缩容效果需要一个能稳定消耗 CPU 的测试应用。这里我直接用一段简单的 Python 程序请求某个接口后做一段循环计算把 CPU 占满模拟高负载场景。实际项目里你在模板里换成自己的业务镜像即可。Chart 里 deployment.yaml 的关键片段如下apiVersion: apps/v1 kind: Deployment metadata: name: {{ include demo.fullname . }} spec: replicas: {{ .Values.replicaCount }} selector: matchLabels: {{- include demo.selectorLabels . | nindent 6 }} template: metadata: labels: {{- include demo.selectorLabels . | nindent 8 }} spec: containers: - name: {{ .Chart.Name }} image: {{ .Values.image.repository }}:{{ .Values.image.tag }} ports: - containerPort: 8080 resources: requests: cpu: {{ .Values.resources.requests.cpu }} memory: {{ .Values.resources.requests.memory }}resources.requests.cpu 一定要写并且要和你 HPA 里配置的目标值对应起来。比如 request 设为 500m目标利用率设为 60%就表示每个 Pod 的 CPU 目标用量是 300m。4.2 把 HPA 模板写进 Charthpa.yaml 模板可以这样设计{{- if .Values.autoscaling.enabled }} apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: {{ include demo.fullname . }} labels: {{- include demo.labels . | nindent 4 }} spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: {{ include demo.fullname . }} minReplicas: {{ .Values.autoscaling.minReplicas }} maxReplicas: {{ .Values.autoscaling.maxReplicas }} metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: {{ .Values.autoscaling.targetCPUUtilizationPercentage }} - type: Resource resource: name: memory target: type: Utilization averageUtilization: {{ .Values.autoscaling.targetMemoryUtilizationPercentage }} {{- end }}对应的 values.yaml 配置块replicaCount: 2 resources: requests: cpu: 500m memory: 512Mi autoscaling: enabled: true minReplicas: 2 maxReplicas: 8 targetCPUUtilizationPercentage: 60 targetMemoryUtilizationPercentage: 80开发环境如果不需要 HPA把 autoscaling.enabled 改成 false 即可模板里整段 HPA 不会渲染。模板里我同时配了 CPU 和内存两个指标HPA 会分别计算期望副本数并取最大值这样内存飙升导致的扩容也会被覆盖。这里有个小的实践经验不要把 targetCPUUtilizationPercentage 设得太低比如设成 30%其后果是扩容非常敏感稍有波动就扩Pod 数量频繁变动反而影响稳定性。一般 50% 到 70% 是比较合理的区间。4.3 渲染检查、安装和升级写完模板先不要急着 install用 helm template 做一次本地渲染看生成的 YAML 是不是脑子里预期的样子helm template demo ./demo-chart -n test加上 --debug 还能看到渲染的详细过程和查找路径排查模板函数错误时很管用。确认没问题后安装helm install demo ./demo-chart -n test --create-namespace查看 release 状态helm list -n test kubectl get hpa -n test改动 values 后升级helm upgrade demo ./demo-chart -n test -f values-prod.yaml我已经数不清有多少次因为忘记加 -n 导致折腾半天。这个参数 Helm 不会自动延续每次 install、upgrade、uninstall 都要显式带上最稳妥的办法是提前给 kubectl 和 helm 都设置好命名空间上下文然后再执行命令。4.4 用压测看一次完整的扩容安装完成后用压测工具给测试应用持续施压让 CPU 用量越过 60% 的目标线。HPA 默认每个调协周期都会重新计算所以指标超标的几十秒后就能看到副本数开始往上走kubectl get hpa -n test -w正常情况下会看到 TARGETS 列从 20% 左右一路上涨到 80% 甚至 120%然后副本数从 2 变成 3、4、5。等到压测停止CPU 降下来HPA 会等待一段缩容冷却时间默认 5 分钟再把副本逐渐降回 minReplicas。这个等待过程是正常的不要以为缩容坏了。我这轮测试里还观察到很典型的现象扩容触发很快因为默认的扩容冷却只有 15 秒缩容非常慢因为默认缩容稳定窗口要 5 分钟。这其实是设计上故意为之的——扩容要快避免服务过载缩容要稳避免指标抖动导致副本被反复砍掉。5. 常见问题与排查技巧实录5.1 HPA 显示 Unknown 或者拿不到指标HPA 状态里 TARGETS 列显示 Unknown最常见的原因是 metrics-server 没部署或工作不正常。先用这个命令确认kubectl get --raw /apis/metrics.k8s.io/v1beta1如果返回错误或者空结果说明 metrics-server 还没有正确暴露资源指标。另一个常见原因是你给 Deployment 里的容器没写 resources.requestsHPA 没有基准就没法计算利用率。这两个问题基本覆盖了“看到 Unknown”的绝大多数情况。还有一种情况是 HPA 创建时写错了 scaleTargetRef 里的名字指向了一个不存在的 Deployment。控制器会一直找不到目标状态里报错信息也会指向这个原因核对一下名字和命名空间就好。5.2 指标正常但是副本数不动TARGETS 列能显示百分比说明指标链路通了但副本数不变化这时候先算一下当前值和目标值的关系。假设 target 是 60%当前只有 40%那就还没到扩容条件这不是“坏了”而是“时机未到”。HPA 本身就是按阈值触发不是所有指标变化都会引发扩缩。另一个经常被忽略的点是 maxReplicas 太小。比如你已经配了 maxReplicas: 3当前副本数已经是 3指标再高也不会继续扩。日志里通常会告警说已达到最大副本数直接调大 maxReplicas 看看。如果你在 HPA 启动后手动 scale 过 Deployment也可能出现一段时间内副本数像抽风一样来回跳那是 HPA 在重新接管控制权。不要慌等几分钟让它自动稳定并且避免再手动修改副本数。5.3 缩容总是很慢或者不缩如果压测停了很久CPU 已经降到很低副本数还是定格在高位原因大概率是缩容冷却窗口还没到或者集群节点资源使用率本身较高但 HPA 指标正常。前者是设计行为后者要确认是不是节点层面的事情那不是 HPA 管的范围。如果你希望缩容响应更快可以在 HPA 的 behavior 字段里配置缩容策略。下面这段 HPA 参数我实际用在一些夜间流量骤减的服务上kubectl patch hpa demo -n test --type merge -p { spec: { behavior: { scaleDown: { stabilizationWindowSeconds: 60, selectPolicy: Max } } } }stabilizationWindowSeconds 从默认的 300 秒缩短到 60 秒缩容观察窗口变短流量下降后能更快回收副本。selectPolicy 可以用 Max 或者 Min具体的组合调节逻辑可以在 Kubernetes 官网参数说明里查到但核心思路是先小步调、再观察避免一次缩太多。5.4 Helm 升级后资源没有按预期变更Helm 升级常见的疑问是我明明改了 values 里的镜像 tag升级之后 Pod 没变。这种情况大概率是模板里没有把镜像 tag 变化传递到 Deployment 的 pod 模板。如果 Deployment 的 pod template 里没有对应字段或者模板渲染结果没有变化Helm 自然不会触发滚动更新。一个稳妥的做法是在 pod template 的 annotations 区域加入一个包含版本或者更新时间的字段比如annotations: helm.sh/hash: {{ toYaml .Values | sha256sum | quote }}这样每次 values 有变化hash 就会变Pod 模板随之变化Helm 升级就会触发滚动更新。不过用这种方式时要小心因为配置里任何微小的改动都会导致全部 Pod 重建你需要权衡它带来的便利和代价。如果你想把变更细节前置检查可以先执行 helm diff upgrade这个插件能列出本次升级要创建、删除、修改哪些资源发布前看一眼差异能省掉不少事故。5.5 回滚之后 HPA 出现短暂异常Helm rollback 会把 release 恢复到某个历史版本但 HPA 对象本身在集群里的状态可能不会立刻和模板一致。出现这种情况的原因是HPA 的实时状态比如当前副本数、最后一次扩容时间是集群运行时数据回滚只会把 spec 部分改回旧版本。我个人建议回滚后看一下 HPA 对应的 Deployment 副本数必要时把它调整到目标状态。6. HPA 和 Helm 配合使用的一些经验6.1 发布和伸缩分清楚用 Helm 做发布用 HPA 做弹性两者的职责要切干净。发布频率低的改动比如改环境变量、换镜像版本走 Helm 升级发布频率高、随负载波动的变更比如加副本数不要走 Helm也不要手动 scale应该调 HPA 的参数。把这两个职责混淆很容易出现发布流程和伸缩策略相互打架的现象。举一个真实感受的例子某服务流量涨了你想把副本从 3 扩到 6如果直接用 helm upgrade 改了 replicaCountHPA 可能马上把副本数压回来。正确做法是改 HPA 的 maxReplicas或者把目标利用率调低让 HPA 自己判断要不要扩。想清楚这一步你在团队里会少背很多锅。6.2 参数速查表日常配置 HPA 和 Helm 时有几个关键参数我整理成一张速查表方便直接用对象参数作用建议值HPAminReplicas最小副本数按业务下限一般不少于 2HPAmaxReplicas最大副本数按峰值预估留 20% 余量HPAaverageUtilization目标利用率CPU 50% 到 70%内存 70% 到 80%HPAstabilizationWindowSeconds缩容稳定窗口默认 300 秒敏感业务可降到 60 秒Deploymentresources.requestsHPA 计算基准必须设置否则 HPA 无参考值Helm valuesautoscaling.enabled是否生成 HPA环境差异时通过 values 控制Helm--set临时覆盖参数不要用于复杂结构用 -f 代替6.3 模板里使用 HPA 的注意事项Helm 模板写多了以后我总结了几条容易出问题的点HPA 的 apiVersion 记得用 autoscaling/v2旧版 autoscaling/v1 只支持 CPU 且写法繁琐templates 目录里生成的资源名要和其他模板保持一致最好都通过 _helpers.tpl 里的函数生成避免手写拼错values.yaml 的结构保持扁平化autoscaling 块就是一个好的例子嵌套太深会让维护的人非常痛苦模板函数里注意缩进include 后要配合 nindent 修正偏移否则渲染出来的 YAML 会直接报格式错误。调试的时候用 helm install --dry-run --debug 配合 helm template 检查渲染结果基本能定位大部分模板问题。6.4 一个更完整的自动扩缩容闭环最后说下 HPA 常见的搭档Cluster Autoscaler。HPA 解决 Pod 层的容量调节而 Cluster Autoscaler 解决节点层的容量扩容。流量突然增长HPA 把 Pod 从 2 个扩到 20 个但集群节点放不下这么多 Pod扩容出来的 Pod 会卡在 Pending 状态这时候 Cluster Autoscaler 看到有 Pending Pod会自动申请新的节点加入集群。两者配合形成完整闭环后整个集群才算真正具备“按需伸缩”的能力。我在实践中最满意的配置组合是Helm 模板负责渲染 HPA 和 DeploymentHPA 用 CPU 内存双指标做扩缩依据集群层搭配 Cluster Autoscaler 自动扩节点。业务流量上来后Pod 和节点都有条不紊地增加流量下去后资源逐步释放。整个过程不需要人工介入也不需要值班人员在半夜盯监控。如果你也在做容器化改造这套东西值得认真落地。最后分享一个小技巧给模板加监控。很多人记不清本次 helm upgrade 改了哪些内容我习惯在发布前两天先在测试环境跑一遍 helm diff upgrade --detailed-exitcode如果返回码是 2说明有变化直接把 diff 结果贴到发布记录里代码评审和故障追溯都方便很多。类似的每次升级后查看 helm history也能快速确认发布是不是真的成功。这些习惯养成以后你会发现 Kubernetes 下的日常发布和伸缩管理比想象中更可控。

HPA与Helm实战：Kubernetes自动扩缩容与模板化部署

相关推荐

单周期RISC-V CPU设计：Vivado实战与FPGA落地指南

用GDAL实现遥感影像裁剪：从范围裁剪到批量处理实战

西门子PLC增量式PID程序：抗积分饱和、无扰切换、1200/1500通用

更多资讯

轻量级实时事件分析工具rea：从事件采集到告警可视化的实践

用先知AI精炼男装产品语言：从概念到爆款的实战方法

车道线检测从训练到TensorRT部署实战：轻量化模型与INT8量化全流程

2026年起号新逻辑：AI工具一分钟生成原创图文与多平台分发实操

从零手写字符设备驱动：安卓底层驱动的灵魂与实战

CoppeliaSim+Python小车视觉追踪：从仿真到真机移植的完整实现指南

今日更新

微信云开发旅游小程序实战：LBS打卡+UGC社交全栈方案

金融AI代理平台核心拆解：从多代理协作到财报分析实战

基于大数据的智慧旅游推荐与可视化平台架构实践

本周精选

金融AI落地指南：从调研报告到技术选型与工程实践

大模型上下文成本与注意力优化技术深度解析——为何O(n²)平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测

基于GMM的语音识别系统原理与MATLAB实现详解

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？