DataHub Kubernetes 部署实战Helm Chart 架构、依赖编排与 system-update 零停机升级机制【免费下载链接】datahubThe Context Platform for your Data and AI Stack项目地址: https://gitcode.com/GitHub_Trending/da/datahub本篇技术指南聚焦 DataHub 在 Kubernetes 集群上的完整部署流程从官方 Helm Chart 的组件与依赖架构出发逐步完成 secrets 创建、依赖部署、DataHub 主 Chart 安装、端口暴露与 ingress 配置并深入剖析 system-update Job 及其 Kubernetes scale-down 升级机制。读者学完后将能够独立在 EKS / GKE / AKS 或 Minikube 上从零搭建一套生产级 DataHub 集群并理解升级时底层如何编排数据库迁移与索引重建。部署前置准备集群与工具链准备一个可用的 Kubernetes 集群DataHub 及其依赖组件Elasticsearch、Kafka、MySQL、可选的 Neo4j会以多个 StatefulSet / Deployment 形式运行因此需要一个资源充足的集群。官方推荐以下两类环境任选其一云托管集群如 Amazon EKS、Google Kubernetes EngineGKE、Azure Kubernetes ServiceAKS适合生产环境本地开发集群使用 Minikube。注意运行 DataHub 及其全部依赖至少需要 7GB 以上可用内存请在启动 Minikube 时显式分配例如minikube start --memory8192 --cpus4。安装 kubectl 与 Helm 3后续所有操作都依赖两个命令行工具kubectl用于管理 Kubernetes 资源、查看 Pod 状态、执行port-forward等操作安装方式见 Kubernetes 官方文档helm用于基于 Chart 渲染并部署资源。DataHub 仅支持 Helm 3Helm 2 的 Tiller 模型已不再兼容请确保helm version主版本号为 3。# 校验当前上下文指向目标集群 kubectl config current-context # 校验 Helm 主版本 helm version --short组件与外部依赖一张架构全景图四大核心组件DataHub 由 4 个主要组件构成Kubernetes 部署中每个组件都作为主datahubHelm Chart 下的一个subchart被定义与编排组件角色仓库中的对应模块GMSGeneralized Metadata Service元数据服务核心对外提供 GraphQL / Rest.li / OpenAPI 读写接口metadata-service 下的war、factories等MAE ConsumerMetadata Audit Event可选消费元数据变更事件MCL驱动搜索索引与图索引更新metadata-jobs/mae-consumer-jobMCE ConsumerMetadata Change Event可选消费元数据变更提议MCP执行异步写入metadata-jobs/mce-consumer-jobFrontend数据门户前端代理 GraphQL 请求并托管 UIdatahub-frontend值得注意的是MAE / MCE Consumer 在标准架构中为可选组件当 GMS 开启内嵌消费者时例如 Docker quickstart 的默认形态可以不需要独立部署它们但生产集群通常按独立 Deployment 部署以获得更好的隔离与扩展性。四大外部依赖主组件由 4 类外部基础设施驱动它们必须先于 DataHub 本体部署完成Kafka事件总线承载 MCP / MCL 消息流转本地数据库MySQL或 Postgres、MariaDB作为元数据主存储对应仓库中的 Ebean 存储层配置见 docs/deploy/environment-vars.md 中EBEAN_DATASOURCE_URL等变量搜索索引Elasticsearch承载全文检索与聚合图索引支持 Neo4j或 Elasticsearch两种实现对应GRAPH_SERVICE_IMPL配置。依赖如何部署prerequisites Chart官方在独立的 datahub-helm 仓库中提供了两个 Chartcharts/prerequisites一键部署上述依赖Elasticsearch、可选 Neo4j、MySQL、Kafka附带开箱即用的示例配置charts/datahub主 Chart部署 GMS、MAE/MCE Consumer、Frontend 等组件。依赖既可以由prerequisitesChart 部署在集群内也可以独立部署在本地数据中心或者直接使用云厂商的托管服务如 Amazon RDS、MSK、OpenSearch Service。Chart 内的默认 values 已经预置为指向prerequisites部署的依赖。去掉 Neo4j 依赖的方法若希望图索引改用 Elasticsearch 实现只需两步——首先在prerequisites的values.yaml中将neo4j.enabled设为false对应原文档中 values 的第 54 行附近然后在datahub主 Chart 的values.yaml中将graph_service_impl字段对应原文档 values 第 63 行附近从neo4j覆盖为elasticsearch。这与 docs/how/migrating-graph-service-implementation.md 描述的实现迁移路径一致GRAPH_SERVICE_IMPL的默认值就是elasticsearch。仓库现状说明Helm Chart 代码自 2021 年 7 月起已迁移至独立仓库acryldata/datahub-helm并发布到 Helm 仓库https://helm.datahubproject.io当前仓库仅保留迁移说明见 datahub-kubernetes/README.md。部署时直接使用 Helm 仓库即可无需拉取 Chart 源码。Quickstart从零到可访问的完整命令流以下步骤假设kubectl上下文已指向目标集群。第 1 步创建 MySQL 与 Neo4j 密码 Secrets部署时依赖服务会通过 Kubernetes Secret 读取数据库密码因此需要先创建两个 secretkubectl create secret generic mysql-secrets --from-literalmysql-root-passworddatahub kubectl create secret generic neo4j-secrets --from-literalneo4j-passworddatahub以上将密码设置为datahub仅为示例生产环境务必替换为随机强密码并确保后续 Helm values 中引用的 secret 名称与键名一致。第 2 步添加 DataHub Helm 仓库helm repo add datahub https://helm.datahubproject.io/第 3 步部署依赖prerequisites Charthelm install prerequisites datahub/datahub-prerequisites默认配置即对应charts/prerequisites/values.yaml中的预设。如需自定义例如调整 Elasticsearch 副本数、切换数据库类型、关闭 Neo4j可将配置写入自定义 values 文件后覆盖安装helm install prerequisites datahub/datahub-prerequisites --values path-to-values-file安装完成后用kubectl get pods验证依赖是否全部就绪健康状态应类似NAME READY STATUS RESTARTS AGE elasticsearch-master-0 1/1 Running 0 62m elasticsearch-master-1 1/1 Running 0 62m elasticsearch-master-2 1/1 Running 0 62m prerequisites-cp-schema-registry-cf79bfccf-kvjtv 2/2 Running 1 63m prerequisites-kafka-0 1/1 Running 2 62m prerequisites-mysql-0 1/1 Running 1 62m prerequisites-neo4j-community-0 1/1 Running 0 52m prerequisites-zookeeper-0 1/1 Running 0 62m第 4 步部署 DataHub 主 Charthelm install datahub datahub/datahubcharts/datahub/values.yaml中的默认值已经预置为指向 release 名为prerequisites的依赖服务Kafka、MySQL、Elasticsearch、Neo4j 的地址均由 release 名推导。如果你用其他 release 名部署了 prerequisites务必在安装前同步修改 values 中对应的依赖地址。关于认证配置的注意事项默认 values 会自动生成metadata_service_authentication所需的 signing key 与 salt 两个 secret 值无需手动干预如果想自行提供可参考values.yaml中的datahub.metadata_service_authentication配置块覆盖。后端认证机制的完整介绍见 docs/authentication/introducing-metadata-service-authentication.md。第 5 步验证 DataHub Pod 与 system-update Job再次运行kubectl get pods此时应能看到 DataHub 各组件 Pod 以及一个特殊的一次性 JobNAME READY STATUS RESTARTS AGE datahub-datahub-frontend-84c58df9f7-5bgwx 1/1 Running 0 4m2s datahub-datahub-gms-58b676f77c-c6pfx 1/1 Running 0 4m2s datahub-datahub-mae-consumer-7b98bf65d-tjbwx 1/1 Running 0 4m3s datahub-datahub-mce-consumer-8c57d8587-vjv9m 1/1 Running 0 4m2s datahub-datahub-system-update-xxxxx 0/1 Completed 0 4m50s elasticsearch-master-0 1/1 Running 0 97m elasticsearch-master-1 1/1 Running 0 97m elasticsearch-master-2 1/1 Running 0 97m prerequisites-cp-schema-registry-cf79bfccf-kvjtv 2/2 Running 1 99m prerequisites-kafka-0 1/1 Running 2 97m prerequisites-mysql-0 1/1 Running 1 97m prerequisites-neo4j-community-0 1/1 Running 0 88m prerequisites-zookeeper-0 1/1 Running 0 97m关键观察点datahub-datahub-system-update-xxxxx处于Completed状态说明数据库初始化与搜索索引创建已由 system-update Job 完成当前 Chart 使用统一的 system-update Job 承担数据库与索引的初始化因此独立的elasticsearchSetupJob与mysqlSetupJob默认处于禁用状态elasticsearchSetupJob.enabled: false、mysqlSetupJob.enabled: falseSQL 与索引的初始化分别由datahubSystemUpdate.sql.setup.enabled与datahubSystemUpdate.elasticsearch.setup.enabled控制两者默认均为true。第 6 步本地访问前端通过kubectl port-forward将前端 Pod 的 9002 端口映射到本地Pod 名可从上面的输出中获取本例为datahub-datahub-frontend-84c58df9f7-5bgwxkubectl port-forward datahub-frontend pod name 9002:9002随后即可在浏览器访问 http://localhost:9002。第 7 步对外暴露服务ingress确认所有 Pod 健康运行后为datahub-frontend配置 ingress 将 9002 端口发布到公网。典型做法是创建指向datahub-datahub-frontendService 的 Ingress 资源或使用云厂商的 ALB / NLB 注解AWS 上可参考 docs/deploy/aws.md。如需自定义路径前缀请参考 docs/deploy/BASE_PATH_CONFIGURATION.md。System Update 与升级机制源码级解读system-update Job 的职责DataHub Helm Chart 在每次升级upgrade时都会运行一个 system-update Job其核心职责包括应用数据库 schema 变更SQL setup在需要时重建reindex搜索索引执行其他阻塞式blocking或非阻塞式non-blocking的升级步骤。从源码结构看升级步骤被建模为两类接口BlockingSystemUpgrade与NonBlockingSystemUpgrade均位于 datahub-upgrade 模块。阻塞式步骤如索引重建BuildIndices见 BuildIndicesConfig.java会等待执行完成后才放行 GMS 等核心服务非阻塞式步骤则在启动后台运行不阻塞业务。各种升级步骤的开关、批大小与延迟均可通过环境变量调整详见 docs/deploy/environment-vars.md 的 System Update Configuration 一节。Kubernetes scale-down为阻塞式升级腾出资源当 system-update 在 Kubernetes 集群中运行时它还可以有选择地执行 scale-down 预处理在阻塞式升级例如需要 reindex 的 BuildIndices之前按 label selector 将部分 Deployment如 MAE / MCE Consumer缩容到 0并同时为其他 Deployment如 GMS按 label selector 设置临时环境变量升级完成后统一恢复原状。这套机制具有以下特性条件触发只有当某个阻塞式升级步骤如 reindex 触发的 BuildIndices明确请求时才会执行日常滚动升级不会无谓地缩容并行执行rollout等待 Deployment 就绪与 scale-down 操作在多个 Deployment 之间并行进行减少总等待时间状态可恢复所有副本数与 env 的原始值被持久化在一个ConfigMap中若重试次数超过上限DATAHUB_UPGRADE_K8_SCALE_DOWN_MAX_RETRIES默认 3 次步骤会恢复全部保存的状态、删除 ConfigMap 并报错退出避免阻塞后续升级。仓库中对应实现位于 KubernetesScaleDown.java实现BlockingSystemUpgrade接口与 KubernetesScaleDownStep.java。从 KubernetesScaleDownStep.java 的skip()逻辑可以看到当kubernetesServiceHost未配置即不在集群内运行时该步骤会被跳过因此非 Kubernetes 部署下该功能完全是无操作no-op。配置装配见 KubernetesScaleDownConfig.java它要求application.yaml中定义systemUpdate.kubernetesScaleDown配置块并在满足阻塞式升级条件时以Order(0)优先注册。scale-down 相关环境变量速查以下变量通常由 Helm Chart 为 system-update Job 自动注入仅在集群内运行时生效环境变量默认值说明DATAHUB_UPGRADE_K8_SCALE_DOWN_ENABLEDtruescale-down 总开关必须为 true 才会执行DATAHUB_UPGRADE_K8_SCALE_DOWN_JAVA_ENABLEDfalse是否启用基于 Java 的 scale-down 步骤需显式开启DATAHUB_UPGRADE_K8_SCALE_DOWN_MAX_RETRIES3Job 重启间最大重试次数超过后恢复状态、删除 ConfigMap 并失败DATAHUB_UPGRADE_K8_SCALE_DOWN_LABEL_SELECTORS由 Helm 注入需要缩容到 0 的 Deployment label selector 列表如 MAE、MCEDATAHUB_UPGRADE_K8_DEPLOYMENT_ENV_UPDATES由 Helm 注入JSON 数组配置缩容期间需要注入临时 env 的 Deployment如 GMS 关闭内嵌消费者DATAHUB_UPGRADE_K8_ROLLOUT_MAX_WAIT_SECONDS1800每次 Deployment rollout缩容或 env 变更的最长等待时间默认 30 分钟DATAHUB_UPGRADE_K8_ROLLOUT_POLL_SECONDS5rollout 状态轮询间隔秒NAMESPACE来自 Pod 字段命名空间由 Helm 通过 downward API 注入HELM_RELEASE_NAME由 Helm 注入Helm release 名用于构造状态 ConfigMap 名称完整的环境变量矩阵含 GMS 的 Kubernetes Operations OpenAPI 控制器KUBERNETES_OPERATIONS_API_ENABLED等见 docs/deploy/environment-vars.md。升级路径与潜在停机时间升级行为与可能出现的停机窗口请以 docs/how/updating-datahub.md 为准。从该文档可以提取出几个与 Kubernetes 部署强相关的要点升级前需确认各组件所需的最低版本并注意DATAHUB_SYSTEM_CLIENT_SECRET等凭据变量必须显式设置历史上硬编码默认值已被移除触发 reindex、增量索引迁移或可选的 Elasticsearch ZDU 时system-update 可能运行较长时间需为升级预留足够的维护窗口若系统更新采用 Elasticsearch 8 且开启了 mapping reindex可能出现每次 Helm 升级都触发一次映射重建的已知问题可通过在后续升级前设置ELASTICSEARCH_INDEX_BUILDER_MAPPINGS_REINDEXfalse规避较新版本支持通过 Helm 的global.datahub.systemUpdate.zdu开启零停机索引升级ZDU启用后 system-update 会跳过 scale-down 阶段以分阶段索引迁移的方式降低停机时间。其他常用 Helm 命令命令说明helm uninstall datahub卸载 DataHub如需连同依赖一起卸载可对prerequisitesrelease 执行同样的命令helm ls列出当前已部署的 Helm releasehelm history查看某个 release 的发布历史用于确认升级/回滚记录生产化建议与延伸阅读完成基础部署后面向生产环境还需要关注以下事项镜像版本固定生产集群应固定使用不可变的镜像 tag发布版本v*或提交 tagsha-short-sha避免使用随构建漂移的quickstart标签密钥管理将 MySQL / Neo4j / 认证签名密钥等敏感值交给外部 Secret 管理方案如 External Secrets、Vault并开启 GMS 后端认证存储与备份为 Elasticsearch、MySQL、Kafka 配置持久化卷与备份策略相关讨论可参考 docs/how/backup-datahub.md监控告警结合 docs/advanced/monitoring.md 为 GMS、Consumer 配置 Prometheus 指标采集与告警。如需进一步了解与本主题直接相关的机制推荐按以下顺序深入docs/how/updating-datahub.md —— 各版本升级的 breaking changes、已知问题与停机窗口docs/deploy/environment-vars.md —— system-update、Kafka、Ebean、Elasticsearch 等全部运维环境变量docs/authentication/introducing-metadata-service-authentication.md —— Helm values 中自动生成的签名密钥背后的认证体系datahub-upgrade 模块源码 —— system-update 步骤接口BlockingSystemUpgrade/NonBlockingSystemUpgrade与kubernetes包下的 scale-down 实现metadata-jobs 与 datahub-frontend —— MAE/MCE Consumer 与前端组件的源码结构理解每个 subchart 部署的对象形态。【免费下载链接】datahubThe Context Platform for your Data and AI Stack项目地址: https://gitcode.com/GitHub_Trending/da/datahub创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
DataHub Kubernetes 部署实战：Helm Chart 架构、依赖编排与 system-update 零停机升级机制
DataHub Kubernetes 部署实战Helm Chart 架构、依赖编排与 system-update 零停机升级机制【免费下载链接】datahubThe Context Platform for your Data and AI Stack项目地址: https://gitcode.com/GitHub_Trending/da/datahub本篇技术指南聚焦 DataHub 在 Kubernetes 集群上的完整部署流程从官方 Helm Chart 的组件与依赖架构出发逐步完成 secrets 创建、依赖部署、DataHub 主 Chart 安装、端口暴露与 ingress 配置并深入剖析 system-update Job 及其 Kubernetes scale-down 升级机制。读者学完后将能够独立在 EKS / GKE / AKS 或 Minikube 上从零搭建一套生产级 DataHub 集群并理解升级时底层如何编排数据库迁移与索引重建。部署前置准备集群与工具链准备一个可用的 Kubernetes 集群DataHub 及其依赖组件Elasticsearch、Kafka、MySQL、可选的 Neo4j会以多个 StatefulSet / Deployment 形式运行因此需要一个资源充足的集群。官方推荐以下两类环境任选其一云托管集群如 Amazon EKS、Google Kubernetes EngineGKE、Azure Kubernetes ServiceAKS适合生产环境本地开发集群使用 Minikube。注意运行 DataHub 及其全部依赖至少需要 7GB 以上可用内存请在启动 Minikube 时显式分配例如minikube start --memory8192 --cpus4。安装 kubectl 与 Helm 3后续所有操作都依赖两个命令行工具kubectl用于管理 Kubernetes 资源、查看 Pod 状态、执行port-forward等操作安装方式见 Kubernetes 官方文档helm用于基于 Chart 渲染并部署资源。DataHub 仅支持 Helm 3Helm 2 的 Tiller 模型已不再兼容请确保helm version主版本号为 3。# 校验当前上下文指向目标集群 kubectl config current-context # 校验 Helm 主版本 helm version --short组件与外部依赖一张架构全景图四大核心组件DataHub 由 4 个主要组件构成Kubernetes 部署中每个组件都作为主datahubHelm Chart 下的一个subchart被定义与编排组件角色仓库中的对应模块GMSGeneralized Metadata Service元数据服务核心对外提供 GraphQL / Rest.li / OpenAPI 读写接口metadata-service 下的war、factories等MAE ConsumerMetadata Audit Event可选消费元数据变更事件MCL驱动搜索索引与图索引更新metadata-jobs/mae-consumer-jobMCE ConsumerMetadata Change Event可选消费元数据变更提议MCP执行异步写入metadata-jobs/mce-consumer-jobFrontend数据门户前端代理 GraphQL 请求并托管 UIdatahub-frontend值得注意的是MAE / MCE Consumer 在标准架构中为可选组件当 GMS 开启内嵌消费者时例如 Docker quickstart 的默认形态可以不需要独立部署它们但生产集群通常按独立 Deployment 部署以获得更好的隔离与扩展性。四大外部依赖主组件由 4 类外部基础设施驱动它们必须先于 DataHub 本体部署完成Kafka事件总线承载 MCP / MCL 消息流转本地数据库MySQL或 Postgres、MariaDB作为元数据主存储对应仓库中的 Ebean 存储层配置见 docs/deploy/environment-vars.md 中EBEAN_DATASOURCE_URL等变量搜索索引Elasticsearch承载全文检索与聚合图索引支持 Neo4j或 Elasticsearch两种实现对应GRAPH_SERVICE_IMPL配置。依赖如何部署prerequisites Chart官方在独立的 datahub-helm 仓库中提供了两个 Chartcharts/prerequisites一键部署上述依赖Elasticsearch、可选 Neo4j、MySQL、Kafka附带开箱即用的示例配置charts/datahub主 Chart部署 GMS、MAE/MCE Consumer、Frontend 等组件。依赖既可以由prerequisitesChart 部署在集群内也可以独立部署在本地数据中心或者直接使用云厂商的托管服务如 Amazon RDS、MSK、OpenSearch Service。Chart 内的默认 values 已经预置为指向prerequisites部署的依赖。去掉 Neo4j 依赖的方法若希望图索引改用 Elasticsearch 实现只需两步——首先在prerequisites的values.yaml中将neo4j.enabled设为false对应原文档中 values 的第 54 行附近然后在datahub主 Chart 的values.yaml中将graph_service_impl字段对应原文档 values 第 63 行附近从neo4j覆盖为elasticsearch。这与 docs/how/migrating-graph-service-implementation.md 描述的实现迁移路径一致GRAPH_SERVICE_IMPL的默认值就是elasticsearch。仓库现状说明Helm Chart 代码自 2021 年 7 月起已迁移至独立仓库acryldata/datahub-helm并发布到 Helm 仓库https://helm.datahubproject.io当前仓库仅保留迁移说明见 datahub-kubernetes/README.md。部署时直接使用 Helm 仓库即可无需拉取 Chart 源码。Quickstart从零到可访问的完整命令流以下步骤假设kubectl上下文已指向目标集群。第 1 步创建 MySQL 与 Neo4j 密码 Secrets部署时依赖服务会通过 Kubernetes Secret 读取数据库密码因此需要先创建两个 secretkubectl create secret generic mysql-secrets --from-literalmysql-root-passworddatahub kubectl create secret generic neo4j-secrets --from-literalneo4j-passworddatahub以上将密码设置为datahub仅为示例生产环境务必替换为随机强密码并确保后续 Helm values 中引用的 secret 名称与键名一致。第 2 步添加 DataHub Helm 仓库helm repo add datahub https://helm.datahubproject.io/第 3 步部署依赖prerequisites Charthelm install prerequisites datahub/datahub-prerequisites默认配置即对应charts/prerequisites/values.yaml中的预设。如需自定义例如调整 Elasticsearch 副本数、切换数据库类型、关闭 Neo4j可将配置写入自定义 values 文件后覆盖安装helm install prerequisites datahub/datahub-prerequisites --values path-to-values-file安装完成后用kubectl get pods验证依赖是否全部就绪健康状态应类似NAME READY STATUS RESTARTS AGE elasticsearch-master-0 1/1 Running 0 62m elasticsearch-master-1 1/1 Running 0 62m elasticsearch-master-2 1/1 Running 0 62m prerequisites-cp-schema-registry-cf79bfccf-kvjtv 2/2 Running 1 63m prerequisites-kafka-0 1/1 Running 2 62m prerequisites-mysql-0 1/1 Running 1 62m prerequisites-neo4j-community-0 1/1 Running 0 52m prerequisites-zookeeper-0 1/1 Running 0 62m第 4 步部署 DataHub 主 Charthelm install datahub datahub/datahubcharts/datahub/values.yaml中的默认值已经预置为指向 release 名为prerequisites的依赖服务Kafka、MySQL、Elasticsearch、Neo4j 的地址均由 release 名推导。如果你用其他 release 名部署了 prerequisites务必在安装前同步修改 values 中对应的依赖地址。关于认证配置的注意事项默认 values 会自动生成metadata_service_authentication所需的 signing key 与 salt 两个 secret 值无需手动干预如果想自行提供可参考values.yaml中的datahub.metadata_service_authentication配置块覆盖。后端认证机制的完整介绍见 docs/authentication/introducing-metadata-service-authentication.md。第 5 步验证 DataHub Pod 与 system-update Job再次运行kubectl get pods此时应能看到 DataHub 各组件 Pod 以及一个特殊的一次性 JobNAME READY STATUS RESTARTS AGE datahub-datahub-frontend-84c58df9f7-5bgwx 1/1 Running 0 4m2s datahub-datahub-gms-58b676f77c-c6pfx 1/1 Running 0 4m2s datahub-datahub-mae-consumer-7b98bf65d-tjbwx 1/1 Running 0 4m3s datahub-datahub-mce-consumer-8c57d8587-vjv9m 1/1 Running 0 4m2s datahub-datahub-system-update-xxxxx 0/1 Completed 0 4m50s elasticsearch-master-0 1/1 Running 0 97m elasticsearch-master-1 1/1 Running 0 97m elasticsearch-master-2 1/1 Running 0 97m prerequisites-cp-schema-registry-cf79bfccf-kvjtv 2/2 Running 1 99m prerequisites-kafka-0 1/1 Running 2 97m prerequisites-mysql-0 1/1 Running 1 97m prerequisites-neo4j-community-0 1/1 Running 0 88m prerequisites-zookeeper-0 1/1 Running 0 97m关键观察点datahub-datahub-system-update-xxxxx处于Completed状态说明数据库初始化与搜索索引创建已由 system-update Job 完成当前 Chart 使用统一的 system-update Job 承担数据库与索引的初始化因此独立的elasticsearchSetupJob与mysqlSetupJob默认处于禁用状态elasticsearchSetupJob.enabled: false、mysqlSetupJob.enabled: falseSQL 与索引的初始化分别由datahubSystemUpdate.sql.setup.enabled与datahubSystemUpdate.elasticsearch.setup.enabled控制两者默认均为true。第 6 步本地访问前端通过kubectl port-forward将前端 Pod 的 9002 端口映射到本地Pod 名可从上面的输出中获取本例为datahub-datahub-frontend-84c58df9f7-5bgwxkubectl port-forward datahub-frontend pod name 9002:9002随后即可在浏览器访问 http://localhost:9002。第 7 步对外暴露服务ingress确认所有 Pod 健康运行后为datahub-frontend配置 ingress 将 9002 端口发布到公网。典型做法是创建指向datahub-datahub-frontendService 的 Ingress 资源或使用云厂商的 ALB / NLB 注解AWS 上可参考 docs/deploy/aws.md。如需自定义路径前缀请参考 docs/deploy/BASE_PATH_CONFIGURATION.md。System Update 与升级机制源码级解读system-update Job 的职责DataHub Helm Chart 在每次升级upgrade时都会运行一个 system-update Job其核心职责包括应用数据库 schema 变更SQL setup在需要时重建reindex搜索索引执行其他阻塞式blocking或非阻塞式non-blocking的升级步骤。从源码结构看升级步骤被建模为两类接口BlockingSystemUpgrade与NonBlockingSystemUpgrade均位于 datahub-upgrade 模块。阻塞式步骤如索引重建BuildIndices见 BuildIndicesConfig.java会等待执行完成后才放行 GMS 等核心服务非阻塞式步骤则在启动后台运行不阻塞业务。各种升级步骤的开关、批大小与延迟均可通过环境变量调整详见 docs/deploy/environment-vars.md 的 System Update Configuration 一节。Kubernetes scale-down为阻塞式升级腾出资源当 system-update 在 Kubernetes 集群中运行时它还可以有选择地执行 scale-down 预处理在阻塞式升级例如需要 reindex 的 BuildIndices之前按 label selector 将部分 Deployment如 MAE / MCE Consumer缩容到 0并同时为其他 Deployment如 GMS按 label selector 设置临时环境变量升级完成后统一恢复原状。这套机制具有以下特性条件触发只有当某个阻塞式升级步骤如 reindex 触发的 BuildIndices明确请求时才会执行日常滚动升级不会无谓地缩容并行执行rollout等待 Deployment 就绪与 scale-down 操作在多个 Deployment 之间并行进行减少总等待时间状态可恢复所有副本数与 env 的原始值被持久化在一个ConfigMap中若重试次数超过上限DATAHUB_UPGRADE_K8_SCALE_DOWN_MAX_RETRIES默认 3 次步骤会恢复全部保存的状态、删除 ConfigMap 并报错退出避免阻塞后续升级。仓库中对应实现位于 KubernetesScaleDown.java实现BlockingSystemUpgrade接口与 KubernetesScaleDownStep.java。从 KubernetesScaleDownStep.java 的skip()逻辑可以看到当kubernetesServiceHost未配置即不在集群内运行时该步骤会被跳过因此非 Kubernetes 部署下该功能完全是无操作no-op。配置装配见 KubernetesScaleDownConfig.java它要求application.yaml中定义systemUpdate.kubernetesScaleDown配置块并在满足阻塞式升级条件时以Order(0)优先注册。scale-down 相关环境变量速查以下变量通常由 Helm Chart 为 system-update Job 自动注入仅在集群内运行时生效环境变量默认值说明DATAHUB_UPGRADE_K8_SCALE_DOWN_ENABLEDtruescale-down 总开关必须为 true 才会执行DATAHUB_UPGRADE_K8_SCALE_DOWN_JAVA_ENABLEDfalse是否启用基于 Java 的 scale-down 步骤需显式开启DATAHUB_UPGRADE_K8_SCALE_DOWN_MAX_RETRIES3Job 重启间最大重试次数超过后恢复状态、删除 ConfigMap 并失败DATAHUB_UPGRADE_K8_SCALE_DOWN_LABEL_SELECTORS由 Helm 注入需要缩容到 0 的 Deployment label selector 列表如 MAE、MCEDATAHUB_UPGRADE_K8_DEPLOYMENT_ENV_UPDATES由 Helm 注入JSON 数组配置缩容期间需要注入临时 env 的 Deployment如 GMS 关闭内嵌消费者DATAHUB_UPGRADE_K8_ROLLOUT_MAX_WAIT_SECONDS1800每次 Deployment rollout缩容或 env 变更的最长等待时间默认 30 分钟DATAHUB_UPGRADE_K8_ROLLOUT_POLL_SECONDS5rollout 状态轮询间隔秒NAMESPACE来自 Pod 字段命名空间由 Helm 通过 downward API 注入HELM_RELEASE_NAME由 Helm 注入Helm release 名用于构造状态 ConfigMap 名称完整的环境变量矩阵含 GMS 的 Kubernetes Operations OpenAPI 控制器KUBERNETES_OPERATIONS_API_ENABLED等见 docs/deploy/environment-vars.md。升级路径与潜在停机时间升级行为与可能出现的停机窗口请以 docs/how/updating-datahub.md 为准。从该文档可以提取出几个与 Kubernetes 部署强相关的要点升级前需确认各组件所需的最低版本并注意DATAHUB_SYSTEM_CLIENT_SECRET等凭据变量必须显式设置历史上硬编码默认值已被移除触发 reindex、增量索引迁移或可选的 Elasticsearch ZDU 时system-update 可能运行较长时间需为升级预留足够的维护窗口若系统更新采用 Elasticsearch 8 且开启了 mapping reindex可能出现每次 Helm 升级都触发一次映射重建的已知问题可通过在后续升级前设置ELASTICSEARCH_INDEX_BUILDER_MAPPINGS_REINDEXfalse规避较新版本支持通过 Helm 的global.datahub.systemUpdate.zdu开启零停机索引升级ZDU启用后 system-update 会跳过 scale-down 阶段以分阶段索引迁移的方式降低停机时间。其他常用 Helm 命令命令说明helm uninstall datahub卸载 DataHub如需连同依赖一起卸载可对prerequisitesrelease 执行同样的命令helm ls列出当前已部署的 Helm releasehelm history查看某个 release 的发布历史用于确认升级/回滚记录生产化建议与延伸阅读完成基础部署后面向生产环境还需要关注以下事项镜像版本固定生产集群应固定使用不可变的镜像 tag发布版本v*或提交 tagsha-short-sha避免使用随构建漂移的quickstart标签密钥管理将 MySQL / Neo4j / 认证签名密钥等敏感值交给外部 Secret 管理方案如 External Secrets、Vault并开启 GMS 后端认证存储与备份为 Elasticsearch、MySQL、Kafka 配置持久化卷与备份策略相关讨论可参考 docs/how/backup-datahub.md监控告警结合 docs/advanced/monitoring.md 为 GMS、Consumer 配置 Prometheus 指标采集与告警。如需进一步了解与本主题直接相关的机制推荐按以下顺序深入docs/how/updating-datahub.md —— 各版本升级的 breaking changes、已知问题与停机窗口docs/deploy/environment-vars.md —— system-update、Kafka、Ebean、Elasticsearch 等全部运维环境变量docs/authentication/introducing-metadata-service-authentication.md —— Helm values 中自动生成的签名密钥背后的认证体系datahub-upgrade 模块源码 —— system-update 步骤接口BlockingSystemUpgrade/NonBlockingSystemUpgrade与kubernetes包下的 scale-down 实现metadata-jobs 与 datahub-frontend —— MAE/MCE Consumer 与前端组件的源码结构理解每个 subchart 部署的对象形态。【免费下载链接】datahubThe Context Platform for your Data and AI Stack项目地址: https://gitcode.com/GitHub_Trending/da/datahub创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考