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 的变更先建立旧配置到新配置的映射2.x 的情况3.0.0 的处理依赖 chart 捆绑的ingress-nginx提供 Ingress 控制器chart 不再捆绑需要自行在集群部署 Ingress 控制器EKS 上用ingress.enabled: falseingress.aws: true启用 ALB改为awsAlbIngress.enabled: true全部配置移到awsAlbIngress下hpa.enabled: true一个开关控制 HPA拆成services.apps.autoscaling、services.worker.autoscaling、services.proxy.autoscaling三个独立块CouchDB 子 chart3.3.4CouchDB 3.1.1子 chart 升到4.3.0CouchDB 3.2.1且改用 Budibase 自建镜像以下按 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: PrefixEKS / AWS ALB 路径。2.x 里靠ingress.enabled: falseingress.aws: true启用的 ALB Ingress3.0.0 起改为awsAlbIngress: enabled: true原来散在别处的 ALB 配置全部收敛到awsAlbIngress下values.yaml 中可见的键包括certificateArnHTTPS 时填 ACM 证书 ARN、accessLogs写入 S3 的访问日志enabled/bucket/prefixbucket 必须已存在于同 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.0CouchDB 版本随之从 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.yamluuid 必填。子 chart 自 3.0.0 起要求显式设置couchdbConfig.couchdb.uuid。当前主 chart 的 values.yaml 已在couchdb.couchdbConfig.couchdb.uuid给了默认值budibase-couchdb如果旧 release 的 values 没设过这项升级时要确保它出现在 values 里。子 chart README 给出了升级示例用--set couchdbConfig.couchdb.uuidUUID注入自生成的 UUID$ helm upgrade release-name \ --version3.6.4 \ --reuse-values \ --set couchdbConfig.couchdb.uuidUUID \ couchdb/couchdb注意该示例是针对直接升级 couchdb 子 chart 的写法对 Budibase 主 chart 升级时uuid 落在couchdb覆盖键下即couchdb.couchdbConfig.couchdb.uuid且UUID需替换为你实际生成的值。跨 4.0.0 的 secret 变更。从3.3.4到4.3.0跨越了子 chart 4.0.0其破坏性变更是 secret 中的adminHash不再经由password.ini只存储adminHash本身。子 chart README 的提示是如果你自己管理这个 secret升级时相应调整。镜像不要改。主 chart 固定使用自定义镜像budibase/databasevalues.yaml 中 tag 为2.1.0pullPolicy: 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 # 按需选择不需要就保持默认 falsevalues.yaml 的注释给出 HPA 生效的两个前提集群配置了metrics-server且对应服务 Pod 设置了resources。README 的前置条件一节也单独列出了metrics-serverif you want to make use of horizontal pod autoscaling。另外当前 values.yaml 中services.automationWorkers也带autoscaling块默认同样关闭这是 3.0.0 拆分之后新增的服务可按需启用。执行升级准备条件README Prerequisiteshelmv3 及以上、Kubernetes 1.4要定义 Ingress 资源则集群需有 Ingress 控制器要用 HPA 需metrics-server用持久存储需存储控制器。操作步骤基于现有 values 整理出 3.0.0 的新values.yaml把上文的 Ingress、CouchDB uuid、HPA 各块替换到位升级前可用仓库的 pre-commit 校验脚本同款命令对 chart 做本地校验scripts/helm-pre-commit.sh 中的流程$ helm lint charts/budibase按 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/databasevalues 注释明确不支持其他镜像README 描述 3.0.0 时子 chart 版本为4.3.0当前仓库实际锁定4.5.6见 Chart.lockREADME 的配置文档链接仍指向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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 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 的变更先建立旧配置到新配置的映射2.x 的情况3.0.0 的处理依赖 chart 捆绑的ingress-nginx提供 Ingress 控制器chart 不再捆绑需要自行在集群部署 Ingress 控制器EKS 上用ingress.enabled: falseingress.aws: true启用 ALB改为awsAlbIngress.enabled: true全部配置移到awsAlbIngress下hpa.enabled: true一个开关控制 HPA拆成services.apps.autoscaling、services.worker.autoscaling、services.proxy.autoscaling三个独立块CouchDB 子 chart3.3.4CouchDB 3.1.1子 chart 升到4.3.0CouchDB 3.2.1且改用 Budibase 自建镜像以下按 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: PrefixEKS / AWS ALB 路径。2.x 里靠ingress.enabled: falseingress.aws: true启用的 ALB Ingress3.0.0 起改为awsAlbIngress: enabled: true原来散在别处的 ALB 配置全部收敛到awsAlbIngress下values.yaml 中可见的键包括certificateArnHTTPS 时填 ACM 证书 ARN、accessLogs写入 S3 的访问日志enabled/bucket/prefixbucket 必须已存在于同 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.0CouchDB 版本随之从 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.yamluuid 必填。子 chart 自 3.0.0 起要求显式设置couchdbConfig.couchdb.uuid。当前主 chart 的 values.yaml 已在couchdb.couchdbConfig.couchdb.uuid给了默认值budibase-couchdb如果旧 release 的 values 没设过这项升级时要确保它出现在 values 里。子 chart README 给出了升级示例用--set couchdbConfig.couchdb.uuidUUID注入自生成的 UUID$ helm upgrade release-name \ --version3.6.4 \ --reuse-values \ --set couchdbConfig.couchdb.uuidUUID \ couchdb/couchdb注意该示例是针对直接升级 couchdb 子 chart 的写法对 Budibase 主 chart 升级时uuid 落在couchdb覆盖键下即couchdb.couchdbConfig.couchdb.uuid且UUID需替换为你实际生成的值。跨 4.0.0 的 secret 变更。从3.3.4到4.3.0跨越了子 chart 4.0.0其破坏性变更是 secret 中的adminHash不再经由password.ini只存储adminHash本身。子 chart README 的提示是如果你自己管理这个 secret升级时相应调整。镜像不要改。主 chart 固定使用自定义镜像budibase/databasevalues.yaml 中 tag 为2.1.0pullPolicy: 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 # 按需选择不需要就保持默认 falsevalues.yaml 的注释给出 HPA 生效的两个前提集群配置了metrics-server且对应服务 Pod 设置了resources。README 的前置条件一节也单独列出了metrics-serverif you want to make use of horizontal pod autoscaling。另外当前 values.yaml 中services.automationWorkers也带autoscaling块默认同样关闭这是 3.0.0 拆分之后新增的服务可按需启用。执行升级准备条件README Prerequisiteshelmv3 及以上、Kubernetes 1.4要定义 Ingress 资源则集群需有 Ingress 控制器要用 HPA 需metrics-server用持久存储需存储控制器。操作步骤基于现有 values 整理出 3.0.0 的新values.yaml把上文的 Ingress、CouchDB uuid、HPA 各块替换到位升级前可用仓库的 pre-commit 校验脚本同款命令对 chart 做本地校验scripts/helm-pre-commit.sh 中的流程$ helm lint charts/budibase按 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/databasevalues 注释明确不支持其他镜像README 描述 3.0.0 时子 chart 版本为4.3.0当前仓库实际锁定4.5.6见 Chart.lockREADME 的配置文档链接仍指向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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考