ARTICLE DETAIL

建站实战干货

来自一线的建站与推广经验沉淀,每一条都经过真实交付验证。

ZenML Pro 系统架构深度解析:Control Plane 与 Workspace Server 的协同机制与数据驻留模型

2026/9/18 10:11:31 拓冰建站 浏览量
ZenML Pro 系统架构深度解析:Control Plane 与 Workspace Server 的协同机制与数据驻留模型 ZenML Pro 系统架构深度解析Control Plane 与 Workspace Server 的协同机制与数据驻留模型【免费下载链接】zenmlZenML : One AI Platform from Pipelines to Agents. https://zenml.io.项目地址: https://gitcode.com/GitHub_Trending/ze/zenmlZenML Pro 的多租户架构由两大核心服务构成组织级的Control Plane控制平面与工作区级的Workspace Server工作区服务器二者协作完成从管道执行、元数据追踪到组织管理的全部 MLOps 职责。本文以 ZenML Pro 官方系统架构文档为核心骨架结合仓库内部署场景、部署细节文档及 CLI 登录实现、云连接工具 等源码证据帮助你理解各服务组件在不同部署模式下SaaS / Hybrid / Self-hosted的落点、数据流动边界与安全模型从而为团队做出正确的部署与安全决策。核心服务Control Plane 与 Workspace ServerZenML Pro 的架构遵循一个控制平面管理一个或多个工作区服务器的分层模型。这意味着你可以为不同团队、不同项目或不同环境开发/预发/生产分别创建独立的工作区同时共享一套集中的认证与组织管理能力。服务职责部署位置Control Plane认证、RBAC、组织管理每个组织 1 个ZenML 基础设施SaaS/Hybrid或你的基础设施Self-hostedWorkspace Server存储元数据、提供 API、管理实体、从 UI 触发管道运行每个 Control Plane 下可有 1 个或多个你的基础设施Hybrid/Self-hosted或 ZenMLSaaS这一一对多关系正是 ZenML Pro 与开源 ZenML 的核心差异所在开源版本只有一个 ZenML server 实例而 Pro 版本引入了组织级控制平面向下管辖多个彼此隔离的工作区服务器。关于实体层级Organization → Workspace → Project → Team → User → Role的完整介绍可参见 层级结构文档。术语说明在早期版本的 ZenML Pro 中工作区被称为 TenantAPI 文档与部分错误消息中可能仍会出现该称谓二者指代同一概念。Control Plane组织级管理中枢Control Plane 位于所有工作区之上是组织层面的管理大脑集中处理认证、授权与行政职能。核心职责认证与身份Authentication Identity负责用户认证支持 SSO 集成、通过 OIDC 与社交登录提供商实现身份联合并提供 API Key 管理覆盖个人访问令牌与服务账号。授权与 RBACAuthorization RBAC角色管理Admin、Editor、Viewer跨工作区的权限强制以及带共享权限的团队管理。角色与权限的细节参见 roles.md。组织管理Organization Management工作区生命周期管理SaaS 场景下、用户邀请与成员关系处理。工作区协调Workspace Coordination维护工作区注册表对 Hybrid/Self-hosted 部署执行健康监控并在 SaaS 升级时进行版本管理。各部署模式下 Control Plane 的位置部署模式Control Plane 位置SaaSZenML 基础设施完全托管HybridZenML 基础设施完全托管Self-hosted你的基础设施自行管理从源码看Control Plane 与工作区之间的心跳通信是真实存在的在 cloud_utils.py 中定义了send_pro_workspace_status_update()函数它通过cloud_connection().patch(/workspace_status)将工作区状态上报给 Cloud API。这正是架构文档中工作区注册表与健康监控职责的底层实现——工作区服务器需要周期性地向控制平面同步自身的运行状态。Workspace ServerML 运维的中央枢纽Workspace Server 是所有管道相关操作的 API 入口SDK、Dashboard 与各编排器orchestrator都连接到这里。架构文档将其描述为开源 ZenML server 的超集——它包含开源版全部能力并叠加了 Pro 专属功能。核心职责元数据存储与 APIMetadata Storage API管道运行追踪状态、耗时、血缘关系、步骤执行详情、制品注册表指向你的 artifact store 的指针、带版本与阶段的模型注册表。实体管理Entity ManagementStack 与组件、管道定义、制品版本、代码仓库连接。实体层的完整清单可在 src/zenml/models 目录下的 69 个模型文件中找到对应定义。令牌与凭据管理Token Credential Management面向云资源的短时 Service Connector 令牌、Stack 组件认证、API 校验。集成中心Integration Hub为 Python SDK 提供 REST API、作为 Dashboard 后端、接收编排器的状态更新回调。服务端路由实现在 src/zenml/zen_server/routers 与 zen_server_api.py 中。从 UI 执行管道Pipeline Execution from UIWorkspace Server 内置一个 workload manager可在 Kubernetes 集群中创建临时的 runner pod以执行从 Dashboard 触发的管道。各部署模式下 Workspace Server 的位置部署模式Workspace Server 位置SaaSZenML 基础设施完全托管Hybrid你的基础设施自行管理Self-hosted你的基础设施自行管理数据驻留理解你的数据在哪里数据驻留Data Residency是安全与合规决策的关键。架构文档给出了每类数据的存放位置数据类型说明存放位置管道元数据Pipeline Metadata运行状态、步骤执行详情、制品指针Workspace Server 数据库制品Artifacts模型权重、数据集、评估结果你的 artifact storeS3、GCS 等容器镜像Container Images包含你的代码与依赖的 Docker 镜像你的容器仓库日志Logs管道运行的执行日志你配置的日志后端密钥Secrets凭据与敏感配置ZenML secrets store 或外部 vault用户/组织数据User/Org Data认证、RBAC、组织设置Control Plane 数据库重要结论在 ZenML 的所有部署场景中你真正的 ML 数据模型、数据集、制品始终保留在你的基础设施内只有元数据流向 ZenML 服务。这是理解 ZenML Pro 架构安全边界的关键一句话。安全考虑敏感数据与 ML 数据分离架构文档强调Control Plane 处理敏感的认证数据但永远不会访问你的 ML 数据、制品或管道代码。敏感度分级如下数据类型敏感度存储位置用户凭据User credentials高通过 IDP 管理API 令牌API tokens高安全 Cookie 存储组织设置Organization settings中Control Plane 数据库审计日志Audit logs中Control Plane 数据库工作区元数据Workspace metadata低Control Plane 数据库这一设计使得三种部署模式的差异化安全承诺成为可能SaaS 模式下 ZenML 托管服务器基础设施而数据主权仍在你的云环境Hybrid 模式将所有元数据、密钥与制品留在你的基础设施内仅认证与授权数据流向控制平面Self-hosted 模式则零外部依赖、完全隔离运行。各场景的详细对比可参见 scenarios.md。三种部署模式下架构的落点差异理解了核心服务与数据边界后再看三种部署模式如何影响实际架构实体SaaSHybrid SaaSSelf-hostedZenML Workspace ServerZenML 基础设施你的基础设施你的基础设施ZenML Control PlaneZenML 基础设施ZenML 基础设施你的基础设施ZenML Pro UIZenML 基础设施ZenML 基础设施你的基础设施Stack管道计算与数据你的基础设施你的基础设施你的基础设施设置时间约 1 小时约 4 小时约 8 小时维护责任完全托管部分托管需维护工作区完全客户自理适用场景希望最小化基础设施开销、最快见效的团队有安全/合规要求但希望简化用户管理的组织需要完全数据隔离与本地控制的组织需要注意的是无论选择哪种部署模式你在开发环境中通过 pip 安装的客户端 SDK 都是同一个 ZenML 官方包、hybrid-deployment.md 与 self-hosted-deployment.md。源码印证从 CLI 看工作区连接与 Pro API架构中的Workspace Server 提供 API 层供 SDK/Dashboard 连接在 CLI 实现中有直接对应。在 src/zenml/cli/login.py 中zenml login命令支持--pro-api-url参数对应源码中的pro_api_url: Optional[str] None参数login.py用于 Self-hosted 部署时指定 Pro API 地址未显式传入时会回退到ZENML_PRO_API_URL环境变量pro_api_url pro_api_url or ZENML_PRO_API_URL登录过程中通过ZenMLProClient(pro_api_url)与 Pro API 交互并通过is_pro_server(server)判断目标服务器是否为 Pro 服务器从而决定认证流程见 login.py登出时可用zenml logout --pro --clear清理 Pro 凭据。对应到 工作区文档 中的实操命令# 登录到你的工作区SaaS 场景直接使用工作区名称 zenml login WORKSPACE_NAME # Self-hosted 场景需额外指定 Pro API 地址 zenml login WORKSPACE_NAME --pro-api-url URL_OF_STAGING # 登录后初始化仓库并设置活动项目与 Stack zenml init zenml project set default zenml stack set default其中--pro-api-url仅对 Self-hosted 部署必需SaaS 版可省略。这从命令行层面验证了架构文档所述无论工作区服务器部署在何处客户端统一通过其 REST API 接入。相关文档导航scenarios.md对比三种部署选项选择最适合你的场景deploy-details.md各组件部署的详细配置参考环境变量、权限、网络要求upgrades-updates.md组件的升级与更新方式hierarchy.md组织 → 工作区 → 项目 → 团队 → 用户 → 角色的完整层级workspaces.md工作区的创建、组织与使用【免费下载链接】zenmlZenML : One AI Platform from Pipelines to Agents. https://zenml.io.项目地址: https://gitcode.com/GitHub_Trending/ze/zenml创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考