必须用 timescaledb-multinode Chart 部署生产级多节点集群：需添加官方 Helm 仓库、匹配 Kubernetes/PostgreSQL 版本、显式配置 storageClassName 和 accessModes、使用 headless Service 域名连接、扩容前停写并手动注册节点及迁移 chunk。
直接用 Helm 部署 TimescaleDB 多节点集群，别碰单节点 Chart
TimescaleDB 官方 timescaledb-single Chart 仅适合验证，生产环境必须用 timescaledb-multinode。单节点 Chart 缺少流复制配置、无自动故障转移、不支持 hypertable 分布式写入——这些在 Kubernetes 里不是“可选”，而是“不配就崩”。
关键操作步骤：
- 先添加官方 repo：
helm repo add timescale https://charts.timescale.com - 确认版本兼容性：Kubernetes v1.22+、PostgreSQL 14/15 对应的
timescaledb-multinodeChart 版本需匹配（如 v1.9.x 支持 PG 15 + TS 2.17） - 部署命令必须指定 namespace 和 values 文件：
helm install tsdb timescale/timescaledb-multinode -n timescale-ns -f values.yaml
storageClassName 和 PVC 模板必须显式声明，否则 Pod 卡在 Pending
默认 Chart 的 values.yaml 里 storageClassName 是空字符串，Kubernetes 会 fallback 到 default StorageClass——但多数生产集群（尤其启用了 CSI driver 的云环境）没有 default，或 default 不支持 ReadWriteMany。结果就是所有 data node 的 PVC 一直 Pending。
必须手动补全以下字段：
-
dataNode.persistence.storageClassName：填你集群实际存在的 StorageClass 名（如alicloud-disk-ssd或rook-ceph-block） -
dataNode.persistence.accessModes：多节点集群必须为["ReadWriteOnce"]（每个 data node 独占 PV），别误设成ReadWriteMany -
configNode.persistence同理，且容量建议 ≥20Gi，避免元数据写满导致集群不可用
连接串里的 host 必须用 Service 名，不能用 Pod IP 或 NodePort
部署后，tsdb-timescaledb-ha 这个 headless Service 提供内部 DNS 名称，客户端连接时 host 必须填 tsdb-timescaledb-ha.timescale-ns.svc.cluster.local（或简写 tsdb-timescaledb-ha）。填错会导致：
针对 Kubernetes 仪表板和 Web UI 的浏览器自动化。适用于与 Kubernetes Dashboard、Grafana、ArgoCD UI 或其他 Web 界面交互。需要设置 MCP_BROWSER_ENABLED=true。
- 连接超时（Pod IP 无法跨节点路由）
- 写入失败（NodePort 绕过 HA proxy，直连某节点，破坏一致性）
- 连续聚合失效（依赖 coordinator 节点分发任务，直连 data node 会跳过调度）
验证方式：kubectl -n timescale-ns exec -it <i>any-pod</i> -- psql -h tsdb-timescaledb-ha -U postgres -d postgres -c "SELECT * FROM timescaledb_information.hypertables;"
扩容 data node 前，必须先停写并检查 chunk 分布
TimescaleDB 多节点集群扩容不是“改个 replicas 就完事”。直接增加 data node 数量，新节点不会自动接管已有 hypertable 的 chunk，反而可能因 coordinator 调度混乱导致写入阻塞。
安全扩容流程：
- 先执行
SELECT * FROM timescaledb_experimental.attached_data_node('new_node_name');手动注册节点 - 再运行
CALL distributed_move_chunk(...)显式迁移部分 chunk（注意 chunk 名称和时间范围） - 最后才调整 StatefulSet 的
replicas并重启 coordinator - 过程中严禁应用写入，否则 chunk 元数据可能不一致
最容易被忽略的是：扩容后必须手动触发 ALTER TABLE ... SET (timescaledb.distributed = true) 重置分布策略，否则新表仍走本地存储。
