| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[Feature] 增加云原生部署器 Co-authored-by: sceneryback<afterbreeze@hotmail.com> # message auto-generated for no-merge-commit merge: !67 merge feature/add-deployer into master [Feature] 增加云原生部署器 Created-by: gcw_gxG14I7x Commit-by: sceneryback Merged-by: zhoujing101 Description: ## **1. 合入背景** 本次改动提供一套面向 examples/deployer/deploy.py 的云原生部署方式。它的目标是让部署过程不再依赖人工登录宿主机,也不依赖宿主机上的本地配置文件,而是能够被云平台直接触发。来自真实的云厂商部署需求,在内部平台已验证。 项目原始部署方式默认由运维人员登录某个 Kubernetes 节点,手工执行 examples/deployer/deploy.py,并从本地目录读取配置文件。 这种方式适合开发调试和人工验证,但在云平台场景下会遇到明显问题: * 集群通常是多租户的,同一集群内会并行部署多个推理服务,并通过 namespace 做隔离。 * 云平台用户不应被要求拥有节点登录权限。 * 部署请求通常来自平台控制面或 API,而不是人工在宿主机执行脚本。 * 交付物应该是容器镜像和 Kubernetes 清单,而不是依赖宿主机本地状态。 * 扩缩容、清理等动作也应该被表达为 Kubernetes Job,便于平台统一审计、重试和观测。 因此,这里把现有的部署逻辑封装成了适合容器执行的形式。对云平台而言,只需要两步: 1. 准备一个包含 user_config.json 和 env.json 的 ConfigMap。 2. 创建对应的 deploy / scale / cleanup Job。 底层真正执行部署的仍然是现有的 examples/deployer/deploy.py,这样可以保持与当前人工部署行为一致,同时把入口改造成云原生形态。示意如图:  Fixes https://gitcode.com/Ascend/MindIE-PyMotor/issues/345 ## **2. 修改内容** 本次仅涉及 deployer 部分。 1. 新增 examples/cloud_native_deploy 云原生部署目录,补齐 deployer 镜像 Dockerfile、deploy/scale/cleanup 入口脚本,以及对应的 Kubernetes Job、RBAC 和配置清单;同时将 user_config.json 与 env.json 统一封装进同一个 ConfigMap,并在 Job 中映射为容器内配置文件,使云平台可以通过 “ConfigMap + Job” 方式直接触发部署、扩缩容和清理,而不再依赖人工登录宿主机。 2. 在 user_config.json 中新增 scheduling_queue、coordinator_service_name、prefill_node_selector 和 decode_node_selector 等配置 3. 调整云原生 cleanup 逻辑,使用独立 cleanup.sh 按 namespace 清理集群资源,而不是依赖宿主机上的 output_yamls 4. 修正多服务并存时的 RBAC 冲突问题:保留共享的 ClusterRole,将生成出来的 ClusterRoleBinding 改为按 namespace 唯一化,并让 cleanup 只删除当前 namespace 对应的 binding,不再删除共享的 ClusterRole 5. 新增根目录 Makefile,统一提供 wheel 构建、云原生 deployer 镜像本地构建和 buildx 多架构推送入口,默认镜像仓库为 Docker Hub(在另一个 PR 提交)。 6. 新增 helm 部署,通过 helm install 一键部署,更符合云原生组件的部署规范 ## **3. 资料变更** 涉及部署方式变更,已描述 ## **4. 接口变更** 涉及 user_config.json 变更 ## **5. 测试结果** > 需体现<ins>**测试场景,测试方法以及测试结果**</ins>。\ > 测试用例设计时需考虑硬件、部署方式、功能、性能、精度、显存等维度。 ## **6. CheckList** > PR提交人对以下CheckList自检项进行全量自检,自检通过或不涉及,均修改 [ ] 为 [x] [ ] 代码注释完备 [ ] 正确记录维测日志 [ ] 是否有UT用例 [ ] 若涉及多线程场景,考虑了并发场景,不存在死锁问题 See merge request: Ascend/MindIE-PyMotor!67 | 20 天前 | |
[Feature] 增加云原生部署器 Co-authored-by: sceneryback<afterbreeze@hotmail.com> # message auto-generated for no-merge-commit merge: !67 merge feature/add-deployer into master [Feature] 增加云原生部署器 Created-by: gcw_gxG14I7x Commit-by: sceneryback Merged-by: zhoujing101 Description: ## **1. 合入背景** 本次改动提供一套面向 examples/deployer/deploy.py 的云原生部署方式。它的目标是让部署过程不再依赖人工登录宿主机,也不依赖宿主机上的本地配置文件,而是能够被云平台直接触发。来自真实的云厂商部署需求,在内部平台已验证。 项目原始部署方式默认由运维人员登录某个 Kubernetes 节点,手工执行 examples/deployer/deploy.py,并从本地目录读取配置文件。 这种方式适合开发调试和人工验证,但在云平台场景下会遇到明显问题: * 集群通常是多租户的,同一集群内会并行部署多个推理服务,并通过 namespace 做隔离。 * 云平台用户不应被要求拥有节点登录权限。 * 部署请求通常来自平台控制面或 API,而不是人工在宿主机执行脚本。 * 交付物应该是容器镜像和 Kubernetes 清单,而不是依赖宿主机本地状态。 * 扩缩容、清理等动作也应该被表达为 Kubernetes Job,便于平台统一审计、重试和观测。 因此,这里把现有的部署逻辑封装成了适合容器执行的形式。对云平台而言,只需要两步: 1. 准备一个包含 user_config.json 和 env.json 的 ConfigMap。 2. 创建对应的 deploy / scale / cleanup Job。 底层真正执行部署的仍然是现有的 examples/deployer/deploy.py,这样可以保持与当前人工部署行为一致,同时把入口改造成云原生形态。示意如图:  Fixes https://gitcode.com/Ascend/MindIE-PyMotor/issues/345 ## **2. 修改内容** 本次仅涉及 deployer 部分。 1. 新增 examples/cloud_native_deploy 云原生部署目录,补齐 deployer 镜像 Dockerfile、deploy/scale/cleanup 入口脚本,以及对应的 Kubernetes Job、RBAC 和配置清单;同时将 user_config.json 与 env.json 统一封装进同一个 ConfigMap,并在 Job 中映射为容器内配置文件,使云平台可以通过 “ConfigMap + Job” 方式直接触发部署、扩缩容和清理,而不再依赖人工登录宿主机。 2. 在 user_config.json 中新增 scheduling_queue、coordinator_service_name、prefill_node_selector 和 decode_node_selector 等配置 3. 调整云原生 cleanup 逻辑,使用独立 cleanup.sh 按 namespace 清理集群资源,而不是依赖宿主机上的 output_yamls 4. 修正多服务并存时的 RBAC 冲突问题:保留共享的 ClusterRole,将生成出来的 ClusterRoleBinding 改为按 namespace 唯一化,并让 cleanup 只删除当前 namespace 对应的 binding,不再删除共享的 ClusterRole 5. 新增根目录 Makefile,统一提供 wheel 构建、云原生 deployer 镜像本地构建和 buildx 多架构推送入口,默认镜像仓库为 Docker Hub(在另一个 PR 提交)。 6. 新增 helm 部署,通过 helm install 一键部署,更符合云原生组件的部署规范 ## **3. 资料变更** 涉及部署方式变更,已描述 ## **4. 接口变更** 涉及 user_config.json 变更 ## **5. 测试结果** > 需体现<ins>**测试场景,测试方法以及测试结果**</ins>。\ > 测试用例设计时需考虑硬件、部署方式、功能、性能、精度、显存等维度。 ## **6. CheckList** > PR提交人对以下CheckList自检项进行全量自检,自检通过或不涉及,均修改 [ ] 为 [x] [ ] 代码注释完备 [ ] 正确记录维测日志 [ ] 是否有UT用例 [ ] 若涉及多线程场景,考虑了并发场景,不存在死锁问题 See merge request: Ascend/MindIE-PyMotor!67 | 20 天前 | |
[Feature] 增加云原生部署器 Co-authored-by: sceneryback<afterbreeze@hotmail.com> # message auto-generated for no-merge-commit merge: !67 merge feature/add-deployer into master [Feature] 增加云原生部署器 Created-by: gcw_gxG14I7x Commit-by: sceneryback Merged-by: zhoujing101 Description: ## **1. 合入背景** 本次改动提供一套面向 examples/deployer/deploy.py 的云原生部署方式。它的目标是让部署过程不再依赖人工登录宿主机,也不依赖宿主机上的本地配置文件,而是能够被云平台直接触发。来自真实的云厂商部署需求,在内部平台已验证。 项目原始部署方式默认由运维人员登录某个 Kubernetes 节点,手工执行 examples/deployer/deploy.py,并从本地目录读取配置文件。 这种方式适合开发调试和人工验证,但在云平台场景下会遇到明显问题: * 集群通常是多租户的,同一集群内会并行部署多个推理服务,并通过 namespace 做隔离。 * 云平台用户不应被要求拥有节点登录权限。 * 部署请求通常来自平台控制面或 API,而不是人工在宿主机执行脚本。 * 交付物应该是容器镜像和 Kubernetes 清单,而不是依赖宿主机本地状态。 * 扩缩容、清理等动作也应该被表达为 Kubernetes Job,便于平台统一审计、重试和观测。 因此,这里把现有的部署逻辑封装成了适合容器执行的形式。对云平台而言,只需要两步: 1. 准备一个包含 user_config.json 和 env.json 的 ConfigMap。 2. 创建对应的 deploy / scale / cleanup Job。 底层真正执行部署的仍然是现有的 examples/deployer/deploy.py,这样可以保持与当前人工部署行为一致,同时把入口改造成云原生形态。示意如图:  Fixes https://gitcode.com/Ascend/MindIE-PyMotor/issues/345 ## **2. 修改内容** 本次仅涉及 deployer 部分。 1. 新增 examples/cloud_native_deploy 云原生部署目录,补齐 deployer 镜像 Dockerfile、deploy/scale/cleanup 入口脚本,以及对应的 Kubernetes Job、RBAC 和配置清单;同时将 user_config.json 与 env.json 统一封装进同一个 ConfigMap,并在 Job 中映射为容器内配置文件,使云平台可以通过 “ConfigMap + Job” 方式直接触发部署、扩缩容和清理,而不再依赖人工登录宿主机。 2. 在 user_config.json 中新增 scheduling_queue、coordinator_service_name、prefill_node_selector 和 decode_node_selector 等配置 3. 调整云原生 cleanup 逻辑,使用独立 cleanup.sh 按 namespace 清理集群资源,而不是依赖宿主机上的 output_yamls 4. 修正多服务并存时的 RBAC 冲突问题:保留共享的 ClusterRole,将生成出来的 ClusterRoleBinding 改为按 namespace 唯一化,并让 cleanup 只删除当前 namespace 对应的 binding,不再删除共享的 ClusterRole 5. 新增根目录 Makefile,统一提供 wheel 构建、云原生 deployer 镜像本地构建和 buildx 多架构推送入口,默认镜像仓库为 Docker Hub(在另一个 PR 提交)。 6. 新增 helm 部署,通过 helm install 一键部署,更符合云原生组件的部署规范 ## **3. 资料变更** 涉及部署方式变更,已描述 ## **4. 接口变更** 涉及 user_config.json 变更 ## **5. 测试结果** > 需体现<ins>**测试场景,测试方法以及测试结果**</ins>。\ > 测试用例设计时需考虑硬件、部署方式、功能、性能、精度、显存等维度。 ## **6. CheckList** > PR提交人对以下CheckList自检项进行全量自检,自检通过或不涉及,均修改 [ ] 为 [x] [ ] 代码注释完备 [ ] 正确记录维测日志 [ ] 是否有UT用例 [ ] 若涉及多线程场景,考虑了并发场景,不存在死锁问题 See merge request: Ascend/MindIE-PyMotor!67 | 20 天前 | |
[Feature] 增加云原生部署器 Co-authored-by: sceneryback<afterbreeze@hotmail.com> # message auto-generated for no-merge-commit merge: !67 merge feature/add-deployer into master [Feature] 增加云原生部署器 Created-by: gcw_gxG14I7x Commit-by: sceneryback Merged-by: zhoujing101 Description: ## **1. 合入背景** 本次改动提供一套面向 examples/deployer/deploy.py 的云原生部署方式。它的目标是让部署过程不再依赖人工登录宿主机,也不依赖宿主机上的本地配置文件,而是能够被云平台直接触发。来自真实的云厂商部署需求,在内部平台已验证。 项目原始部署方式默认由运维人员登录某个 Kubernetes 节点,手工执行 examples/deployer/deploy.py,并从本地目录读取配置文件。 这种方式适合开发调试和人工验证,但在云平台场景下会遇到明显问题: * 集群通常是多租户的,同一集群内会并行部署多个推理服务,并通过 namespace 做隔离。 * 云平台用户不应被要求拥有节点登录权限。 * 部署请求通常来自平台控制面或 API,而不是人工在宿主机执行脚本。 * 交付物应该是容器镜像和 Kubernetes 清单,而不是依赖宿主机本地状态。 * 扩缩容、清理等动作也应该被表达为 Kubernetes Job,便于平台统一审计、重试和观测。 因此,这里把现有的部署逻辑封装成了适合容器执行的形式。对云平台而言,只需要两步: 1. 准备一个包含 user_config.json 和 env.json 的 ConfigMap。 2. 创建对应的 deploy / scale / cleanup Job。 底层真正执行部署的仍然是现有的 examples/deployer/deploy.py,这样可以保持与当前人工部署行为一致,同时把入口改造成云原生形态。示意如图:  Fixes https://gitcode.com/Ascend/MindIE-PyMotor/issues/345 ## **2. 修改内容** 本次仅涉及 deployer 部分。 1. 新增 examples/cloud_native_deploy 云原生部署目录,补齐 deployer 镜像 Dockerfile、deploy/scale/cleanup 入口脚本,以及对应的 Kubernetes Job、RBAC 和配置清单;同时将 user_config.json 与 env.json 统一封装进同一个 ConfigMap,并在 Job 中映射为容器内配置文件,使云平台可以通过 “ConfigMap + Job” 方式直接触发部署、扩缩容和清理,而不再依赖人工登录宿主机。 2. 在 user_config.json 中新增 scheduling_queue、coordinator_service_name、prefill_node_selector 和 decode_node_selector 等配置 3. 调整云原生 cleanup 逻辑,使用独立 cleanup.sh 按 namespace 清理集群资源,而不是依赖宿主机上的 output_yamls 4. 修正多服务并存时的 RBAC 冲突问题:保留共享的 ClusterRole,将生成出来的 ClusterRoleBinding 改为按 namespace 唯一化,并让 cleanup 只删除当前 namespace 对应的 binding,不再删除共享的 ClusterRole 5. 新增根目录 Makefile,统一提供 wheel 构建、云原生 deployer 镜像本地构建和 buildx 多架构推送入口,默认镜像仓库为 Docker Hub(在另一个 PR 提交)。 6. 新增 helm 部署,通过 helm install 一键部署,更符合云原生组件的部署规范 ## **3. 资料变更** 涉及部署方式变更,已描述 ## **4. 接口变更** 涉及 user_config.json 变更 ## **5. 测试结果** > 需体现<ins>**测试场景,测试方法以及测试结果**</ins>。\ > 测试用例设计时需考虑硬件、部署方式、功能、性能、精度、显存等维度。 ## **6. CheckList** > PR提交人对以下CheckList自检项进行全量自检,自检通过或不涉及,均修改 [ ] 为 [x] [ ] 代码注释完备 [ ] 正确记录维测日志 [ ] 是否有UT用例 [ ] 若涉及多线程场景,考虑了并发场景,不存在死锁问题 See merge request: Ascend/MindIE-PyMotor!67 | 20 天前 | |
[Feature] 增加云原生部署器 Co-authored-by: sceneryback<afterbreeze@hotmail.com> # message auto-generated for no-merge-commit merge: !67 merge feature/add-deployer into master [Feature] 增加云原生部署器 Created-by: gcw_gxG14I7x Commit-by: sceneryback Merged-by: zhoujing101 Description: ## **1. 合入背景** 本次改动提供一套面向 examples/deployer/deploy.py 的云原生部署方式。它的目标是让部署过程不再依赖人工登录宿主机,也不依赖宿主机上的本地配置文件,而是能够被云平台直接触发。来自真实的云厂商部署需求,在内部平台已验证。 项目原始部署方式默认由运维人员登录某个 Kubernetes 节点,手工执行 examples/deployer/deploy.py,并从本地目录读取配置文件。 这种方式适合开发调试和人工验证,但在云平台场景下会遇到明显问题: * 集群通常是多租户的,同一集群内会并行部署多个推理服务,并通过 namespace 做隔离。 * 云平台用户不应被要求拥有节点登录权限。 * 部署请求通常来自平台控制面或 API,而不是人工在宿主机执行脚本。 * 交付物应该是容器镜像和 Kubernetes 清单,而不是依赖宿主机本地状态。 * 扩缩容、清理等动作也应该被表达为 Kubernetes Job,便于平台统一审计、重试和观测。 因此,这里把现有的部署逻辑封装成了适合容器执行的形式。对云平台而言,只需要两步: 1. 准备一个包含 user_config.json 和 env.json 的 ConfigMap。 2. 创建对应的 deploy / scale / cleanup Job。 底层真正执行部署的仍然是现有的 examples/deployer/deploy.py,这样可以保持与当前人工部署行为一致,同时把入口改造成云原生形态。示意如图:  Fixes https://gitcode.com/Ascend/MindIE-PyMotor/issues/345 ## **2. 修改内容** 本次仅涉及 deployer 部分。 1. 新增 examples/cloud_native_deploy 云原生部署目录,补齐 deployer 镜像 Dockerfile、deploy/scale/cleanup 入口脚本,以及对应的 Kubernetes Job、RBAC 和配置清单;同时将 user_config.json 与 env.json 统一封装进同一个 ConfigMap,并在 Job 中映射为容器内配置文件,使云平台可以通过 “ConfigMap + Job” 方式直接触发部署、扩缩容和清理,而不再依赖人工登录宿主机。 2. 在 user_config.json 中新增 scheduling_queue、coordinator_service_name、prefill_node_selector 和 decode_node_selector 等配置 3. 调整云原生 cleanup 逻辑,使用独立 cleanup.sh 按 namespace 清理集群资源,而不是依赖宿主机上的 output_yamls 4. 修正多服务并存时的 RBAC 冲突问题:保留共享的 ClusterRole,将生成出来的 ClusterRoleBinding 改为按 namespace 唯一化,并让 cleanup 只删除当前 namespace 对应的 binding,不再删除共享的 ClusterRole 5. 新增根目录 Makefile,统一提供 wheel 构建、云原生 deployer 镜像本地构建和 buildx 多架构推送入口,默认镜像仓库为 Docker Hub(在另一个 PR 提交)。 6. 新增 helm 部署,通过 helm install 一键部署,更符合云原生组件的部署规范 ## **3. 资料变更** 涉及部署方式变更,已描述 ## **4. 接口变更** 涉及 user_config.json 变更 ## **5. 测试结果** > 需体现<ins>**测试场景,测试方法以及测试结果**</ins>。\ > 测试用例设计时需考虑硬件、部署方式、功能、性能、精度、显存等维度。 ## **6. CheckList** > PR提交人对以下CheckList自检项进行全量自检,自检通过或不涉及,均修改 [ ] 为 [x] [ ] 代码注释完备 [ ] 正确记录维测日志 [ ] 是否有UT用例 [ ] 若涉及多线程场景,考虑了并发场景,不存在死锁问题 See merge request: Ascend/MindIE-PyMotor!67 | 20 天前 | |
[Feature] 增加云原生部署器 Co-authored-by: sceneryback<afterbreeze@hotmail.com> # message auto-generated for no-merge-commit merge: !67 merge feature/add-deployer into master [Feature] 增加云原生部署器 Created-by: gcw_gxG14I7x Commit-by: sceneryback Merged-by: zhoujing101 Description: ## **1. 合入背景** 本次改动提供一套面向 examples/deployer/deploy.py 的云原生部署方式。它的目标是让部署过程不再依赖人工登录宿主机,也不依赖宿主机上的本地配置文件,而是能够被云平台直接触发。来自真实的云厂商部署需求,在内部平台已验证。 项目原始部署方式默认由运维人员登录某个 Kubernetes 节点,手工执行 examples/deployer/deploy.py,并从本地目录读取配置文件。 这种方式适合开发调试和人工验证,但在云平台场景下会遇到明显问题: * 集群通常是多租户的,同一集群内会并行部署多个推理服务,并通过 namespace 做隔离。 * 云平台用户不应被要求拥有节点登录权限。 * 部署请求通常来自平台控制面或 API,而不是人工在宿主机执行脚本。 * 交付物应该是容器镜像和 Kubernetes 清单,而不是依赖宿主机本地状态。 * 扩缩容、清理等动作也应该被表达为 Kubernetes Job,便于平台统一审计、重试和观测。 因此,这里把现有的部署逻辑封装成了适合容器执行的形式。对云平台而言,只需要两步: 1. 准备一个包含 user_config.json 和 env.json 的 ConfigMap。 2. 创建对应的 deploy / scale / cleanup Job。 底层真正执行部署的仍然是现有的 examples/deployer/deploy.py,这样可以保持与当前人工部署行为一致,同时把入口改造成云原生形态。示意如图:  Fixes https://gitcode.com/Ascend/MindIE-PyMotor/issues/345 ## **2. 修改内容** 本次仅涉及 deployer 部分。 1. 新增 examples/cloud_native_deploy 云原生部署目录,补齐 deployer 镜像 Dockerfile、deploy/scale/cleanup 入口脚本,以及对应的 Kubernetes Job、RBAC 和配置清单;同时将 user_config.json 与 env.json 统一封装进同一个 ConfigMap,并在 Job 中映射为容器内配置文件,使云平台可以通过 “ConfigMap + Job” 方式直接触发部署、扩缩容和清理,而不再依赖人工登录宿主机。 2. 在 user_config.json 中新增 scheduling_queue、coordinator_service_name、prefill_node_selector 和 decode_node_selector 等配置 3. 调整云原生 cleanup 逻辑,使用独立 cleanup.sh 按 namespace 清理集群资源,而不是依赖宿主机上的 output_yamls 4. 修正多服务并存时的 RBAC 冲突问题:保留共享的 ClusterRole,将生成出来的 ClusterRoleBinding 改为按 namespace 唯一化,并让 cleanup 只删除当前 namespace 对应的 binding,不再删除共享的 ClusterRole 5. 新增根目录 Makefile,统一提供 wheel 构建、云原生 deployer 镜像本地构建和 buildx 多架构推送入口,默认镜像仓库为 Docker Hub(在另一个 PR 提交)。 6. 新增 helm 部署,通过 helm install 一键部署,更符合云原生组件的部署规范 ## **3. 资料变更** 涉及部署方式变更,已描述 ## **4. 接口变更** 涉及 user_config.json 变更 ## **5. 测试结果** > 需体现<ins>**测试场景,测试方法以及测试结果**</ins>。\ > 测试用例设计时需考虑硬件、部署方式、功能、性能、精度、显存等维度。 ## **6. CheckList** > PR提交人对以下CheckList自检项进行全量自检,自检通过或不涉及,均修改 [ ] 为 [x] [ ] 代码注释完备 [ ] 正确记录维测日志 [ ] 是否有UT用例 [ ] 若涉及多线程场景,考虑了并发场景,不存在死锁问题 See merge request: Ascend/MindIE-PyMotor!67 | 20 天前 |
MindIE PyMotor 云原生部署 Helm Chart
该 Chart 将 examples/cloud_native_deploy 中的部署入口封装为 Helm 操作,支持部署、扩缩容和清理。
Chart 只管理以下资源:
- 包含
user_config.json和env.json的 ConfigMap。 - deployer 使用的 ServiceAccount、ClusterRole 和 ClusterRoleBinding。
- 执行
deploy.py的 deploy / scale / cleanup Job。
Controller、Coordinator、Engine、KV Pool 和 KV Conductor 等运行时资源仍由 deployer Job 动态生成。
准备
-
构建并推送 deployer 镜像:
docker build -f examples/cloud_native_deploy/Dockerfile \ -t example.com/team/mindie-pymotor-deployer:latest . docker push example.com/team/mindie-pymotor-deployer:latest -
复制
values.yaml并修改:cp examples/cloud_native_deploy/helm/values.yaml /tmp/pymotor-values.yaml必须按实际环境设置:
image.repository和image.tag:deployer 镜像。userConfigJSON 字符串中的motor_deploy_config.image_name:运行 Controller、Coordinator 和 Engine 的 Motor 镜像。job_id、模型路径、实例数、NPU 数量和硬件类型。- 按需修改
userConfigJSON 字符串中的coordinator_infer_node_port和各组件*_node_selector。
部署
helm upgrade --install pymotor examples/cloud_native_deploy/helm \
--namespace mindie \
--create-namespace \
--values /tmp/pymotor-values.yaml \
--set operation=deploy
查看 Job 和日志:
kubectl get jobs -n mindie
kubectl logs job/pymotor-mindie-pymotor-deployer-deploy -n mindie
扩缩容
修改 /tmp/pymotor-values.yaml 中的实例数后执行:
helm upgrade pymotor examples/cloud_native_deploy/helm \
--namespace mindie \
--values /tmp/pymotor-values.yaml \
--set operation=scale
清理
先运行 cleanup Job 删除 deployer 动态创建的资源,再卸载 Helm release:
helm upgrade pymotor examples/cloud_native_deploy/helm \
--namespace mindie \
--values /tmp/pymotor-values.yaml \
--set operation=cleanup
helm uninstall pymotor --namespace mindie
注意
当前 cleanup 脚本会删除 userConfig.motor_deploy_config.job_id 对应 namespace 中的 Deployment 和 Service。请为每套服务使用独立 namespace,并在执行前确认 namespace。
operation
| 取值 | 行为 |
|---|---|
deploy |
执行完整部署。 |
scale |
根据当前配置执行实例扩缩容。 |
cleanup |
清理目标 namespace 中由部署流程使用的资源。 |
三个 Job 均使用 Helm post-install,post-upgrade hook,并通过 before-hook-creation 在重复执行前清理同名旧 Job。