开源组件定制-智能计算灵骏(LINGJUN)-阿里云帮助中心

灵骏 Runtime Kit 容器层组件开源，用户可基于源码定制资源名、调度策略、监控指标与节点开关行为。内容涵盖源码结构、编译构建、部署衔接与定制边界。

说明

公测中：本产品当前处于公测阶段，如有问题或建议，请联系灵骏技术支持。

1. 源码获取

开源组件代码发布在 GitHub 仓库 aliyun/LJ-RuntimeKit，各组件以独立子目录提供：

组件	源码位置	主要定制方向
Device Plugin	`LJ-RuntimeKit-Device-Plugin`	资源名定制、显存切分粒度
Scheduler Framework	`LJ-RuntimeKit-Scheduler-Framework`	调度打分策略、资源建模、K8s 版本适配
Exporter	`LJ-RuntimeKit-Exporter`	自定义指标
Controller（开关控制）	`Controller` 组件目录	标签监听逻辑、节点操作行为

分支与 Tag 约定：

main 分支始终保持最新可用代码；
Tag 为稳定版本入口，开源组件版本与 Runtime 版本保持跟随对应。

2. 编译构建与镜像制作

各组件在对应源码目录根下通过 Makefile 构建：

make build     # 编译二进制文件
make docker    # 构建镜像

其他构建目标详见各组件目录下的 Makefile。构建完成后，将镜像推送至集群节点可拉取的仓库，并确保部署清单中的镜像名称、Tag 与实际构建产物一致（部署文件与镜像配置说明详见3.6 进阶部署与定制）。

Scheduler Framework 的多 Kubernetes 版本适配

Scheduler Framework 以 out-of-tree 插件方式编译，依赖 k8s.io/kubernetes 及其 staging 子模块。开源仓 hack/ 目录提供脚本，用于切换目标 K8s 版本：

# 1. 切换依赖到目标 K8s 版本（例如 v1.28.0）
./hack/download-deps.sh v1.28.0

# 2. 更新 vendor 目录
go mod tidy && go mod vendor

# 3. 编译验证
make build

当前默认依赖 Kubernetes v1.21.2，可按上述步骤适配其他版本。编译依赖版本应与目标集群版本保持一致，避免 API 兼容性问题。预编译镜像当前支持的社区 Kubernetes 版本为：v1.28、v1.30、v1.32、v1.34、v1.35。

3. 部署衔接

定制完成后的部署方式与预编译组件一致：

一键部署：Scheduler Framework 仓库提供统一脚本 deploy/deploy-all.sh，支持全部或按组件部署（--components=<name>），可覆盖镜像地址、namespace 等参数；
组件级部署：各组件也支持自身部署方式（make deploy、Helm Chart、kustomize 等）；
版本兼容：定制组件与 Runtime 的对接契约仍是 gRPC 接口，版本兼容政策与最低版本要求同样适用，详见5. 版本兼容说明、6. 功能最低版本要求。
配置级定制（无需重新编译）：Device Plugin、Scheduler Framework、Exporter 三个组件的部署清单中均包含独立配置文件（configmap.yaml），将扩展资源名、节点标签 key、annotation key 等协议常量外置为 ConfigMap。如仅需修改资源名称等配置项而不涉及代码逻辑，可直接编辑对应 ConfigMap 后重新部署，无需重新编译镜像。注意：三个组件使用同一套协议常量，配置不一致会导致资源上报、调度与监控使用的资源名对不上，Pod 可能无法调度或监控缺失。示例——修改 gpu-core 与 gpu-memory 的资源名：
```
  protocol.yaml: 
    resources.memory: "alibabacloud.com/gpu-memory.percentage"
    resources.core: "alibabacloud.com/gpu-core.percentage"
    resources.gpu: "alibabacloud.com/gpu"
```
修改位置与生效方式：上述配置位于 Scheduler Framework 组件一键部署 deploy 目录下各组件的 ConfigMap 文件中——deploy/<组件>/02-configmap.yaml。修改完成后，依次对三个组件执行 kubectl apply -f 更新 ConfigMap，再重启对应的 DaemonSet / Deployment 使新配置生效：
```
# 1. 更新三个组件的 ConfigMap
kubectl apply -f deploy/deviceplugin/02-configmap.yaml
kubectl apply -f deploy/exporter/02-configmap.yaml
kubectl apply -f deploy/scheduler/02-configmap.yaml

# 2. 重启组件使新配置生效
kubectl rollout restart ds/lj-runtimekit-device-plugin-ds -n kube-system
kubectl rollout restart ds/lj-runtimekit-exporter-ds -n kube-system
kubectl rollout restart deploy/lj-runtimekit-scheduler-framework -n kube-system
```
也可直接通过 deploy-all.sh deploy 统一重新部署，效果相同。

定制组件由用户自行维护，后续升级须将定制变更与新版本基线自行合并。

4. 各组件源码结构与扩展点

4.1 Device Plugin

源码结构：

目录/文件	职责
`cmd/main.go`	程序入口，初始化 gRPC 连接与 Plugin 注册
`internal/plugin/`	Device Plugin 核心逻辑（ListAndWatch、Allocate 转发）
`internal/grpc/`	Proto 定义与 gRPC Client 封装
`internal/utils/`	常量定义（socket 路径、资源名等）

扩展点：

自定义资源名：扩展资源名（如 aliyun.com/gpu-core）可通过配置文件覆盖默认值，便于多集群命名隔离或对接已有命名规范。修改后须同步更新 Device Plugin、Scheduler Framework、Exporter 三个组件的配置，确保资源名一致；
显存切分粒度：默认 1 GiB，可通过启动参数 --memory-unit 调整，适配不同显存规格的 GPU。

4.2 Scheduler Framework

源码结构：

目录/文件	职责
`cmd/scheduler/main.go`	程序入口，注册调度插件
`pkg/standard/`	StandardPlugin —— 时分调度（Filter/Score/Reserve/Bind）
`pkg/mig/`	MigPlugin —— MIG 空分调度
`pkg/utils/`	常量定义（调度策略名、资源标签等）
`pkg/utils/noderesource.go`	节点 GPU 资源账本结构
`helm/`	Helm Chart（values.yaml 含调度器配置）

扩展点：

调度插件扩展：pkg/ 下的 StandardPlugin（时分调度）与 MigPlugin（MIG 空分调度）均基于 Scheduler Framework 的 Filter/Score/Reserve/Bind 钩子实现，可在此基础上扩展自定义打分策略或亲和性约束；
资源建模扩展：Scheduler 启动时通过 informer 监听 Node、Pod 与 Device Plugin 上报，为每个 Node 维护 gpuCount × {core, memory} 多维资源账本；分配时原子扣减，Pod 删除时通过事件回流恢复账本。如需增加新的资源维度，可在账本结构上扩展。

4.3 Exporter

源码结构：

目录/文件	职责
`cmd/exporter/main.go`	程序入口
`pkg/collector/`	gRPC 客户端采集逻辑（调用灵骏 Runtime Kit 接口获取指标）
`pkg/exporter/`	Prometheus 指标转换与 HTTP 暴露
`pkg/detector/`	健康检测逻辑
`deployment/`	Helm Chart 部署模板
`etc/`	配置文件模板

扩展点：

自定义指标：在 pkg/collector/ 中扩展新的指标采集逻辑，通过 gRPC 接口 ExporterGetDataList 获取原始数据后转换为 Prometheus 指标。

4.4 Controller（开关控制）

源码结构：

Controller/
├── cmd/
│   ├── controller/main.go       # Controller 主程序（Kubebuilder 框架）
│   └── job-agent/main.go        # Job Agent（节点上执行启用/禁用）
├── internal/controller/
│   ├── node_controller.go       # 监听 Node 标签变化，创建 Job
│   └── job_controller.go        # 自动清理成功的 Job
├── api/proto/
│   └── config_service.proto     # gRPC 接口定义
├── pkg/configpb/                # 生成的 Go gRPC 代码
└── config/manager/              # 部署配置

扩展方向：

修改 node_controller.go 可自定义标签监听逻辑或触发条件（默认为监听 lj_runtimekit_enable=true）；
修改 job-agent/main.go 可自定义节点上的操作行为；
修改 config_service.proto 可扩展与节点 config-daemon 的通信协议（接口详情见gRPC接口参考）。

5. 定制边界与注意事项

gRPC 接口是唯一的对接边界。只要不改动组件与灵骏 Runtime Kit 交互的部分，就无需关心 proto 细节，定制范围限于组件自身策略（调度、监控、编排、存储等）；一旦需要修改或重新实现与 Runtime 的交互，请以gRPC接口参考为协议基础，并遵循其中的兼容性政策；
资源名一致性：自定义资源名前缀时，Device Plugin、Scheduler Framework、Exporter 三个组件须同步修改，否则资源上报与调度会不匹配。轻量场景下可编辑各组件部署清单中的协议 ConfigMap 统一修改（见第 3 节），无需重新编译；涉及代码逻辑变更时须修改源码中的常量定义并重新构建镜像。
版本兼容同样适用：定制组件与 Runtime 之间仍遵循"只增不改、向后兼容"的接口政策，功能最低版本要求对定制实现同样有效（详见5. 版本兼容说明、6. 功能最低版本要求）。
维护责任：定制组件由用户自行维护；后续基线升级时，用户须自行将定制变更与新版本合并。问题归属与支持渠道详见部署与版本指南。