GitHub 源码知乎专栏

管理员操作指南

作为平台管理员，需要配置机器标签调度 / 权限 / LDAP 认证 / 项目组 / 任务模板 / 任务流后台行为时读这篇

04-运维管理 / 管理员配置
管理员admin运维配置机器标签labelnode selectornodeSelector权限RBAC认证LDAPldap3项目组org模板分类expand

管理员操作指南

本篇从管理员视角说明平台的调度、权限、认证与各功能模块的后台行为配置。事实性内容已对照源码核实，关键差异处给出 文件:行号 依据。

机器标签管理

机器通过 label 进行管理，所有的调度机器由平台控制，不由用户直接控制。

开发训练服务机器管理

  • 对于 CPU 的 train/notebook/service 会选择 cpu=true 的机器
  • 对于 GPU 的 train/notebook/service 会选择 gpu=true 的机器
  • 对于 vGPU 的 service 会选择 vgpu=true 的机器
  • 训练任务会选择 train=true 的机器
  • notebook 会选择 notebook=true 的机器
  • 服务化会选择 service=true 的机器
  • 不同项目的任务会选择对应 org=xx 的机器，默认为 org=public
  • 可以通过 gpu-type=xx 表示 GPU 的型号，比如 gpu-type=V100 或 gpu-type=T4。在配置 GPU 算力时也可以同步配置 GPU 型号，例如 2(T4) 表示 2 张 T4 卡。

默认的 node_selector：notebook 默认 cpu=true;notebook=true（见 myapp/views/view_notebook.py:171）；pipeline 任务默认 cpu=true;train=true;org=public（见 myapp/views/view_pipeline.py:161）。

控制器机器管理

平台部署脚本 install/kubernetes/start.sh 中给控制面机器统一打的标签如下（每个标签对应一类控制组件，按需拆分到不同机器）：

  • mysql=true：部署 MySQL 服务的机器
  • redis=true：部署 Redis 服务的机器
  • kubeflow-dashboard=true：部署 CubeStudio 服务（kubeflow-dashboard）的机器
  • kubeflow=true：部署 kubeflow 的机器
  • istio=true：部署 istio 的机器
  • monitoring=true：部署 prometheus 的机器
  • logging=true：部署日志组件的机器

⚠️ 原文档此处有笔误，已按 install/kubernetes/start.sh:25 的实际标签纠正：应为 istio=true（非 isito）、kubeflow-dashboard=true（非 kubeflow-dashobard），redis=true 对应 Redis（原文误写成"部署 mysql 服务"）。start.sh 实际还包含 logging=true。

打标签命令示例（详见 02-部署安装 / 多机多集群多资源组）：

kubectl label node $node train=true cpu=true notebook=true service=true org=public \
  istio=true kubeflow=true kubeflow-dashboard=true mysql=true redis=true monitoring=true logging=true --overwrite

权限管理

  • OA 登录开发：登录方式可通过 project.py 文件定义的方式自行修改，或自行添加管理员专用接口。
  • RBAC 的权限管理方式：所有菜单 / 模块的增删改查以及所有后端接口都有权限控制，可以在 Security 中自由控制。
  • 用户登录后会自动创建并绑定与用户名同名的角色，同时绑定 gamma 角色，加入 public 项目组。

认证方式

CubeStudio 支持多种认证方式，默认使用 MySQL 的账号密码验证。用户也可以根据实际环境对接 LDAP。

当前 LDAP 兜底机制：用户走 /login/db/ 登录时，先用本地 ab_user 表的密码校验；本地密码不匹配且配置了 AUTH_LDAP_SERVER 时，会尝试 LDAP bind 兜底（见 myapp/views/view_login.py:226-231）。bind 用户名拼接为 username@AUTH_LDAP_BASE_DN（见 view_login.py:133）。若用户在本地不存在且 LDAP bind 成功，会自动注册到本地。

config.py 中的相关配置项（见 myapp/config.py:154-158）：

AUTH_LDAP_SERVER = ""             # LDAP 服务地址，如 ldap://xx.xx.xx.xx；为空则不启用 LDAP 兜底
AUTH_LDAP_PORT = "xx"             # LDAP 端口
AUTH_LDAP_USE_TLS = False         # 是否使用 TLS
AUTH_LDAP_BASE_DN = 'cpcnet.local'  # 基准 DN，会与用户名拼成 username@BASE_DN 做 bind

依赖 ldap3 库（from ldap3 import ALL, Connection, Server），后端镜像需安装该包，更好的方式是在构建镜像时通过 Dockerfile 安装。

项目组 -> 模板分类

项目组（模板分组）的 expand 字段：

{
  "index": 2
}

index 控制该分组下面的 job 模板在 pipeline 编排界面左侧的显示顺序（见 myapp/views/view_job_template.py:270，分组 index 会乘以 1000 参与排序）。

项目组 -> 项目分组

跨 k8s 集群调度的支持

需要在 config.py 中配置 CLUSTERS，并通过 ENVIRONMENT 环境变量指定控制台所在的集群，其他集群为训练集群（见 myapp/config.py:1403，ENVIRONMENT 见 config.py:461，默认 DEV）。多集群部署与资源组划分的完整步骤见 02-部署安装 / 多机多集群多资源组。

CLUSTERS 结构示例（每个 key 与 project expand 里的 cluster 名称一致）：

CLUSTERS = {
    "dev": {
        "NAME": "dev",
        "KUBECONFIG": "/home/myapp/kubeconfig/dev-kubeconfig",
        "SERVICE_DOMAIN": "service.svc.cluster.local",
        "HOST": "192.168.3.22",
    },
}

在项目组 / 项目分组中，可通过项目组的 expand 字段控制其调度集群：

{
  "cluster": "dev"
}

资源划分项目组

机器通过 label 进行管理，所有调度机器由平台控制。在标注好哪些机器属于哪些项目后，可通过项目组的 expand 字段控制调度机器（见 myapp/models/model_team.py:63-70，org 会被拼接成 org=xx 加入 node_selector）：

{
  "org": "public"
}

控制该项目自动挂载什么 pvc，可通过项目组的 expand 字段配置：

{
  "volume_mount": "kubeflow-user-workspace(pvc):/mnt"
}

在线开发 -> notebook

定时任务中配置了 notebook 的定时清理和提醒用户续期，没有及时续期的 notebook 会被删除，容器消失后环境丢失。

实现：清理逻辑在 myapp/tasks/schedules.py 的 delete_notebook celery 任务（见 schedules.py:185）。过期时长由 ENABLE_JUPYTER_EXPIRY 控制，默认 60*60*24*3（3 天，见 myapp/config.py:989）；每次续期有效期 3 天。续期接口 /renew/<notebook_id>（见 view_notebook.py:1002）。

在线开发 -> 镜像调试

在线调试镜像时，保存按钮会自动 commit/push 到仓库，当晚也会自动释放调试容器。

实现：调试容器的释放在 myapp/tasks/schedules.py 的 delete_debug_docker celery 任务（见 schedules.py:220）。

训练 -> 仓库

仓库中的 k8s hubsecret 以及账号密码，在保存时会更新到所配置的所有集群的各个命名空间下。当用户拉起 pod 时，也会附带上用户配置的 k8s hubsecret 以及 config.py 中配置的公共 k8s hubsecret（拉取秘钥的合并见 myapp/views/view_docker.py:283、view_docker.py:427）。

建议仓库拉取秘钥均在 config.py 中全局配置。

训练 -> 任务模板

任务模板的字段定义见 myapp/views/view_job_template.py。模板挂载 / 环境变量 / k8s 账号等更详细的说明见 05-任务模板 段。

版本

模板的 release 版本才能被用户看到（开发者能看到所有模板，见 view_job_template.py:42、:101）。

工作目录 / 启动命令

如果配置，则会覆盖镜像的启动目录和启动命令。

挂载目录

会在 task 创建时添加模板的挂载项，一般用户需要固定挂载的模板会配置该参数（比如 docker in docker 需要 docker.sock）。目前支持 hostpath / pvc / memory / configmap / storage 几种挂载方式：

kubeflow-user-workspace(pvc):/mnt          # pvc 挂载方式，会自动在 pvc 下挂载个人 username 子目录
/data/k8s/kubeflow/pipeline/workspace/xxxx(hostpath):/mnt   # 挂载主机目录
4G(memory):/dev/shm                        # 内存挂载为磁盘
kubernetes-config(configmap):/root/.kube   # 挂载 configmap 成文件夹

环境变量

会附加给每个使用该模板的 task。书写格式：每行一个环境变量 env_key=env_value（见 view_job_template.py:131-134）。

模板中特殊的环境变量（见 myapp/views/view_pipeline.py:664-668、myapp/views/view_task.py:641-644、myapp/tools/watch_workflow.py:180）：

NO_RESOURCE_CHECK=true    # 使用该模板的 task 不会进行资源配置的自动校验（也不参与近 10 次资源动态调整）
TASK_RESOURCE_CPU=4       # 忽略用户的资源配置，cpu 固定配置为 4 核
TASK_RESOURCE_MEMORY=4G   # 忽略用户的资源配置，mem 固定配置为 4G
TASK_RESOURCE_GPU=0       # 忽略用户的资源配置，gpu 固定配置为 0 卡

补充：init 模板中还可见 TASK_RESOURCE_RDMA=0（见 myapp/init/init-job-template.json），用法同上，用于固定 RDMA 资源。

k8s 账号

为模板配置 k8s 账号（ServiceAccount），主要为那些需要操控 k8s 集群的模板设定，比如临时分布式训练集群的 launcher 端（见 view_job_template.py:152）。

扩展（expand）

{
  "index": 7,
  "help_url": "http://xx.xx.xx.xx/xx"
}

index 控制在 pipeline 编排界面同一个模板分组中每个模板的显示顺序；help_url 为 pipeline 编排界面每个模板的帮助文档地址（见 view_job_template.py:160-163，该 expand 还支持 "HostNetwork": true 启动主机端口监听）。

训练 -> 任务流

任务流的使用细节见 03-平台使用 段（任务流）。以下为后台调度行为：

  • 先调试单独的 task，再调试 pipeline 的原则。
  • task 包含 debug/run/log/clear 等功能，通过 run-id 串联对应的 pod 和 crd。
  • pipeline 包含 run/log/运行实例/定时调度记录/pod 等功能，使用 run-id 串联所有的 task。
  • 手动运行 pipeline 会先清空之前手动运行的 pipeline 实例（workflow）。
  • 定时任务会定时清理运行结束的 pod，避免 pod 堆积过多（实现在 myapp/tasks/schedules.py 的 delete_debug_docker/delete_workflow 任务，见 schedules.py:220、:133）。

    ⚠️ 原文档此处写的是 myapp/task/scheduler.py，当前代码中并无此文件，清理逻辑在 myapp/tasks/schedules.py，已更正。

  • 在 pipeline 正常运行 10 次以后，定时任务会取其中真实使用的资源最大值，再预留一定空间，动态修改用户配置的资源项，防止资源配置不合理而浪费算力（实现见 myapp/tools/watch_workflow.py:176，按近 10 次最大值 ceil(max*1.4)+2 计算，cpu 上限 150、内存上限 350）。

训练 -> demo 任务流

首页会显示所有的 demo pipeline，即 pipeline 扩展字段 expand（dict）中包含（见 myapp/views/view_pipeline.py:1524，按 parameter 含 "demo": "true" 过滤）：

{
  "demo": "true",
  "img": "https://xx.xx.xx.xx/xx.png"
}

训练 -> 定时调度记录

手动运行和定时运行同一个 pipeline，相互之间不干扰。

最后更新 2026-07-04完整文档以官方仓库为准：GitHub Wiki