Kubernetes 动态资源分配（DRA）端到端测试指南：Kind 集群搭建、代理式测试驱动与 e2e 运行全流程

Kubernetes 动态资源分配DRA端到端测试指南Kind 集群搭建、代理式测试驱动与 e2e 运行全流程【免费下载链接】kubernetesProduction-Grade Container Scheduling and Management项目地址: https://gitcode.com/GitHub_Trending/kuber/kubernetes动态资源分配Dynamic Resource AllocationDRA是 Kubernetes 面向可插拔异构硬件GPU、加速器、FPGA 等的新一代资源管理模型由第三方驱动通过 gRPC 与 kubelet 协作将设备以 ResourceClaim 形式供给 Pod。本文聚焦 Kubernetes 仓库内真实的一线验证手段——test/e2e/dra端到端测试套件说明它如何在不额外制作驱动镜像的前提下用代理式测试驱动在 e2e 二进制内完整驱动 kubelet 与 DRA 控制面并给出从 CDI/Kind 集群搭建、节点镜像构建到 ginkgo 聚焦运行的完整可复现流程。读完你可以独立搭起一套 DRA 端到端测试环境并理解测试驱动与控制器、kubelet 插件之间的底层调用契约。测试套件的定位验证 Kubernetes 的 DRA 能力而非第三方驱动仓库 test/e2e/dra/README.md 开篇即划定了边界该目录下的测试覆盖的是 Kubernetes 对动态资源分配的支持行为并不负责验证任意第三方 DRA 驱动的正确性。也就是说这套测试关心的是调度器、kube-apiserver、kubelet、DRA 控制面组件彼此配合是否符合预期而不是某个厂商设备驱动是否实现了规范。从目录结构可以清楚看到该套件的组成test/e2e/dra/dra.go主测试文件体量很大包含 DeviceClass、ResourceClaim、分配生命周期等大量用例test/e2e/dra/health.go针对 kubelet 与驱动之间 DRAResourceHealth gRPC 接口及其在 Pod 状态中反映的设备健康用例test/e2e/dra/kind.yaml用于拉起测试集群的 Kind 配置test/e2e/dra/utils测试基建节点选取、驱动部署、对象构建test/e2e/dra/test-driver随测试一起构建的示例 DRA 驱动它本身就是一个可运行的二进制与一组参考部署清单。由于 kubelet 侧要有真实的设备分配行为发生这套测试全部依赖容器运行时的CDIContainer Device Interface支持来把虚拟设备注入容器而不是简单地在 API 层模拟。核心设计把 DRA 测试驱动代理进 e2e.test 进程DRA 测试需要一个驱动但驱动以 DaemonSet/Deployment 部署到集群会带来两个问题需要为测试专门维护容器镜像且测试难以精确操纵、检查驱动与 kubelet 之间每一次 gRPC 往返。test/e2e/dra的做法是复用 CSI mock 测试积累的代理技术把驱动本体搬进 e2e 测试进程内部集群中只运行一个用于打通 socket 通道的代理容器ReplicaSet 形式部署清单见 test/e2e/testing-manifests/dra/dra-test-driver-proxy.yaml。它复用registry.k8s.io/sig-storage/hostpathplugin镜像——该镜像本身就具备 csi-driver-host-path 的代理模式、基础镜像自带 shell便于写文件而且已经是 e2e.test 的既有依赖因此无需为 DRA 测试引入任何新镜像代理容器把 kubelet 所需的两个 socket 目录插件数据目录/var/lib/kubelet/plugins/driver与注册目录/var/lib/kubelet/plugins_registry以及 CDI 目录/var/run/cdi以 hostPath 挂载出来清单以test-driver.dra.k8s.io为例容器在集群内只是躺着负责转发e2e 测试进程内依赖 test/e2e/storage/drivers/proxy 目录的既有实现真正运行起 DRA 驱动的 kubelet 插件与注册逻辑直接面对转发过来的 gRPC 流。这套proxy into e2e.test设计带来的直接收益正如 README 所述测试对全部 gRPC 调用拥有完整控制权可以按需注入错误、精确断言某个方法是否被调用、调用了几次。例如health.go中通过driver.CallCount(...)断言 kubelet 究竟在v1还是v1alpha1版本的DRAResourceHealth_NodeWatchResources上订阅了健康流并校验另一个版本调用数为零见 test/e2e/dra/health.go。在 test/e2e/dra/utils/deploy.go 的Driver.SetUp中可以追到更具体的装配细节每个被选中节点上的代理 Pod 就绪后测试在进程内为每个节点启动一个app.ExamplePluginkubelet 插件实现并通过 gRPC 拦截器GRPCInterceptor/GRPCStreamInterceptor记录或注入失败Driver持有fail与callCounts两张表插件向 kubelet 注册使用与真实 DaemonSet Pod 完全一致的凭据测试构造出该 Pod ServiceAccount 的 UserInfo 后通过impersonation用户伪装访问 API从而让进程内驱动享有与集群内 DaemonSet Pod 完全相同的 RBAC 权限与准入约束插件数据目录按kubeletRootDir/plugins/driverName计算驱动名默认由测试命名空间派生namespace[后缀].k8s.io。测试驱动test-driver单一二进制同时扮演控制器与 kubelet 插件在真实产品中DRA 驱动通常拆成两个部分集群内的控制器负责给 ResourceClaim 做分配决策kubelet 插件负责在节点上准备/回收设备。仓库内置的测试驱动 test/e2e/dra/test-driver/README.md 说明它把两者合并进一个二进制以减少样板代码而真实驱动完全可以选择不同二进制分别部署控制器可作为 Deployment 并带 leader electionkubelet 插件用 DaemonSet控制器也可以作为集群外的客户端运行。其分层复用关系很典型二进制本体是基于 Cobra 的命令提供controller与kubelet-plugin两个子命令日志采用与 Kubernetes 一致的 contextual logging 风格控制器侧复用 staging 中通用包 staging/src/k8s.io/dynamic-resource-allocation 的controller子包它实现了与 ResourceClaim 的完整交互只把真正属于驱动逻辑的部分抽象成接口交给 test/e2e/dra/test-driver/app 里的示例实现kubelet 插件侧同样复用该目录下kubelet-plugin子包处理与 kubelet 的注册、NodePrepareResources/NodeUnprepareResources 等交互app仅提供极简的接口实现kubeletplugin.go、options.go、server.go。该测试驱动的功能刻意保持简单但行为足以模拟真实驱动的各种拓扑其关键设计来自 test-driver 自己的文档与 test/e2e/dra/utils/builder.go 的构建器代码包括参数透传与容器环境注入驱动参数是存放在 ConfigMap 里的 key/value 字符串对控制器把它们以 JSON map 形式写入ResourceClaimStatus的ResourceHandle字段其中来自 ResourceClaim 的参数加user_前缀、来自 DeviceClass 的参数加admin_前缀kubelet 插件随后把user_/admin_变量注入到每个使用该资源的容器环境变量中。e2e 用例正是通过进入容器执行env、按正则^(?:admin|user|claim)_...匹配来断言注入结果资源可用性可配置用于模拟多种场景网络附属资源所有运行节点驱动的节点都可用vs 主机本地资源只在被分配节点可用共享可被多次分配vs 非共享无限制 vs 有限额限额就是每个集群/节点允许的分配次数这一简单数字。utils 中提供了DriverResources(...)、NetworkResources(...)、ShareableResources(...)、PartitionableResources(...)等生成器来构造这些资源拓扑代码虽然功能有限但刻意示范了最佳实践暴露 metrics、支持 leader election、支持与 Kubernetes 相同的日志选项参考自 external-resizer 的控制器逻辑。运行前提CDI 与 Kind 版本要求DRA 的端到端测试要求容器运行时能理解 CDI 注入的设备README 明确给出版本下限CRI-O1.23 起支持 CDIContainerd1.7 起支持 CDI。测试官方建议用 Kind 拉起带 Containerd 的多节点集群并对 Kind 提出要求Kind 从 0.20 版本开始默认采用内置 Containerd 1.7 的 worker 节点基础镜像因此请使用 Kind 0.20 及以上的 release 二进制或直接从最新 main 分支构建 Kind。Kubernetes 侧则需要先从源码树构建好二进制。集群配置逐段解读test/e2e/dra/kind.yaml拉起集群的配置模板 test/e2e/dra/kind.yaml 是理解需要打开哪些开关的第一手资料runtimeConfig显式启用了多组 API 服务resource.k8s.io/v1alpha3、resource.k8s.io/v1beta1、resource.k8s.io/v1beta2DRA 资源 API 的多个演进版本共存以及scheduling.k8s.io/v1beta1调度组相关 APIcontainerdConfigPatches通过 patch 打开 CRI 插件的enable_cdi true这是让 containerd 识别 CDI 注入文件的关键开关拓扑为 1 个 control-plane 3 个 worker 节点多数用例需要多个可调度节点来验证拓扑约束、分配冲突等kubeadmConfigPatches同时为旧v1beta3覆盖 v1.23.x 起的老集群与新v1beta4面向 v1.35.0 的未来版本两种 kubeadm 配置格式打开高等级调试日志scheduler 侧开启allocator*、pools*、dynamicresources、allocateddevices、dra_manager、extendeddynamicresources模块的 vmodule6对应 DRA 调度插件与pkg/scheduler/framework/...内的结构化分配器controller-manager 侧开启controller6对应 resourceclaim 控制器;featureGates兜底开启DynamicResourceAllocation注释说明仍需要对 kubelet 1.33 的 n-3 兼容测试待只针对 1.34 后可移除与NodeLogQueryn-3/2/1 兼容测试所需待只针对 1.36 后可移除。部分 Prow CI 作业还会以追加--config (cat test/e2e/dra/kind.yaml; echo ...)的方式临时加开更多特性门控——因此注释专门提醒特性门控必须放在 YAML 最后。搭建环境构建节点镜像并创建 Kind 集群先在 Kubernetes 源码树内构建好产物随后构建一个包含本地 Kubernetes 二进制的 Kind 节点镜像$(pwd)即源码根目录$ kind build node-image --image dra/node:latest $(pwd)然后用仓库自带的集群配置创建集群$ kind create cluster --config test/e2e/dra/kind.yaml --image dra/node:latest运行 DRA 端到端测试首先构建 ginkgo 测试执行器$ make ginkgo然后针对Dynamic Resource Allocation特性运行 e2e 测试KUBECONFIG指向 Kind 生成的 kubeconfig$ KUBECONFIG~/.kube/config _output/bin/ginkgo -p -v -focusFeature:DynamicResourceAllocation ./test/e2e-p启用并行-v输出详细日志-focus用 ginkgo 正则只挑选 DRA 相关用例。除此之外test/e2e/dra/dra.go 中的注释还揭示了套件内部的标签/分组约定所有用例注册在SIGDescribe(node)下并打上WithLabel(DRA)标签可直接用 ginkgo 标签过滤用例分成两大类以control plane开头的子用例只验证控制面组件不依赖 kubelet 的 DRA 支持可在没有真实插件的情况下运行以kubelet开头的子用例依赖 kubelet 与插件会真实拉起 Pod驱动容器需要足够权限修改/var/lib/kubelet/plugins因此测试命名空间被设为PrivilegedNamespacePodSecurityLevel admissionapi.LevelPrivileged套件内含大量符合 conformance 规范的 CRUD 用例如对resource.k8s.io/v1 DeviceClass的 create/update/list/patch/delete以及多 API 版本v1、v1beta1、v1beta2、v1alpha3下的 claim/分配回归测试等待 Pod 启动的默认超时为 5 分钟podStartTimeout。设备健康方向test/e2e/dra/health.go 单独验证了一条较新的链路kubelet 以NodeWatchResources流订阅驱动的设备健康上报测试通过驱动插件的控制通道把健康状态在Healthy - Unhealthy - Healthy之间切换并断言 Pod 状态AllocatedResourcesStatus中的claim:资源随之更新同时按 kubelet 版本健康 API v1 自 kubelet 1.37 起1.36 仅 v1alpha1校验协商出的 gRPC API 版本与调用计数。单节点本地快速试跑local-up-cluster.sh如果不想起多节点集群test-driver 的文档还给出了基于 hack/local-up-cluster.sh 的本地单节点演练路径适合先跑通驱动 - 分配 - 容器拿到设备的完整链路第一个终端启动本地控制面与 kubelet打开 DRA 特性门控与 v1alpha3 运行时配置RUNTIME_CONFIGresource.k8s.io/v1alpha3 FEATURE_GATESDynamicResourceAllocationtrue ALLOW_PRIVILEGED1 ./hack/local-up-cluster.sh -O第二个终端先准备好 CDI、kubelet 插件与注册目录并赋予权限然后直接在本地以go run启动驱动的 kubelet 插件子命令sudo mkdir -p /var/run/cdi sudo mkdir -p /var/lib/kubelet/plugins/test-driver.cdi.k8s.io sudo mkdir -p /var/lib/kubelet/plugins_registry sudo chmod arx /var/lib/kubelet /var/lib/kubelet/plugins sudo chmod arwx /var/run/cdi /var/lib/kubelet/plugins_registry /var/lib/kubelet/plugins/test-driver.cdi.k8s.io KUBECONFIG/var/run/kubernetes/admin.kubeconfig go run ./test/e2e/dra/test-driver -v5 kubelet-plugin --node-name127.0.0.1随后导入示例对象并观察分配结果以下输出为 test-driver 文档记录的真实运行样例$ export KUBECONFIG/var/run/kubernetes/admin.kubeconfig $ kubectl create -f test/e2e/dra/test-driver/deploy/example/deviceclass.yaml resourceclass/example created $ kubectl create -f test/e2e/dra/test-driver/deploy/example/pod-inline.yaml configmap/pause-claim-parameters created pod/pause created $ kubectl get resourceclaims NAME CLASSNAME STATE AGE pause-resource example allocated,reserved 19s $ kubectl get pods NAME READY STATUS RESTARTS AGE pause 1/1 Running 0 23s注意仓库中 test/e2e/dra/test-driver/deploy/example 目录下的示例清单已随 API 演进多次调整当前已包含DeviceClass/ResourceClaimTemplate样式的 deviceclass.yaml 与 pod-inline.yaml 等上文的资源名/输出是较早版本的运行记录但整个流程语义不变创建 DeviceClass示例用 CEL 选择器device.driver test-driver.cdi.k8s.io→ 提交引用该 class 的 Pod/模板 → 控制器为 claim 完成分配并置为allocated,reserved→ kubelet 插件生成 CDI 文件并 prepare 设备 → Pod 进入 Running。目录中还提供了多 Pod 共享、外部 claim、多 claim 等更多场景的参考清单。值得说明的限制由于测试驱动没有发布独立容器镜像目前它无法直接部署到普通的多节点生产集群test-driver 文档明确指出了这一点这正是它配合 e2e 代理机制在 Kind/本地环境使用的根本原因。关键参考路径速查想深入这套测试的读者建议按以下顺序阅读仓库源码test/e2e/dra/kind.yaml集群运行时配置、CDI 开关与调试日志开关的一手模板test/e2e/testing-manifests/dra/dra-test-driver-proxy.yaml节点上转发 kubelet 流量的代理 ReplicaSettest/e2e/dra/utils/deploy.goDriver的进程内插件启动、RBAC/impersonation、gRPC 拦截器与失败注入基建test/e2e/dra/utils/builder.goDeviceClass/claim/Pod/Workload 的对象构建器与容器环境断言user_/admin_前缀约定test/e2e/dra/test-driver驱动二进制源码、controller/kubelet-plugin子命令与示例部署清单staging/src/k8s.io/dynamic-resource-allocation被控制器/kubelet 插件复用的通用实现未来有望抽成可独立复用的工具包。这套测试栈代表了 DRA 能力在 Kubernetes 主仓内的验收标准以 CDI 就绪的运行时为前提、以代理式驱动换取零镜像与完全可观测的 gRPC 交互是理解乃至二次开发 DRA 调度、分配与设备生命周期实现最直接的入口。【免费下载链接】kubernetesProduction-Grade Container Scheduling and Management项目地址: https://gitcode.com/GitHub_Trending/kuber/kubernetes创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考