Kubernetes 与多副本

Kubernetes 部署运行同一个受管理 Node 服务。PostgreSQL 与 S3 由外部供应，初次仍要本机配对；多副本不会改变权限、Store 或 Mailbox 的权威模型。

从单副本开始

网关仓库的 chart 位于 deploy/helm/tool-bridge。根据对应版本的 values.yaml 设置镜像、bootstrap PVC、Service 和 Ingress：

helm upgrade --install tool-bridge ./deploy/helm/tool-bridge \
  --namespace tool-bridge --create-namespace \
  --values ./values.production.yaml

先使用默认单副本，准备持久 bootstrap 卷及 PG/S3 服务。在实际应用 Pod 内执行 node /app/dist/admin.js pair，经受保护安装界面提交连接与公开 canonical origin。验证 /readyz 和受限业务调用后再扩容。

扩容前必须共享哪些状态

依赖	多副本要求
PostgreSQL	同一个实例权威数据库
S3	同一套已登记后端，保留历史 backendId
bootstrap	同一个已初始化身份与根，使用共享卷
Redis	跨副本设备路由

Chart 的多副本需要明确共享的 RWX bootstrap PVC；不要让每个 Pod 独立 setup 成不同实例。未配置 Redis 时，服务会拒绝第二个活跃副本。

设备 socket 只在一个副本上，Redis 帮助其他副本把实时调用路由过去。presence 只是当前可路由提示，不是授权真源。Mailbox 通过 PG 领域仓库和 HTTP pull 工作，不依赖活 WebSocket 才能保存任务。

Readiness 与滚动更新

负载均衡器使用 /readyz。安装、恢复、维护、依赖不可用或 draining 时它返回 503；/livez 仅证明进程存活。

在配置页应用合适的 shutdownDrainSec，并为容器终止留足排空时间。SIGTERM 先摘流量，再结束请求、设备和后台工作。观察真实关停，不能把进程消失等同于所有工作已完成。

维护和根轮换

多副本运行不代表支持无中断多副本根轮换。数据库迁移和 key mutation 要求其他副本正常 drain 并删除登记；失联心跳、断开的连接都不能替代这个证据。

先阅读维护与恢复。受限 tb deployment agent 只管理本机 Compose app，不自动修改 Kubernetes 或 Railway。平台升级继续由平台编排工具完成。

扩容、滚动更新和隔离恢复都应验证节点身份、旧对象字节、受限授权、设备重连及 Mailbox 终态，按上线检查保留脱敏证据。