Dagster 升级小版本时如何在 Kubernetes 环境迁移 Dagster 实例【免费下载链接】dagsterAn orchestration platform for the development, production, and observation of data assets.项目地址: https://gitcode.com/GitHub_Trending/da/dagster当 Dagster 升级跨过了小版本minor version除了升级镜像和 Helm chart通常还需要对 Dagster 实例做一次数据库迁移。官方文档明确指出只有升级小版本时才会要求运行迁移Migrations will only be required if you are upgrading your minor version。本文适用于通过 Dagster Helm chart 在 Kubernetes 上部署 OSS Dagster 的环境目标是在完成 chart 升级后用 Helm chart 自带的 Kubernetes Job 跑完dagster instance migrate迁移然后把 webserver 和 daemon 服务恢复回原来的副本数。完整步骤参见 migrating-while-upgrading.md。开始前的准备条件执行迁移前需要完成以下准备工作查阅 Dagster 升级指南确认目标版本是否还有额外步骤。升级指南MIGRATION.md按版本列出了各小版本的 breaking changes、弃用项以及是否需要数据库迁移例如 1.9.0 会为runs表和bulk_actions表新增列并新建backfill_tags表1.2.0、1.1.1 等版本也提供了通过dagster instance migrate运行的可选 schema 迁移。备份 PostgreSQL 数据库。迁移会修改实例存储的 schema官方将其列为硬性前置条件。确认集群中只有一个 Dagster Helm release。文档假设每个 Kubernetes 集群只安装了一个 Dagster Helm chart release所有命令都要在正确的 namespace 下执行。第一步升级 Helm chart先刷新本地仓库索引获取与 OSS 版本同步更新的 chart 信息helm repo update然后执行helm upgrade指定你要升级到的 Dagster chart 版本和你自己的 Helm valueshelm upgrade --install dagster dagster/dagster -f /path/to/values.yaml其中/path/to/values.yaml是你安装 Dagster Helm chart 时所用的 values 文件路径替换成你自己的实际路径。该命令会安装新 chart如果dagsterrelease 已存在则直接修改现有 release。第二步缩容 webserver 和 daemon迁移执行期间不能有其他正在运行的 job run 继续向数据库写入所以需要先把 webserver 和 daemon 的 Deployment 缩到 0 副本。缩容前要先记录各自的副本数迁移完成后再按原值恢复# 获取 Helm 创建的 webserver 和 daemon deployment 名称 export WEBSERVER_DEPLOYMENT_NAMEkubectl get deploy \ --selectorcomponentdagster-webserver -o jsonpath{.items[0].metadata.name} export DAEMON_DEPLOYMENT_NAMEkubectl get deploy \ --selectorcomponentdagster-daemon -o jsonpath{.items[0].metadata.name} # 记录各自的副本数迁移后用于恢复 export WEBSERVER_DEPLOYMENT_REPLICA_COUNTkubectl get deploy \ --selectorcomponentdagster-webserver -o jsonpath{.items[0].status.replicas} export DAEMON_DEPLOYMENT_REPLICA_COUNTkubectl get deploy \ --selectorcomponentdagster-daemon -o jsonpath{.items[0].status.replicas} # 缩容到 0 副本 kubectl scale deploy $WEBSERVER_DEPLOYMENT_NAME --replicas0 kubectl scale deploy $DAEMON_DEPLOYMENT_NAME --replicas0文档同时确认了这两个 Deployment 的标签选择器Helm chart 模板中 webserver 与 daemon 的 Deployment 分别带有component: dagster-webserver和component: dagster-daemon标签见 deployment-daemon.yaml因此上述--selector查询可以直接使用。第三步运行实例迁移 Job先记录你的 Dagster Helm release 名可运行helm list查看替换下面命令中的DAGSTER_RELEASE_NAME占位符export HELM_DAGSTER_RELEASE_NAMEDAGSTER_RELEASE_NAME用helm template渲染出迁移 Job 并应用到集群Job 中运行的是dagster instance migrate命令helm template $HELM_DAGSTER_RELEASE_NAME dagster/dagster \ --set migrate.enabledtrue \ --show-only templates/job-instance-migrate.yaml \ --values values.yaml \ | kubectl apply -f -这条命令有两个硬性前提必须在你安装 chart 时所用values.yaml文件所在目录下执行如果你本地没有该文件可以先从集群导出当前生效的 valueshelm get values $HELM_DAGSTER_RELEASE_NAME values.yaml。migrate.enabled在 chart 的 values.yaml 中默认为false注释明确说明该字段只应在一次性场景中临时开启。渲染出的 job-instance-migrate.yaml 会创建一个restartPolicy: Never的 Job容器内执行dagster instance migrate并复用 webserver 的镜像、环境变量和dagster.yaml配置因此 Job 连接的是与实例相同的数据库。验证迁移结果按以下顺序检查 Job 是否成功查询迁移 Job 产生的 pod 名称kubectl get pods -l job-namedagster-instance-migrate把上一步查到的 pod 名替换掉POD_NAME占位符检查 pod 详情kubectl describe pod POD_NAME确认该 pod 已正常结束且没有任何错误再进入下一步。如果 pod 处于错误状态应先排查 Job 输出再恢复服务不要在迁移未成功时把 Deployment 缩回去。第四步恢复副本数迁移验证通过后用第二步记录的副本数把两个 Deployment 缩回原规模kubectl scale deploy $WEBSERVER_DEPLOYMENT_NAME --replicas$WEBSERVER_DEPLOYMENT_REPLICA_COUNT kubectl scale deploy $DAEMON_DEPLOYMENT_NAME --replicas$DAEMON_DEPLOYMENT_REPLICA_COUNT限制与注意事项该流程只覆盖Helm chart 部署 小版本升级的场景。跨小版本升级本身还可能有代码层面的 breaking changes如 API 移除、参数改名是否受影响需要对照 MIGRATION.md 中对应版本的章节逐条确认这部分无法由迁移 Job 代替。所有kubectl/helm命令都要在 Dagster 所在的 namespace 下执行文档假设集群中只有一个 Dagster Helm release多 release 集群需要自行区分 release 名再套用同样的流程。迁移 Job 是一次性资源它依赖migrate.enabledtrue临时渲染默认关闭不要把它当作常驻配置写进 values。【免费下载链接】dagsterAn orchestration platform for the development, production, and observation of data assets.项目地址: https://gitcode.com/GitHub_Trending/da/dagster创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/9/15 15:42:55 · 阅读 1.2k Dagster 升级小版本时如何在 Kubernetes 环境迁移 Dagster 实例？
Dagster 升级小版本时如何在 Kubernetes 环境迁移 Dagster 实例【免费下载链接】dagsterAn orchestration platform for the development, production, and observation of data assets.项目地址: https://gitcode.com/GitHub_Trending/da/dagster当 Dagster 升级跨过了小版本minor version除了升级镜像和 Helm chart通常还需要对 Dagster 实例做一次数据库迁移。官方文档明确指出只有升级小版本时才会要求运行迁移Migrations will only be required if you are upgrading your minor version。本文适用于通过 Dagster Helm chart 在 Kubernetes 上部署 OSS Dagster 的环境目标是在完成 chart 升级后用 Helm chart 自带的 Kubernetes Job 跑完dagster instance migrate迁移然后把 webserver 和 daemon 服务恢复回原来的副本数。完整步骤参见 migrating-while-upgrading.md。开始前的准备条件执行迁移前需要完成以下准备工作查阅 Dagster 升级指南确认目标版本是否还有额外步骤。升级指南MIGRATION.md按版本列出了各小版本的 breaking changes、弃用项以及是否需要数据库迁移例如 1.9.0 会为runs表和bulk_actions表新增列并新建backfill_tags表1.2.0、1.1.1 等版本也提供了通过dagster instance migrate运行的可选 schema 迁移。备份 PostgreSQL 数据库。迁移会修改实例存储的 schema官方将其列为硬性前置条件。确认集群中只有一个 Dagster Helm release。文档假设每个 Kubernetes 集群只安装了一个 Dagster Helm chart release所有命令都要在正确的 namespace 下执行。第一步升级 Helm chart先刷新本地仓库索引获取与 OSS 版本同步更新的 chart 信息helm repo update然后执行helm upgrade指定你要升级到的 Dagster chart 版本和你自己的 Helm valueshelm upgrade --install dagster dagster/dagster -f /path/to/values.yaml其中/path/to/values.yaml是你安装 Dagster Helm chart 时所用的 values 文件路径替换成你自己的实际路径。该命令会安装新 chart如果dagsterrelease 已存在则直接修改现有 release。第二步缩容 webserver 和 daemon迁移执行期间不能有其他正在运行的 job run 继续向数据库写入所以需要先把 webserver 和 daemon 的 Deployment 缩到 0 副本。缩容前要先记录各自的副本数迁移完成后再按原值恢复# 获取 Helm 创建的 webserver 和 daemon deployment 名称 export WEBSERVER_DEPLOYMENT_NAMEkubectl get deploy \ --selectorcomponentdagster-webserver -o jsonpath{.items[0].metadata.name} export DAEMON_DEPLOYMENT_NAMEkubectl get deploy \ --selectorcomponentdagster-daemon -o jsonpath{.items[0].metadata.name} # 记录各自的副本数迁移后用于恢复 export WEBSERVER_DEPLOYMENT_REPLICA_COUNTkubectl get deploy \ --selectorcomponentdagster-webserver -o jsonpath{.items[0].status.replicas} export DAEMON_DEPLOYMENT_REPLICA_COUNTkubectl get deploy \ --selectorcomponentdagster-daemon -o jsonpath{.items[0].status.replicas} # 缩容到 0 副本 kubectl scale deploy $WEBSERVER_DEPLOYMENT_NAME --replicas0 kubectl scale deploy $DAEMON_DEPLOYMENT_NAME --replicas0文档同时确认了这两个 Deployment 的标签选择器Helm chart 模板中 webserver 与 daemon 的 Deployment 分别带有component: dagster-webserver和component: dagster-daemon标签见 deployment-daemon.yaml因此上述--selector查询可以直接使用。第三步运行实例迁移 Job先记录你的 Dagster Helm release 名可运行helm list查看替换下面命令中的DAGSTER_RELEASE_NAME占位符export HELM_DAGSTER_RELEASE_NAMEDAGSTER_RELEASE_NAME用helm template渲染出迁移 Job 并应用到集群Job 中运行的是dagster instance migrate命令helm template $HELM_DAGSTER_RELEASE_NAME dagster/dagster \ --set migrate.enabledtrue \ --show-only templates/job-instance-migrate.yaml \ --values values.yaml \ | kubectl apply -f -这条命令有两个硬性前提必须在你安装 chart 时所用values.yaml文件所在目录下执行如果你本地没有该文件可以先从集群导出当前生效的 valueshelm get values $HELM_DAGSTER_RELEASE_NAME values.yaml。migrate.enabled在 chart 的 values.yaml 中默认为false注释明确说明该字段只应在一次性场景中临时开启。渲染出的 job-instance-migrate.yaml 会创建一个restartPolicy: Never的 Job容器内执行dagster instance migrate并复用 webserver 的镜像、环境变量和dagster.yaml配置因此 Job 连接的是与实例相同的数据库。验证迁移结果按以下顺序检查 Job 是否成功查询迁移 Job 产生的 pod 名称kubectl get pods -l job-namedagster-instance-migrate把上一步查到的 pod 名替换掉POD_NAME占位符检查 pod 详情kubectl describe pod POD_NAME确认该 pod 已正常结束且没有任何错误再进入下一步。如果 pod 处于错误状态应先排查 Job 输出再恢复服务不要在迁移未成功时把 Deployment 缩回去。第四步恢复副本数迁移验证通过后用第二步记录的副本数把两个 Deployment 缩回原规模kubectl scale deploy $WEBSERVER_DEPLOYMENT_NAME --replicas$WEBSERVER_DEPLOYMENT_REPLICA_COUNT kubectl scale deploy $DAEMON_DEPLOYMENT_NAME --replicas$DAEMON_DEPLOYMENT_REPLICA_COUNT限制与注意事项该流程只覆盖Helm chart 部署 小版本升级的场景。跨小版本升级本身还可能有代码层面的 breaking changes如 API 移除、参数改名是否受影响需要对照 MIGRATION.md 中对应版本的章节逐条确认这部分无法由迁移 Job 代替。所有kubectl/helm命令都要在 Dagster 所在的 namespace 下执行文档假设集群中只有一个 Dagster Helm release多 release 集群需要自行区分 release 名再套用同样的流程。迁移 Job 是一次性资源它依赖migrate.enabledtrue临时渲染默认关闭不要把它当作常驻配置写进 values。【免费下载链接】dagsterAn orchestration platform for the development, production, and observation of data assets.项目地址: https://gitcode.com/GitHub_Trending/da/dagster创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考