Budibase Helm Chart 从 2.x 升级到 3.0.0 时如何处理 Ingress、CouchDB 与 HPA 配置变更

Budibase Helm Chart 从 2.x 升级到 3.0.0 时如何处理 Ingress、CouchDB 与 HPA 配置变更

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

如果你已经用 Budibase 官方 Helm chart（仓库中位于charts/budibase）的 2.x 版本部署过 Budibase，现在要升到3.0.0，就会撞上这一版引入的一组破坏性变更：不再捆绑ingress-nginx、CouchDB 子 chart 从3.3.4跳到4.3.0、AWS ALB Ingress 配置整体搬家、hpa.enabled单一开关拆成三个独立 HPA。升级的核心工作不是跑新命令，而是把 2.x 的 values 逐条翻译到新的配置路径上。本文按 charts/budibase/README.md 的 "Upgrading: 2.x to 3.0.0" 一节和各配置项在 values.yaml 中的实际定义，给出逐项迁移方法、升级命令形态和升级后的验证方式。

四个破坏性变更的对应关系

README 明确列出 3.0.0 的变更，先建立旧配置到新配置的映射：

以下按 Ingress、CouchDB、HPA 三块展开。

Ingress：先确认控制器从哪来

3.0.0 起 chart 不再部署ingress-nginx。如果你的 2.x 集群正是靠它提供 Ingress 控制器，升级前必须先单独部署一个 Ingress 控制器（README 指向 ingress-nginx 项目文档），否则升级完成后 Ingress 资源虽然存在，却没有控制器处理流量。这是 README 列在四条变更里的第一条。

标准 Ingress 路径。如果不用 ALB，保留ingress块即可，新 chart 的键是ingress.enabled（默认true）、ingress.className、ingress.hosts。hosts 默认指向 proxy 服务，README 中给出的最小示例形如：

ingress: enabled: true className: "nginx" hosts: - host: budibase.local # 替换为你的 DNS 域名 paths: - backend: service: name: proxy-service port: number: 10000 path: / pathType: Prefix

EKS / AWS ALB 路径。2.x 里靠ingress.enabled: false+ingress.aws: true启用的 ALB Ingress，3.0.0 起改为：

awsAlbIngress: enabled: true

原来散在别处的 ALB 配置全部收敛到awsAlbIngress下，values.yaml 中可见的键包括certificateArn（HTTPS 时填 ACM 证书 ARN）、accessLogs（写入 S3 的访问日志，enabled/bucket/prefix，bucket 必须已存在于同 region）。注意awsAlbIngress.enabled的描述写明该项 Requires the AWS ALB Ingress Controller，即集群里同样要先装好 AWS ALB Ingress Controller。

CouchDB：子 chart 跨大版本，重点检查 uuid 与镜像

README 说明 3.0.0 把 CouchDB 子 chart 从3.3.4升到4.3.0，CouchDB 版本随之从 3.1.1 到 3.2.1，并且 Budibase 改用自建 CouchDB 镜像。当前仓库的 Chart.yaml 与 Chart.lock 已将依赖锁定在couchdb 4.5.6，而 README 与 values 注释引用的是4.3.0时期的文档——两者并存属于文档版本演进，迁移 3.0.0 时按 README 的4.3.0理解即可。

迁移时需要关注三点（来源：couchdb 子 chart README 与主 chart values.yaml）：

1. uuid 必填。子 chart 自 3.0.0 起要求显式设置couchdbConfig.couchdb.uuid。当前主 chart 的 values.yaml 已在couchdb.couchdbConfig.couchdb.uuid给了默认值budibase-couchdb；如果旧 release 的 values 没设过这项，升级时要确保它出现在 values 里。子 chart README 给出了升级示例，用--set couchdbConfig.couchdb.uuid=<UUID>注入自生成的 UUID：

   $ helm upgrade <release-name> \ --version=3.6.4 \ --reuse-values \ --set couchdbConfig.couchdb.uuid=<UUID> \ couchdb/couchdb

   注意该示例是针对直接升级 couchdb 子 chart 的写法；对 Budibase 主 chart 升级时，uuid 落在couchdb覆盖键下（即couchdb.couchdbConfig.couchdb.uuid），且<UUID>需替换为你实际生成的值。

2. 跨 4.0.0 的 secret 变更。从3.3.4到4.3.0跨越了子 chart 4.0.0，其破坏性变更是 secret 中的adminHash不再经由password.ini，只存储adminHash本身。子 chart README 的提示是：如果你自己管理这个 secret，升级时相应调整。

3. 镜像不要改。主 chart 固定使用自定义镜像budibase/database（values.yaml 中 tag 为2.1.0，pullPolicy: Always），并注释明确：不支持使用其他 CouchDB 镜像，擅自修改无法保证 Budibase 正常工作。其余与 2.x 的衔接项保持不变：services.couchdb.enabled: true、couchdb.persistentVolume（默认启用，10Gi）、SQS 额外端口4984等。

HPA：一个开关拆成三个独立块

2.x 的hpa.enabled: true在 3.0.0 中已移除，改为按服务单独配置，README 指明是services.{apps,worker,proxy}.autoscaling三处。每个块包含相同的四个键，默认值为enabled: false、minReplicas: 1、maxReplicas: 10、targetCPUUtilizationPercentage: 80。例如升级后想让 apps 和 proxy 继续自动扩缩：

services: apps: autoscaling: enabled: true proxy: autoscaling: enabled: true worker: autoscaling: enabled: true # 按需选择，不需要就保持默认 false

values.yaml 的注释给出 HPA 生效的两个前提：集群配置了metrics-server，且对应服务 Pod 设置了resources。README 的前置条件一节也单独列出了metrics-server（"if you want to make use of horizontal pod autoscaling"）。另外当前 values.yaml 中services.automationWorkers也带autoscaling块（默认同样关闭），这是 3.0.0 拆分之后新增的服务，可按需启用。

执行升级

准备条件（README Prerequisites）：helmv3 及以上、Kubernetes 1.4+；要定义 Ingress 资源则集群需有 Ingress 控制器；要用 HPA 需metrics-server；用持久存储需存储控制器。

操作步骤：

1. 基于现有 values 整理出 3.0.0 的新values.yaml，把上文的 Ingress、CouchDB uuid、HPA 各块替换到位；

2. 升级前可用仓库的 pre-commit 校验脚本同款命令对 chart 做本地校验（scripts/helm-pre-commit.sh 中的流程）：

   $ helm lint charts/budibase

3. 按 README 安装命令的相同 release 名与命名空间执行升级。chart 来源二选一：官方 chart 仓库（先helm repo add budibase再helm repo update，仓库地址见 charts/budibase/README.md），或克隆本仓库后在charts/budibase目录直接引用：

   # 从 chart 仓库升级（values.yaml 为你整理后的迁移配置） $ helm upgrade --namespace budibase budibase budibase/budibase -f values.yaml

   如果仓库中同时存在多个 chart 版本，用--version固定到 3.0.0——--version=的固定写法在 couchdb 子 chart README 的升级示例中有展示。

验证升级结果

该 chart 自带 helm test 钩子：test-connection.yaml 定义了一个标注helm.sh/hook: test的 busybox Pod，用wget请求主服务（release 全名 Service 的 10000 端口，对应service.port默认值）。执行：

$ helm test --namespace budibase budibase

钩子 Pod 成功退出即说明 proxy 服务端口在集群内可达。

升级后按迁移项逐一确认：

• Ingress：若流量不通，首先核对集群里确实存在 Ingress 控制器——这是 3.0.0 之后最常见的坑，chart 侧ingress.enabled只负责创建 Ingress 资源；
• HPA：只有metrics-server与 Podresources两项前提都满足时扩缩容才会工作，缺一项 HPA 存在但不生效；
• CouchDB：确认couchdbConfig.couchdb.uuid已生效、Pod 正常拉起；数据卷沿用原persistentVolume配置（默认 10Gi）。

限制与冲突说明

• couchdb.image只能保持budibase/database，values 注释明确不支持其他镜像；
• README 描述 3.0.0 时子 chart 版本为4.3.0，当前仓库实际锁定4.5.6（见 Chart.lock），README 的配置文档链接仍指向couchdb-4.3.0的文档树，查阅子 chart 配置时注意以你实际部署的版本为准；
• ALB 路径依赖 AWS ALB Ingress Controller 已安装，accessLogs要求目标 S3 bucket 预先存在并配置好 ELB 日志投递策略；
• 若旧 release 使用过internalApiKey/jwtSecret/apiEncryptionKey，注意 values 中另提供internalApiKeyFallback、jwtSecretFallback用于轮换期间的兼容，本升级不强制涉及。

完成上述 values 迁移、升级命令执行并通过helm test后，2.x 到 3.0.0 的升级即告完成；后续如需调整各服务副本或探针参数，均在各services.*块内完成。

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