企业官网建设流程全解析

如何用 Kind 和源码构建的节点镜像运行 Kubernetes DRA e2e 测试

【免费下载链接】kubernetesProduction-Grade Container Scheduling and Management项目地址: https://gitcode.com/GitHub_Trending/kuber/kubernetes

如果你想在本地跑一遍 Kubernetes 仓库中 Dynamic Resource Allocation（DRA，动态资源分配）的 e2e 测试，不能直接用现成的 Kind 基础镜像：这些测试要求容器运行时支持 CDI，而 Kind 默认的节点镜像不一定满足。test/e2e/dra/README.md给出的路径是：先从 Kubernetes 源码树构建二进制，再用这份源码树构建一个 Kind 节点镜像，然后用 DRA 专用的kind.yaml拉起集群，最后用 ginkgo 聚焦DynamicResourceAllocation特性运行 e2e 测试。完成这套流程后，你会得到一个带 CDI 容器运行时、开启 DRA 相关 API 与 feature gate、并打开 DRA 组件详细日志的本地集群。

准备条件

按 test/e2e/dra/README.md 的说明，需要满足以下条件：

• 容器运行时必须支持 CDI。文档给出的支持起点是：CRI-O 自 1.23 版本支持 CDI，Containerd 自 1.7 版本支持 CDI。
• 要构建一个基于 Containerd 的 Kind 集群，需要两样东西：从 Kubernetes 源码树构建的二进制文件，以及 Kind。
• 从 Kind 0.20 版本起，默认改用带 Containerd 1.7 的 worker-node 基础镜像。因此要么用 Kind 0.20 或更新的发布版二进制，要么从最新的 main 分支源码构建 Kind。

关于测试驱动有一个前提说明：这套 e2e 测试并不测试任意 DRA 驱动的正确行为。它使用仓库内树的test/e2e/dra/test-driver，但与常规部署不同——该驱动不会直接部署到集群里，而是把与 kubelet 交互所需的 socket（注册和动态资源分配）代理进e2e.test二进制内部，复用了 CSI mock 测试的工作。这样做的好处是不需要为测试驱动单独准备镜像，且 e2e 测试对所有 gRPC 调用有完全的控制权，可用于错误注入和调用检查。

第一步：从源码构建 Kubernetes 二进制

在 Kubernetes 源码树根目录执行：

$ make

make（等价于make all）构建全部代码，可执行文件输出到_output/bin目录。这一步必须在构建 Kind 节点镜像之前完成，因为节点镜像会以当前源码树为输入。

第二步：构建 Kind 节点镜像

构建完 Kubernetes 之后，仍要在 Kubernetes 源码树根目录执行：

$ kind build node-image --image dra/node:latest $(pwd)

这里$(pwd)是 shell 展开的当前目录路径，即源码树根目录，Kind 会把该目录中的源码构建成名为dra/node:latest的节点镜像。

第三步：创建 Kind 集群

$ kind create cluster --config test/e2e/dra/kind.yaml --image dra/node:latest

--image指向第二步构建的镜像，--config使用仓库中的 test/e2e/dra/kind.yaml。这个配置文件为 DRA 测试做了四件事，理解它们有助于排查问题：

1. 开启 CDI：containerdConfigPatch通过[plugins."io.containerd.grpc.v1.cri"] enable_cdi = true打开 containerd 的 CDI 支持，这是 DRA 场景的硬性前提。
2. 注册资源 API 版本：runtimeConfig打开resource.k8s.io/v1alpha3、resource.k8s.io/v1beta1、resource.k8s.io/v1beta2以及scheduling.k8s.io/v1beta1。
3. 详细日志：为排查 DRA 问题，配置里把 scheduler 的日志级别设为v=5并叠加vmodule="allocator*=6,pools*=6,dynamicresources=6,allocateddevices=6,dra_manager=6,extendeddynamicresources=6"（覆盖 DRA 调度器插件相关包），controller-manager 的vmodule="controller=6"（对应 ResourceClaim 控制器），kubelet 设为v=5。文件同时包含 kubeadmv1beta4与v1beta3两套配置变体，注释说明是为了兼容不同版本 Kind 的切换。
4. feature gate：末尾的featureGates开启DynamicResourceAllocation: true（注释说对 n-3 版本对 kubelet 1.33 的测试仍需要，只在 1.34 上测试后可移除）和NodeLogQuery: true（n-3/2/1 测试需要，只在 ≥ 1.36 上测试后可移除）。

注意文件内注释强调：feature gate 必须是这个 YAML 的最后一个条目。部分 Prow job 会在这个基础上追加 gate，文档给出的写法是：

# 文档示例，<some feature> 替换为你要追加的 feature gate 名称 --config <(cat test/e2e/dra/kind.yaml; echo " <some feature>: true")

第四步：构建 ginkgo 并运行 DRA e2e 测试

先构建 ginkgo：

$ make ginkgo

然后在源码树根目录运行聚焦 DRA 特性的 e2e 测试：

$ KUBECONFIG=~/.kube/config _output/bin/ginkgo -p -v -focus=Feature:DynamicResourceAllocation ./test/e2e

参数含义：-p并行执行，-v输出每个 spec 的详细过程，-focus=Feature:DynamicResourceAllocation只运行打了 DRA 特性标签的测试，./test/e2e是测试包路径。KUBECONFIG指向集群的 kubeconfig，按文档使用默认的~/.kube/config。测试套件本身即是验证手段：ginkgo 会逐个报告 DRA 相关 spec 的执行结果，-v输出用于定位失败的 spec；如果某个 spec 失败，第三步中开启的 scheduler / controller-manager / kubelet 详细日志就是文档为 DRA 排查配置的诊断信息。

限制与边界

• 这套测试不覆盖任意 DRA 驱动的正确行为，只验证 Kubernetes 侧的 DRA 支持，驱动是仓库内树的测试驱动。
• 测试驱动没有包含它的容器镜像，因此无法部署到"普通"集群上，这也是整个流程必须用代理进e2e.test的驱动、并用源码构建节点镜像的原因（见 test/e2e/dra/test-driver/README.md）。
• 集群配置文件 test/e2e/dra/kind.yaml 中 feature gate 必须保持为 YAML 末尾条目，自行修改该文件时不要破坏这一顺序。
• 构建目标定义见 Makefile：make与make ginkgo均通过hack/make-rules/build.sh完成，产物位于_output/bin。

【免费下载链接】kubernetesProduction-Grade Container Scheduling and Management项目地址: https://gitcode.com/GitHub_Trending/kuber/kubernetes