1. 为什么要在数据中台里塞进一个算力调度层做过数据中台的人大概都有这种体会平台建得越完整算力这件事就越拧巴。上层是数据集成、数据开发、数据服务、指标管理这一整套东西跑得挺顺可一旦业务方提出来“我要微调一个7B的模型”“我要跑一批OCR识别”“我要做向量化入库”整个平台就开始露怯了。GPU服务器买了几台散落在几个项目组手里谁用谁装环境装完就跑跑完就占着占着别人还看不见。CPU资源倒是多但没人愿意把训练任务往CPU上放因为默认认知里“训练必须上GPU”。这个项目要解决的就是这个断层。标题里说的“AllData数据中台集成开源项目Crater”本质上是把算力资源池化这件事从数据中台的底座层面重新做了一遍。Crater在这里承担的角色不是又一个训练框架而是一个异构算力抽象层——它把GPU、CPU、内存、磁盘这四类资源统一纳管向上暴露成一套可申请、可配额、可回收、可观测的资源视图向下对接K8s、对接容器运行时、对接具体的推理和训练任务。我先把结论放前面这套东西的价值不在于“能跑大模型”市面上能跑大模型的方案太多了。它的价值在于把训推一体化这件事从“项目制”变成了“平台制”。以前一个算法团队要跑训练得自己申请机器、自己配CUDA、自己管显存、自己处理OOM现在这些动作全部收敛到中台的资源调度层算法同学只需要提交任务描述算力从哪来、用多少、什么时候释放平台自己算。适合谁来参考这篇内容三类人。第一类是正在做数据中台或AI平台的技术负责人你们大概率已经遇到了“算力孤岛”的问题第二类是运维和SRE你们需要理解GPU这种特殊资源在K8s体系里到底怎么管第三类是算法工程师你们可能不关心调度细节但你需要知道平台能给你什么、你该怎么提需求才能拿到合适的资源。1.1 异构算力池化的核心矛盾在哪先说清楚问题不然方案讲起来就是空中楼阁。异构算力池化最难的地方不是“把GPU加进K8s”这么简单。K8s原生支持nvidia.com/gpu这种扩展资源装个device plugin就能让Pod申请GPU。但真到了生产环境你会发现几个要命的问题第一GPU的粒度太粗。一张A100 80G你按整卡调度一个推理任务可能只用了8G显存剩下72G就浪费了。你按显存切分又涉及到显存隔离、算力隔离、故障隔离这一堆事。Crater在这块的做法是引入虚拟化切分的思路把物理GPU切成多个vGPU实例每个实例有独立的显存配额和算力配额。这跟HAMI那套思路是一脉相承的但Crater把它做进了数据中台的资源模型里跟CPU、内存的配额管理放在同一个平面上。第二CPU和GPU的配比问题。一个训练任务你给它4张GPU那CPU给多少内存给多少给少了数据加载跟不上GPU利用率上不去给多了CPU资源被占死其他任务排不进来。Crater的资源模型里GPU、CPU、内存、磁盘是联合配额的申请GPU的时候必须同时声明CPU和内存需求平台会根据历史任务的资源画像给出推荐配比。这个设计很关键它避免了“GPU申请了但跑不满”的经典浪费。第三磁盘IO经常被忽略。大模型训练的数据集动辄几百G推理服务的模型文件也是几十G起步。磁盘这块如果不做配额和隔离一个任务把IO打满整台机器上所有任务都跟着遭殃。Crater把磁盘IO也纳入了资源视图虽然不能像CPU那样精确切分但至少能做到配额限制和优先级抢占。提示很多团队做算力平台只盯着GPU看结果上线后发现瓶颈全在数据加载和磁盘IO上。资源池化一定要把存储IO纳入考量否则GPU利用率永远上不去。1.2 训推一体化到底意味着什么“训推一体化”这个词被用烂了但在这个项目语境里它有非常具体的含义。传统做法是训练和推理分开建设训练集群用一套推理集群用另一套。训练集群追求高吞吐、高互联带宽推理集群追求低延迟、高并发。两套集群各自管理资源不能互相借用。结果就是训练任务闲的时候GPU空转推理高峰的时候又不够用。Crater的思路是同一套资源池通过调度策略区分训推任务。训练任务通常需要多卡并行、需要NVLink或高速网络互联调度器会把这类任务尽量调度到同一台机器或同一个互联域内推理任务通常是单卡或小规模多卡调度器会把它们打散到各个节点充分利用碎片资源。两类任务共享同一个资源池通过优先级和抢占策略来调节。这里有个实操细节训练任务一般是可以被抢占的因为训练有checkpoint机制中断了可以从最近的checkpoint恢复推理任务通常不能被抢占因为线上服务中断就是事故。Crater的调度器里训练任务的优先级默认低于推理任务当推理任务需要资源时可以抢占训练任务的资源。这个策略需要在任务提交时显式声明不能默认全开否则训练同学会疯掉。2. Crater的资源抽象模型与核心组件拆解要理解Crater怎么管算力得先看它的资源抽象模型。这套模型不是Crater独创的但它跟数据中台的结合方式有自己的特点。2.1 四类资源的统一视图怎么建Crater把资源分成四层来看资源类型调度单位隔离方式配额粒度典型瓶颈场景GPU卡/显存MB设备隔离显存隔离0.1卡多任务共享单卡CPU核millicorecgroup0.1核数据预处理内存MBcgroup128MB大模型加载磁盘IOPS/带宽cgroup blkio按权重数据集读取GPU的调度单位是“卡”和“显存”两个维度。申请的时候可以写gpu: 0.5表示半张卡也可以写gpu-memory: 40960表示40G显存。这两个维度是联合生效的调度器会找一张剩余显存足够的卡来放置任务。CPU和内存走的是K8s原生的resource request/limit机制这个没什么好说的标准做法。但Crater在CPU这块加了一个智能核心调度的逻辑对于推理任务尽量把CPU核心绑定到GPU所在的NUMA节点上减少跨NUMA访问的开销。这个优化在CPU推理场景下效果很明显实测能降低15%到20%的延迟。磁盘这块比较特殊。Crater没有做磁盘空间的硬配额因为数据集和模型文件通常放在共享存储上硬配额不现实。它做的是IO带宽的软限制通过cgroup blkio来控制每个任务的磁盘读写速率。这个限制不是硬性的当磁盘空闲时可以超发当磁盘繁忙时按权重分配。2.2 调度器的三层架构Crater的调度器分三层这个设计值得细说第一层是资源画像层。这一层负责收集和分析历史任务的资源使用数据。每个任务跑完之后它的GPU利用率、显存峰值、CPU使用率、内存峰值、磁盘IO曲线都会被记录下来形成一个资源画像。当新任务提交时调度器会根据任务类型训练/推理/数据处理和模型规模从画像库里找相似任务给出资源推荐。这个画像层的价值在于避免拍脑袋申请资源。我见过太多团队算法同学申请资源的时候都是“给我来8张A100”问他为什么他说“感觉需要”。结果跑起来GPU利用率不到30%。有了画像层平台可以直接告诉他你这个规模的模型参考历史任务4张卡就够了显存峰值大概60G。第二层是配额管理层。这一层管的是“谁能用多少”。Crater支持多租户每个租户部门、项目组、个人有独立的配额。配额分两种硬配额和软配额。硬配额是绝对不能超的软配额是可以在资源空闲时超发的。比如一个租户硬配额是4张GPU软配额是8张平时只能用4张但当整个集群GPU利用率低于50%时可以临时用到8张。这个设计解决了一个很现实的问题资源闲置和资源争抢同时存在。有的团队配额用不完有的团队不够用。软配额机制让资源可以在空闲时流动起来提高整体利用率。第三层是任务调度层。这一层是真正做决策的地方。它接收任务提交请求根据资源画像、配额、当前集群状态决定任务放到哪个节点、分配多少资源、什么时候启动。调度策略支持多种binpack尽量填满单节点适合训练、spread尽量打散适合推理、priority按优先级抢占。注意调度策略不是全局统一的而是按任务类型和队列来配置的。训练队列用binpack推理队列用spread离线任务用priority。这个配置在Crater的调度器配置文件里改完需要重启调度器生效。2.3 跟K8s的集成方式Crater不是要替代K8s它是构建在K8s之上的调度层。底层的容器编排、网络、存储还是K8s那一套Crater做的是资源抽象和调度决策。具体来说Crater通过几个组件跟K8s集成Device Plugin负责向K8s上报GPU资源包括物理卡和切分后的vGPU。这个组件跑在每个GPU节点上以DaemonSet形式部署。Scheduler Extender扩展K8s默认调度器在调度决策时加入Crater的资源画像和配额逻辑。K8s默认调度器先做一轮筛选Crater的extender再做一轮打分和过滤。Resource Controller负责配额管理和资源回收。当任务结束或超配额时controller会介入处理。Metrics Collector采集GPU、CPU、内存、磁盘的实时指标推送到监控系统同时写入资源画像库。这套集成方式的好处是不破坏K8s生态。你现有的K8s运维体系、监控体系、日志体系都不用动Crater是叠加在上面的。坏处是调度延迟会比原生调度器高一些因为多了一层extender调用。实测下来单次调度延迟增加大概50到100毫秒对于大多数场景可以接受。3. 从零搭建训推一体化算力平台的实操路径这一部分讲具体怎么做。我按实际部署的顺序来写从环境准备到任务提交每一步都给出可操作的命令和配置。3.1 基础环境准备与依赖检查假设你已经有了一套K8s集群版本在1.24以上。如果没有先用kubeadm或者k3s搭一个这个不展开讲。第一步检查节点GPU状态。在每个GPU节点上执行nvidia-smi -L输出应该是类似这样的GPU 0: NVIDIA A100-SXM4-80GB (UUID: GPU-xxxx) GPU 1: NVIDIA A100-SXM4-80GB (UUID: GPU-yyyy)如果这个命令报错说明驱动没装好先装驱动。驱动版本建议用515以上太老的版本对容器化支持不好。第二步安装NVIDIA Container Toolkit。这个组件让容器能访问GPU设备distribution$(. /etc/os-release;echo $ID$VERSION_ID) curl -s -L https://nvidia.github.io/libnvidia-container/gpgkey | sudo apt-key add - curl -s -L https://nvidia.github.io/libnvidia-container/$distribution/libnvidia-container.list | sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list sudo apt-get update sudo apt-get install -y nvidia-container-toolkit sudo nvidia-ctk runtime configure --runtimedocker sudo systemctl restart docker装完之后用一个小测试验证一下docker run --rm --gpus all nvidia/cuda:11.8.0-base-ubuntu22.04 nvidia-smi能正常输出GPU信息就说明环境OK了。第三步部署Crater的核心组件。Crater的部署方式支持Helm和原生YAML两种推荐用Helm升级方便。先把Crater的Helm仓库加进来helm repo add crater https://charts.crater.io helm repo update然后创建一个values文件配置你的集群参数# crater-values.yaml global: clusterName: ai-platform namespace: crater-system scheduler: replicas: 2 image: repository: crater/scheduler tag: v1.2.0 resources: requests: cpu: 2 memory: 4Gi limits: cpu: 4 memory: 8Gi devicePlugin: enabled: true gpuSharing: true memoryUnit: MiB resourceController: quotaEnabled: true softQuotaRatio: 2.0 metricsCollector: interval: 15s retention: 30d这里有几个参数需要解释gpuSharing: true开启GPU切分允许一张卡被多个任务共享。memoryUnit: MiB显存配额的单位用MiB比较直观。softQuotaRatio: 2.0软配额是硬配额的两倍这个值根据你的集群规模调整。interval: 15s指标采集间隔太短会增加开销太长会影响调度精度。执行安装helm install crater crater/crater -f crater-values.yaml -n crater-system --create-namespace安装完成后检查Pod状态kubectl get pods -n crater-system应该能看到scheduler、device-plugin、resource-controller、metrics-collector这几组Pod都在Running状态。3.2 GPU切分与显存隔离的配置细节GPU切分是Crater的核心能力之一这块配置不对后面全是坑。Crater的GPU切分有两种模式显存切分和算力切分。显存切分是把一张卡的显存分成多个独立区域每个区域给一个任务用算力切分是把GPU的计算核心按时间片轮转多个任务分时复用。显存切分是默认开启的配置在device-plugin的ConfigMap里apiVersion: v1 kind: ConfigMap metadata: name: crater-device-plugin-config namespace: crater-system data: config.yaml: | gpuSharing: enabled: true mode: memory # memory | compute | both memorySlice: 8192 # 每个切分单元8GB maxSlices: 10 # 单卡最多切10份memorySlice: 8192表示每个切分单元是8GB显存。一张80GB的卡理论上可以切10份但maxSlices: 10限制了上限。实际配置时这个值要根据你的任务特征来定。如果推理任务多每个任务显存需求小可以切细一点如果训练任务多显存需求大就切粗一点。算力切分需要额外的配置而且对GPU型号有要求。A100和A30支持MIGMulti-Instance GPU可以硬件级切分其他型号只能用软件方式做时间片轮转。MIG的配置在节点层面做# 在GPU节点上执行创建MIG实例 nvidia-smi mig -cgi 1g.10gb,1g.10gb,1g.10gb,1g.10gb -C这个命令创建4个1g.10gb的MIG实例每个实例有10GB显存和1/7的算力。创建完之后Crater的device-plugin会自动发现这些MIG实例并把它们作为独立的GPU资源上报。提示MIG实例的创建是持久化的重启节点后不会丢失。但如果要修改MIG配置需要先销毁所有实例再重新创建。销毁命令是nvidia-smi mig -dci。显存隔离这块有个坑显存切分不是硬隔离。如果一个任务申请了8GB显存但实际用了10GB它可能会挤占其他任务的显存空间导致其他任务OOM。Crater的做法是在容器层面加一个显存限制的wrapper通过CUDA_MPS_ACTIVE_THREAD_PERCENTAGE和显存配额来软限制。但这个限制不是100%可靠的极端情况下还是会溢出。所以生产环境里我建议显存配额留20%的余量。比如任务实际需要8GB就申请10GB。这样即使有波动也不会影响到别人。3.3 任务提交与资源申请的实操示例环境搭好了接下来看怎么提交任务。Crater的任务提交支持三种方式命令行、Web界面、API。命令行最直接适合调试Web界面适合日常使用API适合集成到CI/CD流程里。先看命令行的方式。Crater提供了一个crater-cli工具安装很简单curl -LO https://github.com/crater-io/crater-cli/releases/latest/download/crater-cli-linux-amd64 chmod x crater-cli-linux-amd64 sudo mv crater-cli-linux-amd64 /usr/local/bin/crater配置好API地址和认证信息crater config set --server https://crater.your-domain.com --token your-api-token然后提交一个推理任务crater job submit \ --name llm-inference-7b \ --image registry.your-domain.com/llm-inference:v1.0 \ --gpu 1 \ --gpu-memory 40960 \ --cpu 8 \ --memory 32Gi \ --disk-io 100 \ --command python serve.py --model /models/llama-7b --port 8080 \ --queue inference \ --priority high这个命令里几个关键参数--gpu 1申请1张GPU卡。--gpu-memory 40960申请40GB显存。注意这里申请的是显存配额不是整卡。如果集群里有80GB的卡调度器会找一张剩余显存足够的卡来放置。--cpu 8申请8个CPU核心。--memory 32Gi申请32GB内存。--disk-io 100磁盘IO权重100相对于其他任务的权重。--queue inference提交到推理队列使用spread调度策略。--priority high高优先级可以抢占低优先级的训练任务。提交之后用crater job list查看任务状态crater job list --queue inference输出类似ID NAME STATUS GPU MEMORY NODE job-001 llm-inference-7b Running 1 40Gi gpu-node-03 job-002 ocr-batch Pending 0.5 8Gi -Pending状态的任务说明资源不够在排队。可以用crater job describe job-002看详细原因。再看一个训练任务的例子crater job submit \ --name llm-finetune-7b \ --image registry.your-domain.com/llm-train:v2.0 \ --gpu 4 \ --gpu-memory 327680 \ --cpu 32 \ --memory 128Gi \ --disk-io 500 \ --command torchrun --nproc_per_node4 train.py --model /models/llama-7b --data /data/finetune \ --queue training \ --priority medium \ --preemptible true训练任务的关键区别--gpu 4申请4张卡调度器会尽量把这4张卡放在同一台机器上保证NVLink互联。--gpu-memory 3276804张卡共320GB显存80GB x 4。--preemptible true声明任务可被抢占。当推理任务需要资源时这个训练任务会被暂停释放资源。训练框架需要支持checkpoint恢复否则被抢占后要从头开始。注意--preemptible true这个参数一定要谨慎使用。如果你的训练代码没有实现checkpoint机制被抢占后任务会失败需要重新提交。建议在训练脚本里加上定期保存checkpoint的逻辑比如每1000步保存一次。3.4 资源监控与配额调整的日常操作平台跑起来之后日常运维主要看几个东西资源利用率、配额使用情况、任务排队情况。Crater自带了一个监控面板访问https://crater.your-domain.com/dashboard就能看到。面板上主要看几个指标GPU利用率热力图按节点展示每张卡的利用率颜色越深利用率越高。如果发现某些卡长期浅色说明资源分配不均需要调整调度策略。显存使用趋势展示集群总显存的使用曲线。如果长期在80%以上说明显存紧张需要考虑扩容或优化任务。任务排队时长按队列展示任务的平均排队时长。如果某个队列排队时长持续增长说明该队列的资源配额不够。配额使用率按租户展示配额使用情况。如果某个租户长期超软配额说明硬配额设置不合理。配额调整通过crater quota命令来做# 查看当前配额 crater quota get --tenant team-nlp # 调整硬配额 crater quota set --tenant team-nlp --gpu-hard 8 --cpu-hard 64 --memory-hard 256Gi # 调整软配额 crater quota set --tenant team-nlp --gpu-soft 16 --cpu-soft 128 --memory-soft 512Gi配额调整是即时生效的不需要重启任何组件。但要注意降低硬配额不会立即驱逐正在运行的任务只会影响新任务的提交。如果要强制回收资源需要用crater job evict命令手动驱逐。# 驱逐某个任务 crater job evict job-001 --reason quota-exceeded # 驱逐某个租户的所有低优先级任务 crater job evict --tenant team-nlp --priority low --all4. 踩坑记录与常见问题排查这一部分是我在实际部署和运维中积累的经验有些是Crater本身的坑有些是K8s和GPU环境的老问题。4.1 GPU资源上报异常的排查思路问题现象Crater的device-plugin启动了但kubectl describe node gpu-node-01里看不到nvidia.com/gpu资源。排查步骤第一步检查device-plugin的Pod日志kubectl logs -n crater-system -l appcrater-device-plugin --tail100如果看到failed to initialize NVML: Driver/library version mismatch说明驱动版本和容器里的CUDA库版本不匹配。解决办法是更新驱动或者换一个匹配的CUDA基础镜像。如果看到no devices found说明容器没有正确挂载GPU设备。检查device-plugin的DaemonSet配置里有没有/dev/nvidia*的volume挂载。第二步检查节点上的nvidia-smi是否正常nvidia-smi如果这个命令报错说明是节点层面的问题跟Crater无关。常见原因是驱动没装好或者GPU掉了。第三步检查K8s的Node Resource报告kubectl get node gpu-node-01 -o json | jq .status.capacity如果nvidia.com/gpu不在capacity里说明device-plugin没有成功注册资源。这时候需要重启device-plugin的Podkubectl rollout restart daemonset/crater-device-plugin -n crater-system提示device-plugin的资源上报有延迟重启后等30秒左右再检查。如果还是不行检查kubelet的日志看有没有device plugin相关的错误。4.2 显存OOM与任务被杀的应急处理问题现象任务运行中突然被杀日志里看到CUDA out of memory。原因分析显存OOM通常有三种原因。第一种是任务实际显存需求超过了申请配额第二种是显存碎片化虽然总剩余显存够但没有连续的大块显存第三种是多个任务共享一张卡时某个任务显存溢出影响了其他任务。应急处理先看是哪个任务OOM了crater job list --status failed --since 1h找到OOM的任务后看它的显存使用曲线crater job metrics job-xxx --metric gpu-memory --range 1h如果曲线显示显存持续增长然后突然掉下来说明是内存泄漏或者batch size太大。解决办法是调小batch size或者加显存清理逻辑。如果是碎片化问题可以尝试开启PyTorch的显存碎片整理import torch torch.cuda.memory._set_allocator_settings(expandable_segments:True)这个设置让PyTorch使用可扩展的显存段减少碎片。如果是多任务共享导致的建议把显存配额调大或者把任务调度到独占的GPU上。Crater支持--gpu-exclusive参数申请整卡独占crater job submit --gpu 1 --gpu-exclusive true ...独占模式下这张卡不会被其他任务共享显存隔离是硬隔离。4.3 任务排队不动的几种典型情况情况一配额满了。任务在排队但集群明明有资源。这时候检查租户配额crater quota get --tenant your-tenant如果gpu-used等于gpu-hard说明硬配额用完了。解决办法是等任务结束释放配额或者临时提高软配额。情况二节点亲和性不满足。任务指定了节点标签但没有节点满足。检查任务的调度约束crater job describe job-xxx | grep -A 10 Scheduling Constraints如果有nodeSelector或者affinity配置确认目标节点是否存在且可用。情况三磁盘IO配额不足。这个比较隐蔽。Crater的磁盘IO配额是全局的如果集群磁盘IO已经打满新任务即使GPU和CPU够也会因为IO配额不足而排队。检查集群IO使用率crater cluster metrics --metric disk-io如果IO使用率超过90%需要先降低一些低优先级任务的IO权重或者扩容存储。情况四调度器死锁。这个很少见但发生过。多个任务互相等待对方释放资源导致死锁。Crater的调度器有一个死锁检测机制默认30秒检测一次。如果检测到死锁会自动驱逐一个低优先级任务来打破死锁。如果死锁检测没生效可以手动重启调度器kubectl rollout restart deployment/crater-scheduler -n crater-system4.4 常见问题速查表问题现象可能原因排查命令解决办法GPU资源不上报device-plugin异常kubectl logs -l appcrater-device-plugin重启device-plugin任务OOM被杀显存配额不足crater job metrics job-xxx调大配额或batch size任务排队不动配额满/亲和性不满足crater quota get调整配额或约束调度延迟高extender调用超时kubectl logs -l appcrater-scheduler增加scheduler副本磁盘IO瓶颈IO配额打满crater cluster metrics调整IO权重训练任务被频繁抢占优先级设置过低crater job describe提高优先级或关闭抢占推理延迟波动大CPU NUMA绑定失效numactl -H检查NUMA配置5. 算力平台后续扩展的几个方向这套平台搭起来之后不是就完事了。根据我的经验后续有几个方向可以继续做深。第一个方向是算力计量和成本分摊。现在平台能管资源但还没法精确计量每个任务用了多少算力、折算成多少钱。Crater的metrics collector已经采集了GPU利用率、显存使用量这些数据可以基于这些数据做一个计费模型。比如按GPU秒计费或者按显存GB秒计费。这个功能对于多部门共用集群的场景特别重要没有计量就没有成本意识大家会无节制地申请资源。第二个方向是模型仓库和推理服务的集成。现在提交推理任务需要自己指定镜像和模型路径比较原始。可以做一个模型仓库算法同学把训练好的模型注册进去推理任务直接从仓库拉模型。再进一步可以做一个推理服务的管理界面支持一键部署、灰度发布、自动扩缩容。这块跟KServe或者Triton集成一下就能做不用从头造轮子。第三个方向是训练任务的自动调参和资源推荐。现在资源画像是基于历史任务的对于新类型的任务推荐可能不准。可以引入一些自动调参的工具比如Optuna或者Ray Tune让平台在训练过程中自动调整超参数和资源配比。这个方向比较前沿但已经有团队在做了。第四个方向是异构硬件的支持。现在主要支持NVIDIA GPU但国产芯片比如昇腾、寒武纪也在快速追赶。Crater的device-plugin架构是插件化的理论上可以扩展支持其他厂商的芯片。不过这块工作量不小需要针对每种芯片写device plugin和调度逻辑。提示扩展方向不要贪多先把计量和模型仓库做好这两个是刚需。自动调参和异构硬件可以等平台稳定运行半年后再考虑。我个人在实际操作中的体会是算力平台这件事技术方案只占30%剩下70%是运营。你得让算法同学愿意用、用得顺手平台才有价值。如果平台做得再先进但提交任务比他们自己SSH到机器上跑还麻烦那没人会用。所以Crater这套东西最大的价值不是技术多牛而是它把算力申请这件事标准化了、自助化了。算法同学不用再找运维开机器运维不用再手动配环境大家都省事。最后再分享一个小技巧Crater的调度器支持自定义调度策略插件。如果你有特殊的调度需求比如“同一个租户的任务尽量打散到不同节点”或者“训练任务优先调度到NVLink带宽最高的节点”可以写一个Go插件挂到调度器上。插件的接口在Crater的开发者文档里有说明编译成so文件后放到调度器的插件目录重启调度器就能生效。这个能力对于有特殊需求的团队很有用不用改Crater的源码。