KubeVirt 的 kind-dra 开发环境：在 Kind 集群中预置 DRA 支持的快速上手指南

• 云原生

导读

本文讲解 KubeVirt 开源仓库中kubevirtci子系统提供的kind-dra集群 Provider：一套预置了 Kubernetes 动态资源分配（Dynamic Resource Allocation，DRA）能力、基于 kind 与 pkg/dra 源码 理解其工作原理。

一、kind-dra 是什么

kind-dra是 KubeVirt 的 kubevirtci 集群方案族中的一个 Provider，位于仓库的kubevirtci/cluster-up/cluster/kind-dra/目录。它的目标正如目录内 README.md 开篇所述：

K8S with support for dra-example-driver in a Kind cluster

它基于 kind 在本地拉起一个预部署的 Kubernetes 集群，并额外开启 DRA 相关特性（feature gate 与resource.k8s.io/v1beta1runtime-config）。其核心特点包括：

• 完全临时（ephemeral）：集群在每次重启时都会重建，适合作为 CI/本地开发的隔离环境；
• 本地镜像仓库：KubeVirt 容器镜像在本地机器上构建后，被推送/拉取自暴露在localhost:5000的 registry；
• 按需选型：通过环境变量KUBEVIRT_PROVIDER选择具体的 kind 版本 Provider（当前目录对应kind-1.34系列）。

该目录内除 README 外还包含实际驱动集群创建的五个文件：provider.sh（Provider 入口脚本）、kind.yaml（kind 集群配置，含 DRA feature gate）、version（kind 二进制版本）、image（kindest/node 节点镜像）、conformance.json（sonobuoy 配置）。

二、启动集群

2.1 前置条件与基本命令

启动 kind-dra 集群需要以 root 身份执行（README 明确要求 "The following needs to be executed as root"）。同时，KUBEVIRT_PROVIDER的取值需要参照目录名来确定 kind 版本，当前目录对应kind-1.34：

export KUBEVIRT_PROVIDER=kind-1.34 make cluster-up

执行后，provider.sh中的up()函数会被调用：它先把kind.yaml复制到 kubevirtci 的 config 目录，追加端口映射（若有KIND_PORT_MAPPING），然后进入通用的kind_up流程（见 common.sh）：下载对应版本的 kind 二进制、准备并回显最终 kind 配置、创建集群、等待节点与 DNS 就绪、启动本地 registry、为各节点配置 insecure registry 与网络等。

2.2 访问集群

集群启动后，使用 kubevirtci 自带的kubectl.sh即可访问，无需额外安装 kubectl：

$ cluster-up/kubectl.sh get nodes NAME STATUS ROLES AGE kind-1.34-control-plane Ready master 6m14s

从 provider.sh 可以看到默认集群名为kind-1.34-dra，它同时决定了本地 registry 的宿主机端口映射：

• 默认集群名kind-1.34-dra→HOST_PORT=5000（即 README 中提到的localhost:5000）；
• 使用其他自定义CLUSTER_NAME时 → 自动切换到备用端口5001，避免多个集群共存时端口冲突。

2.3 关闭集群

make cluster-down

该命令会销毁整个集群（包括节点容器与本地 registry 容器）。注意 README 的提示：使用make cluster-down前请确保导出了正确的CLUSTER_NAME。从 common.sh 的 down() 可以看到，销毁逻辑会先按集群名查找 kind 集群，处理 worker 节点的 VF 网卡挂载（若有），再执行kind delete cluster，并清理 registry 容器与生成的 kind.yaml。

三、自定义 kind 版本与节点镜像

如果你需要测试较新的 kind / Kubernetes 版本，或使用自定义镜像，可以在执行cluster-up前导出两个环境变量：

export KIND_NODE_IMAGE="kindest/node:v1.19.1@sha256:98cf5288864662e37115e362b23e4369c8c4a408f99cbc06e58ac30ddc721600" export KIND_VERSION="0.9.0"

provider.sh中的set_kind_params()会优先采用这些显式设置，否则回退到目录内version与image文件中的默认值：

function set_kind_params() { version=$(cat "${KUBEVIRTCI_PATH}/cluster/$KUBEVIRT_PROVIDER/version") export KIND_VERSION="${KIND_VERSION:-$version}" image=$(cat "${KUBEVIRTCI_PATH}/cluster/$KUBEVIRT_PROVIDER/image") export KIND_NODE_IMAGE="${KIND_NODE_IMAGE:-$image}" }

当前仓库中 kind-dra 的默认值是：

• kind 版本：0.31.0（见 version）
• 节点镜像：kindest/node:v1.34.3@sha256:08497ee19eace7b4b5348db5c6a1591d7752b164530a36f855cb0f2bdcbadd48（见 image），对应 Kubernetes 1.34.3

这种方式允许开发者在把新 kind 版本正式合入官方清单之前，先使用自定义镜像或不同 kind 版本进行验证。kind 各版本对应的节点镜像关系可在 kind 官方 release 中查询。

四、DRA 特性在集群配置中的落地

kind-dra 之所以能支持 DRA 相关开发与测试，关键在 kind.yaml 中的几处配置，它们共同构成了一个适配 KubeVirt DRA 测试的集群骨架：

kind: Cluster apiVersion: kind.x-k8s.io/v1alpha4 featureGates: DynamicResourceAllocation: true nodes: - role: control-plane kubeadmConfigPatches: - |- kind: JoinConfiguration nodeRegistration: kubeletExtraArgs: "feature-gates": "CPUManager=true" "cpu-manager-policy": "static" "kube-reserved": "cpu=500m" "system-reserved": "cpu=500m" - |- kind: ClusterConfiguration apiServer: extraArgs: runtime-config: "resource.k8s.io/v1beta1=true" scheduler: extraArgs: v: "1" controllerManager: extraArgs: v: "1" - |- kind: InitConfiguration nodeRegistration: kubeletExtraArgs: v: "1" extraMounts: - containerPath: /var/log/audit hostPath: /var/log/audit readOnly: true

逐项解读这些配置在 DRA 测试中的意义：

• featureGates.DynamicResourceAllocation: true：在集群层面开启 DRA 特性门控，让resource.k8s.ioAPI 组与相关控制器生效——这是 KubeVirt 使用 ResourceClaim 直通 GPU/主机设备的前提。
• kubelet 的CPUManager=true+cpu-manager-policy: static：开启 CPU 管理器静态策略，并保留kube-reserved/system-reserved各 500m CPU。这与provider.sh中CONFIG_WORKER_CPU_MANAGER=true的导出配合，保证节点具备可预测的 CPU 分配能力，是部分涉及 CPU 固定/拓扑的 DRA 与性能测试所需。
• API Server 的runtime-config: "resource.k8s.io/v1beta1=true"：显式启用resource.k8s.io/v1beta1的 runtime 配置，确保该 API 版本可用。
• scheduler / controllerManager 的v: "1"：提高 kube-scheduler 与 controller-manager 的日志级别，便于调试 DRA 调度与资源控制器行为。
• extraMounts挂载/var/log/audit：只读挂载宿主机审计日志目录，供审计/观测类测试使用。

值得注意：kind-dra 默认是单 control-plane 节点集群（kind.yaml 未声明 worker 节点）。若要扩容 worker，可由common.sh的_add_workers()按KUBEVIRT_NUM_NODES动态追加，且当CONFIG_WORKER_CPU_MANAGER=true时（kind-dra 的provider.sh正是如此设置）worker 也会附带 CPU manager 静态策略补丁。

五、DRA 在 KubeVirt 侧的用法示例

kind-dra 集群主要为 KubeVirt 的 DRA 功能提供测试环境。KubeVirt 侧对 DRA 的使用集中在vmi.spec.resourceClaims与domain.devices.gpus/hostDevices的配合上，仓库提供了可直接参考的示例 examples/vmi-dra-pgpu.yaml：

apiVersion: kubevirt.io/v1 kind: VirtualMachineInstance metadata: name: vmi-dra-pgpu spec: domain: devices: gpus: - claimName: pgpu-resource-claim name: example-gpu requestName: pgpu memory: guest: 1024M resourceClaims: - name: pgpu-resource-claim resourceClaimTemplateName: pgpu-resource-claim-tmpl volumes: - containerDisk: image: registry:5000/kubevirt/fedora-with-test-tooling-container-disk:devel name: containerdisk

该示例演示了：VMI 通过resourceClaims引用一个pgpu-resource-claim-tmpl模板创建的 ResourceClaim，GPU 设备段通过claimName+requestName从该 claim 中请求pgpu资源——容器镜像地址registry:5000/kubevirt/...正是对应 kind-dra 集群暴露的本地 registry（localhost:5000），与 README 描述一致。

在实现层面，KubeVirt 的 DRA 准入校验位于 pkg/dra/admitter/dra_admitter.go，它强制约束了resourceClaims的合法性：

• 必须指定resourceClaimName或resourceClaimTemplateName之一，且不能同时指定（见validateResourceClaims，第 145-157 行）；
• claim 名称必须是合法的 DNS 子域名（第 159-164 行）；
• vmi.spec.resourceClaims必须覆盖domain.devices.gpus与domain.devices.hostDevices中使用的所有 claim（第 101-109 行）。

因此，在 kind-dra 集群上编写 DRA 相关 VMI 时，务必让 GPU/hostDevices 中引用的claimName全部出现在resourceClaims列表中，否则创建会被拒绝。

六、与其他 kind Provider 的关系与选型

kind-dra 并非 kubevirtci 唯一的 kind 类 Provider。在 kubevirtci/cluster-up/cluster/ 下还有kind/、kind-1.35/、kind-1.36/、kind-1.37/、kind-ovn/、kind-1.37-vgpu/等目录。它们共享 common.sh 中的通用逻辑（kind 下载、集群创建、registry 配置、CNI 安装、节点标签修复等），差异点主要在：

• kind.yaml 的集群能力：如 kind-dra 开启DynamicResourceAllocation特性门控与resource.k8s.io/v1beta1runtime-config；kind-ovn 则侧重 OVN 网络；
• 默认版本：version与image文件内容不同；
• provider.sh 的额外配置：如 kind-dra 强制CONFIG_WORKER_CPU_MANAGER=true。

选型建议：当你的开发/测试目标涉及 DRA（如 GPU 直通、ResourceClaim）时，优先选择KUBEVIRT_PROVIDER=kind-1.34（即 kind-dra）；若仅需普通网络场景或 OVN 场景，则选择kind或kind-ovn系列。

七、常见问题与注意事项

1. 必须以 root 执行：README 明确要求 root 权限运行make cluster-up，否则容器与网络操作可能失败。
2. 集群完全临时：每次重启都会重建集群，节点上未持久化的数据不会保留；如需保留调试现场，可关注common.sh中 kind 创建时使用的--retain参数与 CI 镜像代理配置（configure_registry_proxy，仅在 CI 环境生效）。
3. 端口冲突处理：默认集群占用宿主机5000端口（registry），多集群场景请使用自定义CLUSTER_NAME，provider.sh会自动切换到5001。
4. make cluster-down需要CLUSTER_NAME：务必先导出与创建时一致的CLUSTER_NAME，否则销毁逻辑可能定位不到目标集群。
5. DRA 需要配套驱动：kind-dra 仅提供开启 DRA 特性的集群骨架；真正分配资源的dra-example-driver等设备驱动需按测试需要额外部署，KubeVirt 侧只负责通过resourceClaims消费 ResourceClaim。

总结

kind-dra 是 KubeVirt kubevirtci 体系中为 DRA 功能量身定制的本地 kind 集群 Provider：一条make cluster-up命令即可获得开启DynamicResourceAllocation特性门控、启用resource.k8s.io/v1beta1、并带本地镜像 registry（localhost:5000）的临时 Kubernetes 1.34 集群。配合KIND_NODE_IMAGE/KIND_VERSION环境变量可以灵活切换集群版本，配合 examples/vmi-dra-pgpu.yaml 与 pkg/dra 的准入校验代码，开发者可以在本地快速验证 KubeVirt 的 DRA 资源消费流程，为后续 CI 与端到端测试铺平道路。

• 云原生