ZenML Pro Workspace Server 快照Workload Manager支持配置指南【免费下载链接】zenmlZenML : One AI Platform from Pipelines to Agents. https://zenml.io.项目地址: https://gitcode.com/GitHub_Trending/ze/zenml本篇技术指南讲解如何为自托管self-hosted的 ZenML Pro Workspace Server 启用 SnapshotWorkload Manager支持使流水线能够直接从 ZenML Pro UI 运行。你将掌握 Workload Manager 的两种实现Kubernetes / AWS、三种 runner 镜像管理方案、完整的 Helm 环境变量配置与 Kubernetes RBAC 权限拆分方法并了解 ZenML 开源仓库中对应的接口与执行链路实现。概述从 UI 直接运行快照Workspace Server 内置了Workload Manager特性它允许你在 ZenML Pro UI 中直接运行流水线快照Snapshot而不必依赖本地 CLI 或 SDK 环境。该特性的本质是Workload Manager 会在一个可访问的 Kubernetes 集群中创建临时ad-hoc的流水线 runner Pod/Job由这些 Job 以与 CLI/SDK 相同的方式启动流水线。启用该功能有两个硬性前提来自原文档的警告提示Snapshot 支持仅从ZenML Pro Workspace Server 0.90.0 版本起可用Snapshot 支持仅适用于部署在 Kubernetes 上的 Workspace Server部署在 AWS ECS 或其他平台的 Workspace Server 目前不受支持。从源码看Workload Manager 的启用与否由服务端配置字段workload_manager_implementation_source决定该字段非空时server_config.py 中的workload_manager_enabled属性返回True而runs_endpoints.py、pipeline_snapshot_endpoints.py、run_templates_endpoints.py等路由会据此开放对应的快照运行能力。前置条件在开始配置前需要满足以下基础要求一个可从 Workspace Server 访问的Kubernetes 集群1.24为 runner Pod 准备的专用命名空间namespace具备创建/管理 Pod 权限的服务账号Service Account与 RBAC 权限为服务账号配置的镜像拉取密钥image pull secrets。理解 Workload Manager 子特性从 UI 运行流水线依赖运行 Kubernetes Job即 runner Job这些 Job 与从 CLI/SDK 运行流水线的方式一致。由于这些 Job 需要携带正确 Python 包依赖的容器镜像才能启动流水线你需要根据实际需求选择以下三种 runner 镜像来源之一复用快照容器镜像Reuse snapshot container images直接复用运行快照时为该快照构建的流水线容器镜像。这要求 runner Job 拥有所有存储这些镜像的容器注册表即 ZenML Stack 中使用的 Container Registries的拉取权限。此方案仅能运行与包含同一容器注册表的 Stack 关联的快照。按需构建 runner 镜像Build on-demandWorkspace Server 在需要时会启动额外的 Kubernetes Job 来构建 runner 镜像并推送到已配置的容器注册表。这要求 builder Kubernetes Job 拥有向私有容器注册表推送的权限同时 runner Job 拥有从同一注册表拉取的权限。这是最灵活的方案可以运行与任意 Stack、任意集成关联的快照。使用预构建 runner 镜像Pre-built image为所有运行提供一个预先构建好的单一 runner 镜像存储在你自己的容器注册表中。这是最简单、最快的方案但你需要自行确保镜像中包含正确的 Python 包依赖。此方案限制最大要求预先构建包含所有可能 Stack 与集成依赖的容器镜像。外部日志存储Store logs externally默认情况下ZenML Pro UI 中展示的日志从 runner Job Pod 中提取。由于 Pod 可能消失你可以配置外部日志存储。目前仅 AWS 实现支持外部日志。启用后需要配置日志存放的 S3 bucket 与 region并授予 ZenML Pro Workspace Server Pod 对该 bucket 的写权限。两种 Workload Manager 实现Kubernetes在与 ZenML Pro Workspace Server 相同的 Kubernetes 集群中运行流水线AWS在 Kubernetes 实现的基础上扩展支持向 AWS ECR 构建/推送镜像并将日志存储到 AWS S3。源码中的接口设计在开源仓库中Workload Manager 的行为被抽象为WorkloadManagerInterface见 workload_manager_interface.py核心方法包括run()在容器中运行命令对应启动 runner 流水线build_and_push_image()构建并推送 Docker 镜像对应按需构建 runner 镜像delete_workload()删除工作负载get_logs()获取工作负载日志log()写入工作负载日志消息。同时定义了WorkloadType枚举SNAPSHOT与RUN用于区分工作负载对应的实体类型。仓库内置的 in_memory_workload_manager.py 是一个通过subprocess在服务器本机直接运行的InMemoryWorkloadManager实现而文档中提到的zenml_cloud_plugins.kubernetes_workload_manager.KubernetesWorkloadManager与zenml_cloud_plugins.aws_kubernetes_workload_manager.AWSKubernetesWorkloadManager则来自 ZenML Pro 的云插件包zenml_cloud_plugins不在本开源仓库内。服务端启动时会调用initialize_workload_manager()见 zen_server_api.py其逻辑位于 utils.py读取server_config().workload_manager_implementation_source配置通过source_utils.load_and_validate_class加载并校验实现类实例化后存入全局单例供后续调用。若实现类无法加载只会记录警告而不会导致服务启动失败。第一步为 Workload Manager 创建 Kubernetes 资源创建一个专用的命名空间和服务账号用于启动 runner Job# 创建命名空间 kubectl create namespace zenml-workload-manager # 创建服务账号 kubectl -n zenml-workload-manager create serviceaccount zenml-workload-manager第二步选择 Workload Manager 实现你的实现选择决定了需要在 ZenML Workspace Server Helm 部署中额外配置的环境变量。Option AKubernetes 实现基础版提供通用的 Kubernetes 功能来运行快照server: environment: ZENML_SERVER_WORKLOAD_MANAGER_IMPLEMENTATION_SOURCE: zenml_cloud_plugins.kubernetes_workload_manager.KubernetesWorkloadManager ZENML_KUBERNETES_WORKLOAD_MANAGER_NAMESPACE: zenml-workload-manager ZENML_KUBERNETES_WORKLOAD_MANAGER_SERVICE_ACCOUNT: zenml-workload-managerOption BAWS 实现在 Kubernetes 基础上提供 AWS 特有能力包括外部 S3 日志与 ECR 集成server: environment: ZENML_SERVER_WORKLOAD_MANAGER_IMPLEMENTATION_SOURCE: zenml_cloud_plugins.aws_kubernetes_workload_manager.AWSKubernetesWorkloadManager ZENML_KUBERNETES_WORKLOAD_MANAGER_NAMESPACE: zenml-workload-manager ZENML_KUBERNETES_WORKLOAD_MANAGER_SERVICE_ACCOUNT: zenml-workload-manager ZENML_AWS_KUBERNETES_WORKLOAD_MANAGER_REGION: eu-central-1 # 如需将日志外部存储到 S3还需要设置以下环境变量 ZENML_KUBERNETES_WORKLOAD_MANAGER_ENABLE_EXTERNAL_LOGS: true ZENML_AWS_KUBERNETES_WORKLOAD_MANAGER_BUCKET: s3://my-bucket/run-template-logs第三步配置 Runner 镜像来源根据你对 runner 镜像的管理方式在 Workspace Server Helm 部署中配置相应环境变量Option 1复用快照容器镜像server: environment: ZENML_KUBERNETES_WORKLOAD_MANAGER_BUILD_RUNNER_IMAGE: false # 保持为空或不设置该变量即可复用快照容器镜像 # ZENML_KUBERNETES_WORKLOAD_MANAGER_RUNNER_IMAGE:Option 2由 ZenML 构建 Runner 镜像按需构建server: environment: ZENML_KUBERNETES_WORKLOAD_MANAGER_BUILD_RUNNER_IMAGE: true ZENML_KUBERNETES_WORKLOAD_MANAGER_DOCKER_REGISTRY: internal-registry.mycompany.com/zenmlOption 3使用预构建的 Runner 镜像server: environment: ZENML_KUBERNETES_WORKLOAD_MANAGER_BUILD_RUNNER_IMAGE: false ZENML_KUBERNETES_WORKLOAD_MANAGER_RUNNER_IMAGE: internal-registry.mycompany.com/zenml/zenml:ZENML_OSS_VERSION源码中的镜像与执行细节从源码可以更直观地理解这些配置背后的执行逻辑。在 utils.py 的_build_and_run()函数中整个快照运行流程为根据 stack 与 build 信息生成 Dockerfilebuild_runner_dockerfile()→generate_dockerfile()见同文件 L1116-L1148。生成的 Dockerfile 以zenmldocker/zenml:{zenml_version}-py{python_version}作为父镜像可通过ENV_ZENML_RUNNER_PARENT_IMAGE环境变量覆盖随后安装 stack 所需的 APT 包与 PyPI 依赖默认通过uv安装基于 Dockerfile 内容计算 MD5 哈希generate_image_hash()以zenml-runner:{image_hash}作为镜像名调用workload_manager().build_and_push_image()构建并推送 runner 镜像写入 Starting pipeline run. 日志随后以ENV_ZENML_RUNNER_POD_TIMEOUT默认 180 秒作为超时调用workload_manager().run()启动 runner 工作负载。runner 工作负载通过build_runner_environment()同文件 L1066-L1113注入环境包括ZENML_STORE_URL服务器地址、ZENML_STORE_TYPEREST、ZENML_STORE_API_TOKEN一个永不过期、作用域限定到该流水线运行的 API token由generate_access_token生成以及ZENML_STORE_VERIFY_SSLTrue。runner 启动后便以 REST 客户端身份回连 Workspace Server 执行流水线。第四步配置权限运行 ZenML Workspace Server 的 Kubernetes 服务账号需要额外权限在第一步设置的 workload manager 命名空间中创建和管理 Job 的权限如果使用 AWS 实现且启用了外部 S3 日志还需要向所配置 S3 bucket 写入的权限。第一步设置的 workload manager Kubernetes 服务账号还需要以下容器注册表权限从存储 runner 镜像的容器注册表拉取镜像的权限如果选择按需构建 runner 镜像还需要向 runner 镜像目标注册表推送镜像的权限。授予这些权限有多种方式授予整个集群对容器注册表的访问权限使用隐式工作负载身份访问容器注册表——大多数云厂商支持通过授予 Kubernetes 服务账号对容器注册表的访问权限来实现配置一个对容器注册表具有隐式访问权限的服务账号——将某个云服务身份例如 GCP 服务账号、AWS IAM 角色等与 Kubernetes 服务账号关联为服务账号配置镜像拉取密钥image pull secret——与上一种方式类似但使用 Kubernetes Secret 而非云服务身份。推荐的权限最小化拆分least-privilege split建议为以下两种身份使用独立的服务账号运行 Workspace Server Pod 的服务账号ZENML_KUBERNETES_WORKLOAD_MANAGER_SERVICE_ACCOUNT中为 runner/builder Job 配置的服务账号。Workspace Server 服务账号的 RBAC位于 workload manager 命名空间内Workspace Server 负责创建、监控、清理 workload manager Job并抓取 Pod 日志。需要授予batch/jobscreate、get、deletecollectioncore/podslistcore/pods/logget这与源码中 Workload Manager 的日志获取路径相互印证runs_endpoints.py会调用workload_manager().get_logs()提取 runner 日志并合并到流水线运行的日志集合中见 runs_endpoints.py。Workload manager runner/builder 服务账号由 workload manager 启动的 runner/builder Job 本身不需要对 workload manager 控制回路的 Kubernetes API 权限。该账号主要需要对 runner 镜像的容器注册表拉取权限如果启用了按需构建则需要容器注册表推送权限工作负载实现所需的可选云权限例如启用 AWS 外部日志时的 S3 写权限。环境变量参考Workload Manager 配置支持的全部环境变量如下变量是否必需说明ZENML_SERVER_WORKLOAD_MANAGER_IMPLEMENTATION_SOURCE是实现类见上方两种实现选项ZENML_KUBERNETES_WORKLOAD_MANAGER_NAMESPACE是runner Job 所在的 Kubernetes 命名空间ZENML_KUBERNETES_WORKLOAD_MANAGER_SERVICE_ACCOUNT是runner Job 使用的 Kubernetes 服务账号ZENML_KUBERNETES_WORKLOAD_MANAGER_BUILD_RUNNER_IMAGE否是否构建 runner 镜像默认falseZENML_KUBERNETES_WORKLOAD_MANAGER_DOCKER_REGISTRY条件必需runner 镜像所在的注册表构建镜像时必需ZENML_KUBERNETES_WORKLOAD_MANAGER_RUNNER_IMAGE否预构建的 runner 镜像不构建时使用ZENML_KUBERNETES_WORKLOAD_MANAGER_ENABLE_EXTERNAL_LOGS否是否外部存储日志默认false仅 AWSZENML_KUBERNETES_WORKLOAD_MANAGER_POD_RESOURCES否Pod 资源限制JSON 格式ZENML_KUBERNETES_WORKLOAD_MANAGER_TTL_SECONDS_AFTER_FINISHED否已完成 Job 的清理时间默认2 天ZENML_KUBERNETES_WORKLOAD_MANAGER_NODE_SELECTOR否节点选择器JSON 格式ZENML_KUBERNETES_WORKLOAD_MANAGER_TOLERATIONS否容忍度JSON 格式ZENML_KUBERNETES_WORKLOAD_MANAGER_JOB_BACKOFF_LIMIT否builder/runner Job 的重试上限ZENML_KUBERNETES_WORKLOAD_MANAGER_POD_FAILURE_POLICY否builder/runner Job 的 Pod 失败策略ZENML_SERVER_MAX_CONCURRENT_TEMPLATE_RUNS否每个 Pod 的最大并发快照运行数默认2AWS 特有变量变量是否必需说明ZENML_AWS_KUBERNETES_WORKLOAD_MANAGER_BUCKET条件必需日志存储的 S3 bucket启用外部日志时必需ZENML_AWS_KUBERNETES_WORKLOAD_MANAGER_REGION条件必需AWS 区域构建镜像时必需完整配置示例最小化 Kubernetes 配置server: environment: ZENML_SERVER_WORKLOAD_MANAGER_IMPLEMENTATION_SOURCE: zenml_cloud_plugins.kubernetes_workload_manager.KubernetesWorkloadManager ZENML_KUBERNETES_WORKLOAD_MANAGER_NAMESPACE: zenml-workspace-namespace ZENML_KUBERNETES_WORKLOAD_MANAGER_SERVICE_ACCOUNT: zenml-workspace-service-account完整的 AWS 配置server: environment: ZENML_SERVER_WORKLOAD_MANAGER_IMPLEMENTATION_SOURCE: zenml_cloud_plugins.aws_kubernetes_workload_manager.AWSKubernetesWorkloadManager ZENML_KUBERNETES_WORKLOAD_MANAGER_NAMESPACE: zenml-workspace-namespace ZENML_KUBERNETES_WORKLOAD_MANAGER_SERVICE_ACCOUNT: zenml-workspace-service-account ZENML_KUBERNETES_WORKLOAD_MANAGER_BUILD_RUNNER_IMAGE: true ZENML_KUBERNETES_WORKLOAD_MANAGER_DOCKER_REGISTRY: 339712793861.dkr.ecr.eu-central-1.amazonaws.com ZENML_KUBERNETES_WORKLOAD_MANAGER_ENABLE_EXTERNAL_LOGS: true ZENML_KUBERNETES_WORKLOAD_MANAGER_POD_RESOURCES: {requests: {cpu: 100m, memory: 400Mi}, limits: {memory: 700Mi}} ZENML_AWS_KUBERNETES_WORKLOAD_MANAGER_BUCKET: s3://my-bucket/run-template-logs ZENML_AWS_KUBERNETES_WORKLOAD_MANAGER_REGION: eu-central-1 ZENML_KUBERNETES_WORKLOAD_MANAGER_NODE_SELECTOR: {node-pool: zenml-pool} ZENML_KUBERNETES_WORKLOAD_MANAGER_TOLERATIONS: [{key: node-pool, operator: Equal, value: zenml-pool, effect: NoSchedule}] ZENML_SERVER_MAX_CONCURRENT_TEMPLATE_RUNS: 10使用预构建 runner 镜像的配置server: environment: ZENML_SERVER_WORKLOAD_MANAGER_IMPLEMENTATION_SOURCE: zenml_cloud_plugins.kubernetes_workload_manager.KubernetesWorkloadManager ZENML_KUBERNETES_WORKLOAD_MANAGER_NAMESPACE: zenml-workspace-namespace ZENML_KUBERNETES_WORKLOAD_MANAGER_SERVICE_ACCOUNT: zenml-workspace-service-account ZENML_KUBERNETES_WORKLOAD_MANAGER_BUILD_RUNNER_IMAGE: false ZENML_KUBERNETES_WORKLOAD_MANAGER_RUNNER_IMAGE: internal-registry.mycompany.com/zenml/zenml:ZENML_OSS_VERSION ZENML_KUBERNETES_WORKLOAD_MANAGER_POD_RESOURCES: {requests: {cpu: 100m, memory: 400Mi}, limits: {memory: 700Mi}} ZENML_KUBERNETES_WORKLOAD_MANAGER_TTL_SECONDS_AFTER_FINISHED: 86400 ZENML_SERVER_MAX_CONCURRENT_TEMPLATE_RUNS: 2更新 Workspace 部署将 workload manager 配置写入你的 workspace server Helm values 文件并重新部署helm upgrade zenml ./zenml-version.tgz \ --namespace zenml-workspace \ --values zenml-workspace-values.yaml关于自托管部署的整体架构与更多 Helm 部署细节可继续阅读 Self-hosted Deployment Overview并参考 Kubernetes 与 Helm 的官方文档深入了解 Job、RBAC 与 Helm values 机制。更多与快照执行、runner 构建相关的源码细节可继续阅读 utils.py、workload_manager_interface.py 与 server_config.py。【免费下载链接】zenmlZenML : One AI Platform from Pipelines to Agents. https://zenml.io.项目地址: https://gitcode.com/GitHub_Trending/ze/zenml创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
ZenML Pro Workspace Server 快照Workload Manager支持配置指南【免费下载链接】zenmlZenML : One AI Platform from Pipelines to Agents. https://zenml.io.项目地址: https://gitcode.com/GitHub_Trending/ze/zenml本篇技术指南讲解如何为自托管self-hosted的 ZenML Pro Workspace Server 启用 SnapshotWorkload Manager支持使流水线能够直接从 ZenML Pro UI 运行。你将掌握 Workload Manager 的两种实现Kubernetes / AWS、三种 runner 镜像管理方案、完整的 Helm 环境变量配置与 Kubernetes RBAC 权限拆分方法并了解 ZenML 开源仓库中对应的接口与执行链路实现。概述从 UI 直接运行快照Workspace Server 内置了Workload Manager特性它允许你在 ZenML Pro UI 中直接运行流水线快照Snapshot而不必依赖本地 CLI 或 SDK 环境。该特性的本质是Workload Manager 会在一个可访问的 Kubernetes 集群中创建临时ad-hoc的流水线 runner Pod/Job由这些 Job 以与 CLI/SDK 相同的方式启动流水线。启用该功能有两个硬性前提来自原文档的警告提示Snapshot 支持仅从ZenML Pro Workspace Server 0.90.0 版本起可用Snapshot 支持仅适用于部署在 Kubernetes 上的 Workspace Server部署在 AWS ECS 或其他平台的 Workspace Server 目前不受支持。从源码看Workload Manager 的启用与否由服务端配置字段workload_manager_implementation_source决定该字段非空时server_config.py 中的workload_manager_enabled属性返回True而runs_endpoints.py、pipeline_snapshot_endpoints.py、run_templates_endpoints.py等路由会据此开放对应的快照运行能力。前置条件在开始配置前需要满足以下基础要求一个可从 Workspace Server 访问的Kubernetes 集群1.24为 runner Pod 准备的专用命名空间namespace具备创建/管理 Pod 权限的服务账号Service Account与 RBAC 权限为服务账号配置的镜像拉取密钥image pull secrets。理解 Workload Manager 子特性从 UI 运行流水线依赖运行 Kubernetes Job即 runner Job这些 Job 与从 CLI/SDK 运行流水线的方式一致。由于这些 Job 需要携带正确 Python 包依赖的容器镜像才能启动流水线你需要根据实际需求选择以下三种 runner 镜像来源之一复用快照容器镜像Reuse snapshot container images直接复用运行快照时为该快照构建的流水线容器镜像。这要求 runner Job 拥有所有存储这些镜像的容器注册表即 ZenML Stack 中使用的 Container Registries的拉取权限。此方案仅能运行与包含同一容器注册表的 Stack 关联的快照。按需构建 runner 镜像Build on-demandWorkspace Server 在需要时会启动额外的 Kubernetes Job 来构建 runner 镜像并推送到已配置的容器注册表。这要求 builder Kubernetes Job 拥有向私有容器注册表推送的权限同时 runner Job 拥有从同一注册表拉取的权限。这是最灵活的方案可以运行与任意 Stack、任意集成关联的快照。使用预构建 runner 镜像Pre-built image为所有运行提供一个预先构建好的单一 runner 镜像存储在你自己的容器注册表中。这是最简单、最快的方案但你需要自行确保镜像中包含正确的 Python 包依赖。此方案限制最大要求预先构建包含所有可能 Stack 与集成依赖的容器镜像。外部日志存储Store logs externally默认情况下ZenML Pro UI 中展示的日志从 runner Job Pod 中提取。由于 Pod 可能消失你可以配置外部日志存储。目前仅 AWS 实现支持外部日志。启用后需要配置日志存放的 S3 bucket 与 region并授予 ZenML Pro Workspace Server Pod 对该 bucket 的写权限。两种 Workload Manager 实现Kubernetes在与 ZenML Pro Workspace Server 相同的 Kubernetes 集群中运行流水线AWS在 Kubernetes 实现的基础上扩展支持向 AWS ECR 构建/推送镜像并将日志存储到 AWS S3。源码中的接口设计在开源仓库中Workload Manager 的行为被抽象为WorkloadManagerInterface见 workload_manager_interface.py核心方法包括run()在容器中运行命令对应启动 runner 流水线build_and_push_image()构建并推送 Docker 镜像对应按需构建 runner 镜像delete_workload()删除工作负载get_logs()获取工作负载日志log()写入工作负载日志消息。同时定义了WorkloadType枚举SNAPSHOT与RUN用于区分工作负载对应的实体类型。仓库内置的 in_memory_workload_manager.py 是一个通过subprocess在服务器本机直接运行的InMemoryWorkloadManager实现而文档中提到的zenml_cloud_plugins.kubernetes_workload_manager.KubernetesWorkloadManager与zenml_cloud_plugins.aws_kubernetes_workload_manager.AWSKubernetesWorkloadManager则来自 ZenML Pro 的云插件包zenml_cloud_plugins不在本开源仓库内。服务端启动时会调用initialize_workload_manager()见 zen_server_api.py其逻辑位于 utils.py读取server_config().workload_manager_implementation_source配置通过source_utils.load_and_validate_class加载并校验实现类实例化后存入全局单例供后续调用。若实现类无法加载只会记录警告而不会导致服务启动失败。第一步为 Workload Manager 创建 Kubernetes 资源创建一个专用的命名空间和服务账号用于启动 runner Job# 创建命名空间 kubectl create namespace zenml-workload-manager # 创建服务账号 kubectl -n zenml-workload-manager create serviceaccount zenml-workload-manager第二步选择 Workload Manager 实现你的实现选择决定了需要在 ZenML Workspace Server Helm 部署中额外配置的环境变量。Option AKubernetes 实现基础版提供通用的 Kubernetes 功能来运行快照server: environment: ZENML_SERVER_WORKLOAD_MANAGER_IMPLEMENTATION_SOURCE: zenml_cloud_plugins.kubernetes_workload_manager.KubernetesWorkloadManager ZENML_KUBERNETES_WORKLOAD_MANAGER_NAMESPACE: zenml-workload-manager ZENML_KUBERNETES_WORKLOAD_MANAGER_SERVICE_ACCOUNT: zenml-workload-managerOption BAWS 实现在 Kubernetes 基础上提供 AWS 特有能力包括外部 S3 日志与 ECR 集成server: environment: ZENML_SERVER_WORKLOAD_MANAGER_IMPLEMENTATION_SOURCE: zenml_cloud_plugins.aws_kubernetes_workload_manager.AWSKubernetesWorkloadManager ZENML_KUBERNETES_WORKLOAD_MANAGER_NAMESPACE: zenml-workload-manager ZENML_KUBERNETES_WORKLOAD_MANAGER_SERVICE_ACCOUNT: zenml-workload-manager ZENML_AWS_KUBERNETES_WORKLOAD_MANAGER_REGION: eu-central-1 # 如需将日志外部存储到 S3还需要设置以下环境变量 ZENML_KUBERNETES_WORKLOAD_MANAGER_ENABLE_EXTERNAL_LOGS: true ZENML_AWS_KUBERNETES_WORKLOAD_MANAGER_BUCKET: s3://my-bucket/run-template-logs第三步配置 Runner 镜像来源根据你对 runner 镜像的管理方式在 Workspace Server Helm 部署中配置相应环境变量Option 1复用快照容器镜像server: environment: ZENML_KUBERNETES_WORKLOAD_MANAGER_BUILD_RUNNER_IMAGE: false # 保持为空或不设置该变量即可复用快照容器镜像 # ZENML_KUBERNETES_WORKLOAD_MANAGER_RUNNER_IMAGE:Option 2由 ZenML 构建 Runner 镜像按需构建server: environment: ZENML_KUBERNETES_WORKLOAD_MANAGER_BUILD_RUNNER_IMAGE: true ZENML_KUBERNETES_WORKLOAD_MANAGER_DOCKER_REGISTRY: internal-registry.mycompany.com/zenmlOption 3使用预构建的 Runner 镜像server: environment: ZENML_KUBERNETES_WORKLOAD_MANAGER_BUILD_RUNNER_IMAGE: false ZENML_KUBERNETES_WORKLOAD_MANAGER_RUNNER_IMAGE: internal-registry.mycompany.com/zenml/zenml:ZENML_OSS_VERSION源码中的镜像与执行细节从源码可以更直观地理解这些配置背后的执行逻辑。在 utils.py 的_build_and_run()函数中整个快照运行流程为根据 stack 与 build 信息生成 Dockerfilebuild_runner_dockerfile()→generate_dockerfile()见同文件 L1116-L1148。生成的 Dockerfile 以zenmldocker/zenml:{zenml_version}-py{python_version}作为父镜像可通过ENV_ZENML_RUNNER_PARENT_IMAGE环境变量覆盖随后安装 stack 所需的 APT 包与 PyPI 依赖默认通过uv安装基于 Dockerfile 内容计算 MD5 哈希generate_image_hash()以zenml-runner:{image_hash}作为镜像名调用workload_manager().build_and_push_image()构建并推送 runner 镜像写入 Starting pipeline run. 日志随后以ENV_ZENML_RUNNER_POD_TIMEOUT默认 180 秒作为超时调用workload_manager().run()启动 runner 工作负载。runner 工作负载通过build_runner_environment()同文件 L1066-L1113注入环境包括ZENML_STORE_URL服务器地址、ZENML_STORE_TYPEREST、ZENML_STORE_API_TOKEN一个永不过期、作用域限定到该流水线运行的 API token由generate_access_token生成以及ZENML_STORE_VERIFY_SSLTrue。runner 启动后便以 REST 客户端身份回连 Workspace Server 执行流水线。第四步配置权限运行 ZenML Workspace Server 的 Kubernetes 服务账号需要额外权限在第一步设置的 workload manager 命名空间中创建和管理 Job 的权限如果使用 AWS 实现且启用了外部 S3 日志还需要向所配置 S3 bucket 写入的权限。第一步设置的 workload manager Kubernetes 服务账号还需要以下容器注册表权限从存储 runner 镜像的容器注册表拉取镜像的权限如果选择按需构建 runner 镜像还需要向 runner 镜像目标注册表推送镜像的权限。授予这些权限有多种方式授予整个集群对容器注册表的访问权限使用隐式工作负载身份访问容器注册表——大多数云厂商支持通过授予 Kubernetes 服务账号对容器注册表的访问权限来实现配置一个对容器注册表具有隐式访问权限的服务账号——将某个云服务身份例如 GCP 服务账号、AWS IAM 角色等与 Kubernetes 服务账号关联为服务账号配置镜像拉取密钥image pull secret——与上一种方式类似但使用 Kubernetes Secret 而非云服务身份。推荐的权限最小化拆分least-privilege split建议为以下两种身份使用独立的服务账号运行 Workspace Server Pod 的服务账号ZENML_KUBERNETES_WORKLOAD_MANAGER_SERVICE_ACCOUNT中为 runner/builder Job 配置的服务账号。Workspace Server 服务账号的 RBAC位于 workload manager 命名空间内Workspace Server 负责创建、监控、清理 workload manager Job并抓取 Pod 日志。需要授予batch/jobscreate、get、deletecollectioncore/podslistcore/pods/logget这与源码中 Workload Manager 的日志获取路径相互印证runs_endpoints.py会调用workload_manager().get_logs()提取 runner 日志并合并到流水线运行的日志集合中见 runs_endpoints.py。Workload manager runner/builder 服务账号由 workload manager 启动的 runner/builder Job 本身不需要对 workload manager 控制回路的 Kubernetes API 权限。该账号主要需要对 runner 镜像的容器注册表拉取权限如果启用了按需构建则需要容器注册表推送权限工作负载实现所需的可选云权限例如启用 AWS 外部日志时的 S3 写权限。环境变量参考Workload Manager 配置支持的全部环境变量如下变量是否必需说明ZENML_SERVER_WORKLOAD_MANAGER_IMPLEMENTATION_SOURCE是实现类见上方两种实现选项ZENML_KUBERNETES_WORKLOAD_MANAGER_NAMESPACE是runner Job 所在的 Kubernetes 命名空间ZENML_KUBERNETES_WORKLOAD_MANAGER_SERVICE_ACCOUNT是runner Job 使用的 Kubernetes 服务账号ZENML_KUBERNETES_WORKLOAD_MANAGER_BUILD_RUNNER_IMAGE否是否构建 runner 镜像默认falseZENML_KUBERNETES_WORKLOAD_MANAGER_DOCKER_REGISTRY条件必需runner 镜像所在的注册表构建镜像时必需ZENML_KUBERNETES_WORKLOAD_MANAGER_RUNNER_IMAGE否预构建的 runner 镜像不构建时使用ZENML_KUBERNETES_WORKLOAD_MANAGER_ENABLE_EXTERNAL_LOGS否是否外部存储日志默认false仅 AWSZENML_KUBERNETES_WORKLOAD_MANAGER_POD_RESOURCES否Pod 资源限制JSON 格式ZENML_KUBERNETES_WORKLOAD_MANAGER_TTL_SECONDS_AFTER_FINISHED否已完成 Job 的清理时间默认2 天ZENML_KUBERNETES_WORKLOAD_MANAGER_NODE_SELECTOR否节点选择器JSON 格式ZENML_KUBERNETES_WORKLOAD_MANAGER_TOLERATIONS否容忍度JSON 格式ZENML_KUBERNETES_WORKLOAD_MANAGER_JOB_BACKOFF_LIMIT否builder/runner Job 的重试上限ZENML_KUBERNETES_WORKLOAD_MANAGER_POD_FAILURE_POLICY否builder/runner Job 的 Pod 失败策略ZENML_SERVER_MAX_CONCURRENT_TEMPLATE_RUNS否每个 Pod 的最大并发快照运行数默认2AWS 特有变量变量是否必需说明ZENML_AWS_KUBERNETES_WORKLOAD_MANAGER_BUCKET条件必需日志存储的 S3 bucket启用外部日志时必需ZENML_AWS_KUBERNETES_WORKLOAD_MANAGER_REGION条件必需AWS 区域构建镜像时必需完整配置示例最小化 Kubernetes 配置server: environment: ZENML_SERVER_WORKLOAD_MANAGER_IMPLEMENTATION_SOURCE: zenml_cloud_plugins.kubernetes_workload_manager.KubernetesWorkloadManager ZENML_KUBERNETES_WORKLOAD_MANAGER_NAMESPACE: zenml-workspace-namespace ZENML_KUBERNETES_WORKLOAD_MANAGER_SERVICE_ACCOUNT: zenml-workspace-service-account完整的 AWS 配置server: environment: ZENML_SERVER_WORKLOAD_MANAGER_IMPLEMENTATION_SOURCE: zenml_cloud_plugins.aws_kubernetes_workload_manager.AWSKubernetesWorkloadManager ZENML_KUBERNETES_WORKLOAD_MANAGER_NAMESPACE: zenml-workspace-namespace ZENML_KUBERNETES_WORKLOAD_MANAGER_SERVICE_ACCOUNT: zenml-workspace-service-account ZENML_KUBERNETES_WORKLOAD_MANAGER_BUILD_RUNNER_IMAGE: true ZENML_KUBERNETES_WORKLOAD_MANAGER_DOCKER_REGISTRY: 339712793861.dkr.ecr.eu-central-1.amazonaws.com ZENML_KUBERNETES_WORKLOAD_MANAGER_ENABLE_EXTERNAL_LOGS: true ZENML_KUBERNETES_WORKLOAD_MANAGER_POD_RESOURCES: {requests: {cpu: 100m, memory: 400Mi}, limits: {memory: 700Mi}} ZENML_AWS_KUBERNETES_WORKLOAD_MANAGER_BUCKET: s3://my-bucket/run-template-logs ZENML_AWS_KUBERNETES_WORKLOAD_MANAGER_REGION: eu-central-1 ZENML_KUBERNETES_WORKLOAD_MANAGER_NODE_SELECTOR: {node-pool: zenml-pool} ZENML_KUBERNETES_WORKLOAD_MANAGER_TOLERATIONS: [{key: node-pool, operator: Equal, value: zenml-pool, effect: NoSchedule}] ZENML_SERVER_MAX_CONCURRENT_TEMPLATE_RUNS: 10使用预构建 runner 镜像的配置server: environment: ZENML_SERVER_WORKLOAD_MANAGER_IMPLEMENTATION_SOURCE: zenml_cloud_plugins.kubernetes_workload_manager.KubernetesWorkloadManager ZENML_KUBERNETES_WORKLOAD_MANAGER_NAMESPACE: zenml-workspace-namespace ZENML_KUBERNETES_WORKLOAD_MANAGER_SERVICE_ACCOUNT: zenml-workspace-service-account ZENML_KUBERNETES_WORKLOAD_MANAGER_BUILD_RUNNER_IMAGE: false ZENML_KUBERNETES_WORKLOAD_MANAGER_RUNNER_IMAGE: internal-registry.mycompany.com/zenml/zenml:ZENML_OSS_VERSION ZENML_KUBERNETES_WORKLOAD_MANAGER_POD_RESOURCES: {requests: {cpu: 100m, memory: 400Mi}, limits: {memory: 700Mi}} ZENML_KUBERNETES_WORKLOAD_MANAGER_TTL_SECONDS_AFTER_FINISHED: 86400 ZENML_SERVER_MAX_CONCURRENT_TEMPLATE_RUNS: 2更新 Workspace 部署将 workload manager 配置写入你的 workspace server Helm values 文件并重新部署helm upgrade zenml ./zenml-version.tgz \ --namespace zenml-workspace \ --values zenml-workspace-values.yaml关于自托管部署的整体架构与更多 Helm 部署细节可继续阅读 Self-hosted Deployment Overview并参考 Kubernetes 与 Helm 的官方文档深入了解 Job、RBAC 与 Helm values 机制。更多与快照执行、runner 构建相关的源码细节可继续阅读 utils.py、workload_manager_interface.py 与 server_config.py。【免费下载链接】zenmlZenML : One AI Platform from Pipelines to Agents. https://zenml.io.项目地址: https://gitcode.com/GitHub_Trending/ze/zenml创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
