如何为 Budibase Helm Chart 配置水平 Pod 自动扩缩容（HPA）

如何为 Budibase Helm Chart 配置水平 Pod 自动扩缩容（HPA）

【免费下载链接】budibaseAI agents, automations and apps that run your operations. Model agnostic.项目地址: https://gitcode.com/GitHub_Trending/bu/budibase

当你把 Budibase 通过 Helm 部署到 Kubernetes 集群后，默认情况下各服务的 Pod 副本数是固定的。如果希望 apps、worker、proxy 或 automation worker 服务的副本数随 CPU 负载自动伸缩，需要在 chart 的values里为对应服务打开autoscaling配置。本文基于 Chart README、values.yaml 和四个 HPA 模板，说明如何完成这项配置并验证结果。

前置条件

Chart README 的 Prerequisites 一节列出了使用水平 Pod 自动扩缩的硬性前提：

• helmv3 或以上；
• Kubernetes 1.4+；
• 集群中已部署metrics-server（原文明确标注：这是"use horizontal pod autoscaling"的前提）。

另外，README 与 values.yaml 在每个服务的targetCPUUtilizationPercentage说明中都强调：autoscaling 要生效，除了metrics-server已配置，还必须为目标 Pod 设置了resources（即services.<服务>.resources）。这两条是判断"配置了 HPA 却不扩缩"时文档给出的检查方向。

哪些服务有独立的 HPA

从 chart2.x升级到3.0.0时，原来的单一开关hpa.enabled: true被拆分为按服务独立的 HPA（README 的 Upgrading 一节），配置键位于services.{apps,worker,proxy}.autoscaling。如果旧版本配置里还残留hpa.enabled，在新 chart 中不会再产生任何 HPA。

当前 chart 中共有四个 HPA 模板，各受一个独立的autoscaling.enabled开关控制（默认均为false）：

四个模板结构一致，可分别查看 app-service-hpa.yaml、worker-service-hpa.yaml、proxy-service-hpa.yaml 和 automation-worker-service-hpa.yaml。注意模板中的条件渲染：autoscaling.enabled为false时整个 HPA 资源不会被渲染，所以默认安装下集群里没有任何 HPA。

各autoscaling块的默认值（来自 README 配置表与 values.yaml，四个服务一致）：

模板中还支持targetMemoryUtilizationPercentage：设置后会额外渲染一条 memory 类型的 Resource 指标，与 CPU 指标并存。这个键没有出现在 README 的配置表中，属于模板提供的可选进阶项，默认不设置。

在 values 中配置扩缩容

把要开启 HPA 的服务写入一个 values 文件，例如values-hpa.yaml。以 apps 服务为例：

services: apps: autoscaling: enabled: true # 渲染 budibase-apps 这个 HPA minReplicas: 2 # 示例值，请按基线副本数调整（chart 默认为 1） maxReplicas: 10 targetCPUUtilizationPercentage: 80 # chart 要求为目标 pod 设置 resources，autoscaling 才能工作。 # 下面的值仅为格式示例，请替换为你的工作负载实际需要的 CPU requests resources: requests: cpu: 500m

说明两点：

• resources是必填配套项。chart 文档没有给出资源示例值，只链接到 Kubernetes 资源管理文档，具体数值由你根据负载自行设定；
• minReplicas建议不低于该服务的基线副本数。这里存在一个文档间差异：当前 values.yaml 中四个服务的replicaCount默认是2，而 README 配置表标注默认值为1，请以你实际拉取的 chart 版本中的values.yaml为准。

要对 worker、proxy 或 automation worker 做同样配置，只需把同样的autoscaling块写到对应的services.worker、services.proxy、services.automationWorkers下。如果你的部署关闭了 automation worker 服务（services.automationWorkers.enabled: false，关闭后 automations 由 apps 服务处理，见 README），那么automation-worker的 HPA 也就没有实际意义。

应用配置

README 给出的安装方式有两条主路径，HPA 配置通过-f values.yaml的方式附加（README 的 "Example minimal configuration" 一节展示了同样的用法）：

从 chart 仓库安装（首次部署时把values-hpa.yaml一起传入）：

$ helm repo add budibase https://budibase.github.io/budibase/ $ helm repo update $ helm install --create-namespace --namespace budibase budibase budibase/budibase -f values-hpa.yaml

或者在本仓库的charts/budibase目录下用本地 chart 安装：

$ helm install --create-namespace --namespace budibase budibase . -f values-hpa.yaml

对于已存在的 release（名称同为budibase），用helm upgrade传入同样的 values 文件更新配置即可，例如：

$ helm upgrade --namespace budibase budibase budibase/budibase -f values-hpa.yaml

验证 HPA 是否生效

安装或升级完成后，用 kubectl 查看命名空间下的 HPA 对象（命名空间budibase来自上面安装命令中的--namespace）：

$ kubectl get hpa -n budibase

判断依据：

• 只有设置了autoscaling.enabled: true的服务才会出现，名称形如budibase-apps、budibase-worker、budibase-proxy、budibase-automation-worker（前缀为<release名>-<服务>，见各 HPA 模板的metadata.name）；
• MIN/MAX 列应与你在 values 中写的minReplicas、maxReplicas一致；
• 由于模板会按集群能力自动选择apiVersion（支持autoscaling/v2的集群渲染autoscaling/v2，否则回退autoscaling/v2beta2），输出中看到的两种版本都属于正常渲染结果，不是配置错误。

如果 HPA 对象存在但副本数从不变化，按文档给出的两条前提检查：集群的metrics-server是否可用，以及对应服务的resources是否已设置——README 对每个服务的说明都是同一句话："for autoscaling to work, you will need to have metrics-server configured, and resources set for the ... pods"。

限制与边界

• 默认安装不会渲染任何 HPA，四个开关默认都是false；本文的验证步骤也依赖这一点，列表里没有的对象说明对应服务未开启。
• 旧版本（2.x）的hpa.enabled: true在3.0.0起失效，迁移时必须改为services.{apps,worker,proxy}.autoscaling。
• 模板只渲染 CPU/memory 两种 Resource 指标，chart 未提供扩缩速度、稳定窗口等策略参数，也没有文档化的其他调优项。
• 本文覆盖的是 chart 自身的 HPA 配置；CouchDB 副本数（couchdb.clusterSize）等数据层伸缩不在 HPA 管理范围内。

【免费下载链接】budibaseAI agents, automations and apps that run your operations. Model agnostic.项目地址: https://gitcode.com/GitHub_Trending/bu/budibase