Kubernetes（Helm）
用 Helm 安装 Busabase Premium——chart 做了什么、哪两个值配错会让附件和登录悄悄坏掉、以及什么时候该接你自己的 Postgres 与 S3。
chart 在公开仓库 busabase/busabase-premium 的 helm/ 目录下。它就是 Compose 部署的 Kubernetes 表达，所以 Compose 生产部署里讲的一切在这里同样成立。
安装
git clone https://github.com/busabase/busabase-premium.git
helm install busabase ./busabase-premium/helm \
--namespace busabase --create-namespace \
--set image.tag=0.10.0 \
--set appUrl=https://busabase.company.internal这两个值都是必填的，缺了 chart 会直接拒绝渲染，而不是装出一个半好不好的东西：
image.tag—— 故意要求钉版本。跟着浮动 tag 走的 chart，会在任何一次 pod 重启时把实例升级掉，这不是你想要的性质，尤其它上面存着你的数据。appUrl—— 用户实际输入的地址。登录 cookie 按它签发，所以对不上的表现是：登录看起来成功，然后立刻弹回登录页，日志里什么都不说。
它会创建什么
| 对象 | 用途 |
|---|---|
Deployment | 应用 |
Job（Helm hook） | 迁移，每次发布跑一次，在应用滚动之前 |
StatefulSet ×2 | 内置 Postgres 与对象存储（外部模式下不创建） |
Service ×3 | 应用、Postgres、存储 |
Secret | 生成的凭据，升级时保留 |
迁移是 hook，不是 initContainer
这个 Job 是 pre-install,pre-upgrade hook，有两个原因：
- 每次发布跑一次，不是每个副本跑一次。 用 initContainer 的话，每个副本都会抢着迁移同一个库，失败的那个报出来的样子像「schema 损坏」，不像「锁冲突」。
- 迁移失败会让整次发布失败。
helm upgrade停住，现有 pod 继续用旧代码服务旧 schema——而不是让新 pod 跑在半迁移的 schema 上。
失败的 Job 会保留下来供你看日志。报错里有失败的 SQL 语句，但没有它来自哪个文件——拿那条语句去迁移目录 grep 就能定位。
对象存储必须是浏览器够得着的
上传走预签名 PUT、下载走跳转，所以是浏览器直接访问对象存储——跟它在云版访问 S3 是同一回事。这个地址必须对浏览器可解析。集群内部的 Service 名字不行，而症状极具误导性：应用正常、登录正常，就是每次附件上传都失败。
默认情况下 chart 从 appUrl 推导存储主机，通常是对的。存储走另一个主机名时设 storage.publicHost，并把两个主机都挂到你的 Ingress 后面。
接你自己的 Postgres 与 S3
内置的那两个存在，只是为了让 helm install 能装出一个能跑的东西。它们都不是生产答案：内置 Postgres 是单 pod，无故障转移、无时间点恢复，备份得你自己安排。
helm install busabase ./busabase-premium/helm \
--set image.tag=0.10.0 \
--set appUrl=https://busabase.company.internal \
--set postgres.mode=external \
--set postgres.external.host=pg.company.internal \
--set storage.mode=external \
--set storage.publicHost=s3.company.internal外部模式下，两个 StatefulSet 都不会创建。
密钥
Postgres 密码、对象存储密钥、会话签名密钥在首次安装时生成，升级时保留——chart 会读回已存在的 Secret，而不是重新生成一套。这不是细节：换了会话密钥所有人被登出，换了 Postgres 密码应用连自己的数据库都打不开。
想自己管这些密钥就设 secrets.existingSecret，chart 便不再创建任何密钥。
激活
与其他部署形态完全一样：系统管理 → 授权，粘贴，保存。验签在本机完成，不需要联网。见授权。