6.1 部署方案：Docker起步与K8s生产化

6.1 部署方案：Docker起步与K8s生产化

本节摘要：DataHub 提供两条部署路径：Docker 单机组合适合评估与演示，半小时可跑通；Kubernetes 生产部署面向持续服役，组件清单、资源配置、存储选型与升级策略都要过一遍。本节给出两条路径的完整操作要点与一份生产化检查清单，并用一张拓扑图标出每个组件的运维属性。本节承接第 2 章的架构认知，是 6.2 扩容与 6.4 监控的物理基础。

先分清两条路径的定位

Docker 组合部署的价值是"快"：一条命令拉起全部组件，评估选型、开发调试、给决策层做演示，它都是最短路径。但要清楚它的天花板：单机单点、无自动恢复、资源混部互相干扰、升级要整体重来。它可以陪你走完选型，不能陪你走进生产。

Kubernetes 部署的价值是"稳"：服务组件以带探活与自愈的容器组运行，存储由持久卷承载，升级按滚动策略进行，扩容改副本数即可。代价是需要 K8s 基础设施与相应的运维能力。两条路径不是二选一的坑，而是同一个时间轴上的两站——多数团队的正确路线是 Docker 起步验证，立项后迁移 K8s，且迁移时主库数据要完整搬迁（它在 2.1 就被定义为唯一事实来源）。

图17 生产部署拓扑与运维属性标注

Docker 起步：半小时跑通

官方提供一键化的组合编排文件，拉取后执行启动命令，数十个容器依次就绪。给三个提速与避坑要点。镜像版本统一：组合文件里的服务镜像要来自同一发布版本，混版本会出现 4.5 复盘里"摄入成功界面空白"的接口不兼容——起步第一天就指定统一版本号，升级时整体同步。首次启动要等就绪：全部容器运行不等于服务可用，索引初始化要额外一段时间，以健康检查端点返回正常为准，急着重试只会制造脏数据。演示数据可选：组合部署支持附带示例元数据，评估阶段建议带上——空平台的演示说服力远不如一张有血有肉的样例地图。

K8s 生产化：检查清单

迁移生产时，逐项过下面这份清单，每一项都对应一类真实事故。

组件完整性：对照第 2 章架构逐个确认——前端、GMS、消息队列、索引消费者、三存储，少一个组件都会以诡异症状迟到地暴露，最常被漏掉的是索引消费者（它没界面，挂了不影响部署成功）。资源配置：GMS 与前端内存占用温和，图库与搜索索引吃内存，按官方基准起步再观察调整；存储卷的容量规划留给 6.4 的巡检节奏。存储选型：主库选组织内标准的关系型数据库服务而非自建容器（备份与高可用交给数据库平台）；图库与索引可容器化，持久卷必须配。探活与自愈：服务层配就绪与存活探针；消费者组件的探针要包含积压健康度，单纯进程活着但积压如山不如让它重启。升级策略：平台版本升级前看发布说明的破坏性变更清单，先升测试环境跑一轮摄入验证，主库在升级前做一次快照——模型变更可能伴随存储结构迁移，回退依赖快照。

对外暴露与入口：前端通过集群入口暴露，接入执行器与 GMS 的通路走集群内服务名；如果组织有统一的网关与域名规范，按规范接入。生产环境的访问凭证管理在 6.3 展开。

从评估到生产的迁移清单

Docker 评估环境的数据要迁到 K8s 生产环境时，走"导出重灌"而非"搬库"：把评估环境的元数据按实体批量导出，作为一轮全量摄入灌进生产环境。原因有三：评估环境的存储版本可能与生产不同构；导出重灌顺便验证了全量摄入链路；评估期的试验性数据（乱打的标签、测试实体）在迁移时正好清洗掉。主库迁移是生产化过程中最不该省的一步是迁移演练：先在测试集群完整走一遍导出、灌入、验证流程，把耗时和坑摸清，再动生产。

⚠️ 不要长期运行"Docker 单机加定时快照"的准生产形态。它最大的风险不是丢数据，而是单机停机时整个组织的找数习惯被摔断两次——第一次坏时大家等它修好，第二次坏时大家回到群聊，第三次没人再回来。

一套中型部署的起点配置

给一个实体量级在数十万的组织的起点配置，作为容量规划的讨论基础而非照抄模板。无状态层：前端两副本各一核两 GB，GMS 两副本各两核四 GB；事件链路：索引消费者两副本各一核两 GB，消息队列三节点小集群；存储层：主库交给组织的数据库服务（四核十六 GB 起步、每日备份），搜索索引三节点各两核八 GB，图库两核八 GB 起步。整套起步规格用不大不小的三到四台工作节点就能放下。

配置之外，三条经验比数字更重要。起步规格宁小勿大，扩容靠数据：所有组件都支持平滑扩，起步超配的资源九成时间在空转，而巡检曲线（6.4）会告诉你该扩谁。内存是稀缺品：索引与图库吃内存，K8s 节点的内存超卖比要保守，内存型 OOM 重启在这两类组件上的代价是缓存冷启动与重建风暴。为消费者预留突发额度：全量摄入的洪峰场景（4.5 复盘里那类项目节点）会瞬时抬高事件链路负载，给消费者副本配置横向自动扩缩的余量，洪峰过后自动回落。

镜像与依赖的拉取纪律

部署细节里最值得立规矩的是镜像管理。三条纪律：用私有镜像仓库中转——生产集群直接从公网镜像源拉取，慢且不可控，官方镜像同步进组织私有仓库，部署的速度与可重复性都由它保证；固定版本标签或摘要——用 latest 标签部署是赌博，生产清单里每个镜像写明确版本号，更稳妥的做法是固定到镜像摘要；同步声明配套组件版本——平台镜像与它依赖的搜索引擎、消息队列镜像有版本对应关系，混搭的隐患在 4.5 复盘已经领教过，把"哪个平台版本配哪些组件版本"写成一张对照表放进部署文档。

这三条执行成本极低，却挡住了部署故障里出现频率最高的一类："昨天还能装，今天装不出来"——通常不是平台的错，是某个镜像标签在远端被悄悄覆盖了。

升级窗口的标准动作

平台版本升级每季度一次是健康的节奏。把升级做成标准动作清单：升级前两周，读发布说明里的破坏性变更与模型变更清单，对照 3.3 的三色判级评估影响；升级前一周，测试环境完成全流程验证（部署、摄入、搜索、血缘、界面回归）；升级当日，主库快照、按官方顺序滚动升级服务组件、观察索引消费者追平积压；升级后三日，重点盯搜索质量信号与一致性抽样——索引层面的漂移往往在升级后一两天内才显形。清单写在值班手册里，升级从"大动作"退化成"例行公事"，是运维成熟度的标志。

部署的最后一道题是文档：把部署拓扑、版本对照表、资源配置与变更记录写成一份“平台户口本”。它在新成员接手、故障复盘、容量申请三个场景的价值，会在运营的第一年里反复兑现——写它的最佳时机是部署当天，记忆最新鲜的那天。

部署完成后，把集群里实际运行的组件清单与本章拓扑图核对一遍，确认每个部件的副本数与资源限制符合预期——图纸与实物的第一次对账，越早越好。

本节要点回顾

• 两条路径的定位：Docker 走评估与演示，K8s 走生产服役；迁移走导出重灌并先做演练。
• 版本统一：服务镜像必须同版本，混版本的症状是写入成功而界面异常。
• 清单五项：组件完整、资源配置、存储选型、探活自愈、升级策略，逐项对应真实事故。
• 存储分级：主库交给数据库服务保备份，图库与索引可重建、故障即重建任务。
• 准生产陷阱：单机加快照的形态伤害的是组织使用习惯，迟早要么转正要么报废。

平台跑起来了，接下来让它稳住。下一节讲扩容决策与三类典型事件的处理：索引重建、消息积压、主库瓶颈。