Kubernetes 节点性能测试中的 NPB-EP 镜像从容器构建到 e2e 基准测试全流程解析【免费下载链接】kubernetesProduction-Grade Container Scheduling and Management项目地址: https://gitcode.com/GitHub_Trending/kuber/kubernetesNAS Parallel BenchmarkNPB套件中的 Embarrassingly ParallelEP基准被 Kubernetes 用作节点级性能测试的代表性 CPU 密集负载。本文基于 test/images/node-perf/npb-ep/ 目录中的文档与镜像定义结合其配套的 e2e 测试源码系统讲解该镜像的构建方式、多架构发布流程以及它是如何在 Kubernetes 节点性能测试中通过 kubelet CPU Manager 静态策略被调度执行并采集性能数据的。读完本文你将掌握 Kubernetes 测试镜像的构建/推送方法理解npb-ep从 Dockerfile 到 e2e 工作负载对象的完整调用链。镜像概览EP 基准与节点性能测试test/images/node-perf/npb-ep/README.md 明确说明该目录描述的容器镜像运行的是NAS Parallel Benchmark 套件中的 EPEmbarrassingly Parallel高度并行基准它来自 NASA 官方的 NAS 并行基准套件NPB 3.x此镜像在 Kubernetes 中被用作节点性能测试node performance testing的工作负载。EP 基准在 NPB 套件中的定位是极度并行类负载它通过大量独立的伪随机数生成与数学运算来压测 CPU 浮点与整数计算能力进程/线程之间的通信量极少因此非常适合衡量单节点 CPU 的纯粹计算吞吐而不引入网络或存储等干扰因素。这正是它在 Kubernetes 节点性能测试中被选中衡量CPU Manager 静态绑定策略下容器实际能拿到多少 CPU 性能的原因——该用途在 npb_ep.go 的注释中有明确表述workload to run the Embarrassingly Parallel (EP) workload from NAS parallel benchmark (NPB) suite。在 test/images/node-perf/ 目录中npb-ep与另外两个兄弟负载并列共同构成节点性能测试的工作负载集合npb-ep/EP 基准镜像本文主题npb-is/NPB 套件中的整数排序Integer Sort, IS基准镜像pytorch-wide-deep/PyTorch Wide Deep 训练负载镜像含 train_wide_deep.py。三者在结构上保持完全一致每个子目录都由README.md、Dockerfile、BASEIMAGE、VERSION四个文件组成便于统一纳入 test/images 的镜像批量构建与发布体系。多阶段 Dockerfile 构建剖析Dockerfile 采用两阶段构建先在一个完整的构建环境中编译 NPB 的 EP 程序再在精简的基础镜像上只保留可执行文件与其依赖的动态库。第一阶段编译 EP 可执行文件构建阶段以基础镜像$BASEIMAGE为起点先安装编译 EP 所需的工具链ARG BASEIMAGE FROM $BASEIMAGE AS build_node_perf_npb_ep RUN apt-get update apt-get install -y libc6-dev g bzip2 dpkg-dev build-essential gfortran其中gfortran是关键——NPB 套件的源码以 Fortran 编写因此必须提供 GNU Fortran 编译器其余包g、build-essential、libc6-dev 等用于提供完整的 C/C 与链接环境。随后从 NAS 官方站点下载 NPB 3.4.3 源码包并解压ADD http://www.nas.nasa.gov/assets/npb/NPB3.4.3.tar.gz . # Fix permissions for cross-build with QEMU emulation RUN tar xzf NPB3.4.3.tar.gz chmod -R arX NPB3.4.3 WORKDIR ./NPB3.4.3/NPB3.4-OMP这里有两个值得注意的工程细节选择的是NPB3.4-OMPOpenMP 并行版本子目录意味着 EP 基准将使用 OpenMP 线程模型在容器内并行计算从而能充分利用 Kubernetes 为其分配的多个 CPUchmod -R arX以及下一段对脚本的sed修改都在注释中说明是为了QEMU 模拟下的跨架构构建例如在 x86 构建机上交叉构建 arm64/ppc64le 镜像——缺少可执行权限或 shebang 会导致make调用的 shell 脚本在模拟环境中执行失败# Add missing shebangs to shell scripts - required for cross-build with QEMU emulation # Without shebangs, dash (default /bin/sh on Debian) fails to execute these scripts via make RUN sed -i 1i#!/bin/sh sys/print_header sys/print_instructions接着根据当前架构生成config/make.def配置文件并编译 EP 基准。NPB 为不同编译器提供样板配置这里选用 GCC 版本同时在非 x86_64 架构下去掉-mcmodelmedium编译选项该选项在部分架构上不可用或不需要RUN if [ $(arch) ! x86_64 ]; then \ sed s/-mcmodelmedium//g config/NAS.samples/make.def_gcc config/make.def; \ else \ cp config/NAS.samples/make.def_gcc config/make.def; \ fi RUN make EP CLASSDmake EP CLASSD的含义是编译 EP 基准并指定CLASSD 问题规模。NPB 使用 CLASSS/A/B/C/D/E表示从小到大的问题规模与内存占用Kubernetes 在 e2e 测试中选用 CLASSD需要与该镜像在 npb_ep.go 中声明的48Gi内存请求相匹配详见下文。编译产物为bin/ep.D.x。第一阶段结束时构建脚本还把系统动态库集中复制到/lib-copy以便在第二阶段精简镜像中直接注入避免运行时依赖缺失RUN mkdir -p /lib-copy find /usr/lib -name *.so.* -exec cp {} /lib-copy \;第二阶段组装运行时镜像最终镜像重新基于$BASEIMAGE不含编译器只把 EP 可执行文件与动态库复制进来并设置LD_LIBRARY_PATH指向库目录FROM $BASEIMAGE COPY --frombuild_node_perf_npb_ep /NPB3.4.3/NPB3.4-OMP/bin/ep.D.x / COPY --frombuild_node_perf_npb_ep /lib-copy /lib-copy ENV LD_LIBRARY_PATH${LD_LIBRARY_PATH}:/lib-copy ENTRYPOINT /ep.D.x也就是说容器启动后直接执行根目录下的/ep.D.xEP 基准 D 规模的可执行文件基准程序自行输出执行耗时。这种两阶段方案使最终镜像大幅瘦身——只保留运行基准所需的二进制与动态库编译器等构建期依赖全部留在中间层符合 Kubernetes 官方镜像追求精简的理念。多架构基础镜像与版本管理BASEIMAGE一套 Dockerfile 覆盖四种 CPU 架构BASEIMAGE 按架构镜像的键值对声明该 Dockerfile 在每种架构下应使用的基础镜像linux/amd64debian:bookworm-slim linux/arm64arm64v8/debian:bookworm-slim linux/ppc64leppc64le/debian:bookworm-slim linux/s390xs390x/debian:bookworm-slim四个条目全部选用Debian bookworm-slim精简镜像且 arm64、ppc64le、s390x 均使用各架构官方命名的镜像变体保证同一份 Dockerfile 可以被构建体系以不同--platform分别产出四个架构的镜像。上文提到的 QEMU 兼容处理补 shebang、chmod arX、按arch分支调整make.def正是为了让构建能在任意架构宿主上正确产出多架构产物。VERSION 与镜像仓库登记VERSION 文件内容为1.6.0即该镜像当前的发布版本。镜像的仓库定位在 e2e 镜像工具中登记——test/utils/image/manifest.go 维护了镜像键到仓库与标签的映射configs[NodePerfNpbEp] Config{list.PromoterE2eRegistry, node-perf/npb-ep, 1.6.0}即NodePerfNpbEp镜像被登记为路径node-perf/npb-ep、标签1.6.0与VERSION文件保持一致。e2e 测试代码通过imageutils.GetE2EImage(imageutils.NodePerfNpbEp)获取最终的完整镜像地址见 npb_ep.go而 image_list.go 会在测试框架层面对这些镜像做统一管理。镜像构建与发布README 给出的两条命令README 中如何发布How to release一节给出了镜像发布的标准操作这也是整份文档最核心的可执行内容# 构建 $ cd $K8S_ROOT/test/images $ make all WHATnode-perf/npb-ep # 推送 $ cd $K8S_ROOT/test/images $ make all-push WHATnode-perf/npb-ep这两条命令说明以下几点$K8S_ROOT指 Kubernetes 源码仓库根目录执行前需把当前目录切换到本仓库下的test/images即包含全部测试镜像子目录的位置make all在 test/images 的 Makefile 体系驱动下为test/images下所有含Dockerfile的子目录执行镜像构建WHATnode-perf/npb-ep则把范围收窄到npb-ep这一个镜像即只对npb-ep/子目录执行目标make all-push与make all对应完成构建后将镜像推送到 manifest 中登记的 e2e 镜像仓库NodePerfNpbEp对应的PromoterE2eRegistry。BASEIMAGE 中的多架构声明会在构建流程中被解析指定WHATnode-perf/npb-ep后构建逻辑逐一取出 BASEIMAGE 中列出的架构条目为每个架构执行一次 Docker 构建并可进一步聚合为多架构 manifest。这套目录名即镜像名、WHAT精确筛选的组织约定使新增性能测试镜像只需在 test/images 下新建目录并提供四个标准文件即可无缝接入发布流水线。e2e 节点测试中的实际调度与性能采集README 明确指出该镜像被用作节点性能测试中的工作负载。Kubernetes 中真正的运行与测量逻辑位于 e2e_node 测试代码下面把整条调用链串起来看。工作负载接口与 npb-ep 实现test/e2e_node/perf/workloads/workloads.go 将三个负载注册为统一接口的集合var NodePerfWorkloads []NodePerfWorkload{npbISWorkload{}, npbEPWorkload{}, pytorchWideDeepWorkload{}}npbEPWorkload定义在 npb_ep.go通过编译期断言var _ NodePerfWorkload npbEPWorkload{}确保其完整实现接口。其关键方法体现了 EP 基准对资源的苛刻要求与测试隔离意图Name()返回npb-ep作为 Pod 命名等工作负载标识PodSpec()为 EP 容器声明Requests与Limits均为CPU 15000m15 核、内存 48Gi容器以/bin/sh -c /ep.D.x启动即直接运行镜像内编译好的 EP D 规模可执行文件见 npb_ep.goTimeout()返回10 * time.Minute作为允许基准完成的最长等待时间KubeletConfig()为本次测试动态改写 kubelet 配置——把 CPU Manager 策略切换为staticcpumanager.PolicyStatic并将 reconcile 周期设为 10 秒源码注释解释了配套细节启用静态策略后若kube-reserved/system-reserved未设置 kubelet 会 panic因此代码会确保kube-reserved[cpu]至少为200mPreTestExec() / PostTestExec()在测试前后删除/var/lib/kubelet/cpu_manager_state状态文件保证每次测试都以干净的 CPU 分配状态开始避免上一次测试的 CPU 独占残留影响本轮结果ExtractPerformanceFromLogs()从容器日志中定位Time in seconds 行把等号后的数值拼上s单位并解析为time.Duration作为最终上报的性能指标见 npb_ep.go。节点性能测试的完整执行流程test/e2e_node/node_perf_test.go 用 Ginkgo 框架编排整个 Node Performance Testing 套件覆盖全部三个负载其中npb-ep对应NodePerfWorkloads[1]见 node_perf_test.go。整条测试链路大致如下容量预检BeforeEach读取被测节点Status.Allocatable若 CPU 小于 15 或内存小于 48Gi 则Skipf跳过防止资源不足导致基准结果失真或 Pod 无法调度套用 kubelet 配置JustBeforeEach先执行工作负载的PreTestExec()随后setKubeletConfig()完成停止 kubelet → 写入新配置CPU Manager 静态策略→ 重启 kubelet → 轮询等待节点重新 Ready的序列运行工作负载runWorkload以npb-ep-pod命名创建 Pod通过WaitForPodCondition等待 Pod 进入Succeeded或Failed状态不用WaitForSuccess是为了在失败时仍能拿到容器日志用于排查见代码注释 #109295Pod 结束后读取容器日志交给ExtractPerformanceFromLogs解析出执行耗时并记录清理与还原cleanup删除 Pod 后特意等待 15 秒让 CPU Manager 完成释放 CPU 的收尾工作避免与PostTestExec删除 checkpoint 文件产生竞态、进而导致 kubelet 在重新配置时 panic随后执行PostTestExec()并把 kubelet 恢复为原始配置。由于测试需要修改 kubelet 配置并在受控节点上独占 15 核 CPUnode_perf_test.go 为套件标注了Serial串行执行与Slow耗时测试特性说明此类基准只适合在专用的节点性能测试环境运行。EP 与兄弟负载的分工对比 npb_is.go 可以看到负载设计的差异IS整数排序负载的Timeout()仅为 4 分钟且无需改动 kubelet 配置KubeletConfig直接返回原配置而 EP 负载专门搭配 CPU Manager 静态策略运行用于衡量容器在 CPU 独占绑定场景下的多核计算吞吐。二者分别从纯计算并行与内存/整数访存两个维度刻画节点性能画像而pytorch-wide-deep则覆盖 AI 训练类负载三者共同补齐了 Kubernetes 节点性能测试的负载矩阵。小结npb-ep镜像是一个完整的从基准源码到可观测性能指标的工程闭环构建侧Dockerfile 通过多阶段构建把 NPB 3.4.3 的 OpenMP 版 EP 程序编译为ep.D.x配合 BASEIMAGE 的多架构声明实现 amd64 / arm64 / ppc64le / s390x 四种架构发布VERSION 与 manifest.go 共同锁定镜像的版本与仓库定位测试侧npb_ep.go 把它封装为NodePerfWorkload接口实现15 核 / 48Gi、CPU Manager 静态策略、日志耗时解析node_perf_test.go 编排串行执行与状态清理最终产出可横向对比的基准耗时运维侧发布只需在 test/images 下执行 README 中给出的两条make命令配合WHAT参数即可精确构建并推送指定镜像。对希望在 Kubernetes 上做节点 CPU 性能基准的团队而言该目录提供了一套可复制的工程范式无论把基准替换成何种科学计算程序只要沿源码编译多阶段构建→ 精简运行镜像 → 工作负载接口封装 → e2e 编排与日志解析的链路落地就能无缝接入 Kubernetes 官方的节点性能测试体系获得可量化的 CPU 计算能力基线。【免费下载链接】kubernetesProduction-Grade Container Scheduling and Management项目地址: https://gitcode.com/GitHub_Trending/kuber/kubernetes创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Kubernetes 节点性能测试中的 NPB-EP 镜像：从容器构建到 e2e 基准测试全流程解析
Kubernetes 节点性能测试中的 NPB-EP 镜像从容器构建到 e2e 基准测试全流程解析【免费下载链接】kubernetesProduction-Grade Container Scheduling and Management项目地址: https://gitcode.com/GitHub_Trending/kuber/kubernetesNAS Parallel BenchmarkNPB套件中的 Embarrassingly ParallelEP基准被 Kubernetes 用作节点级性能测试的代表性 CPU 密集负载。本文基于 test/images/node-perf/npb-ep/ 目录中的文档与镜像定义结合其配套的 e2e 测试源码系统讲解该镜像的构建方式、多架构发布流程以及它是如何在 Kubernetes 节点性能测试中通过 kubelet CPU Manager 静态策略被调度执行并采集性能数据的。读完本文你将掌握 Kubernetes 测试镜像的构建/推送方法理解npb-ep从 Dockerfile 到 e2e 工作负载对象的完整调用链。镜像概览EP 基准与节点性能测试test/images/node-perf/npb-ep/README.md 明确说明该目录描述的容器镜像运行的是NAS Parallel Benchmark 套件中的 EPEmbarrassingly Parallel高度并行基准它来自 NASA 官方的 NAS 并行基准套件NPB 3.x此镜像在 Kubernetes 中被用作节点性能测试node performance testing的工作负载。EP 基准在 NPB 套件中的定位是极度并行类负载它通过大量独立的伪随机数生成与数学运算来压测 CPU 浮点与整数计算能力进程/线程之间的通信量极少因此非常适合衡量单节点 CPU 的纯粹计算吞吐而不引入网络或存储等干扰因素。这正是它在 Kubernetes 节点性能测试中被选中衡量CPU Manager 静态绑定策略下容器实际能拿到多少 CPU 性能的原因——该用途在 npb_ep.go 的注释中有明确表述workload to run the Embarrassingly Parallel (EP) workload from NAS parallel benchmark (NPB) suite。在 test/images/node-perf/ 目录中npb-ep与另外两个兄弟负载并列共同构成节点性能测试的工作负载集合npb-ep/EP 基准镜像本文主题npb-is/NPB 套件中的整数排序Integer Sort, IS基准镜像pytorch-wide-deep/PyTorch Wide Deep 训练负载镜像含 train_wide_deep.py。三者在结构上保持完全一致每个子目录都由README.md、Dockerfile、BASEIMAGE、VERSION四个文件组成便于统一纳入 test/images 的镜像批量构建与发布体系。多阶段 Dockerfile 构建剖析Dockerfile 采用两阶段构建先在一个完整的构建环境中编译 NPB 的 EP 程序再在精简的基础镜像上只保留可执行文件与其依赖的动态库。第一阶段编译 EP 可执行文件构建阶段以基础镜像$BASEIMAGE为起点先安装编译 EP 所需的工具链ARG BASEIMAGE FROM $BASEIMAGE AS build_node_perf_npb_ep RUN apt-get update apt-get install -y libc6-dev g bzip2 dpkg-dev build-essential gfortran其中gfortran是关键——NPB 套件的源码以 Fortran 编写因此必须提供 GNU Fortran 编译器其余包g、build-essential、libc6-dev 等用于提供完整的 C/C 与链接环境。随后从 NAS 官方站点下载 NPB 3.4.3 源码包并解压ADD http://www.nas.nasa.gov/assets/npb/NPB3.4.3.tar.gz . # Fix permissions for cross-build with QEMU emulation RUN tar xzf NPB3.4.3.tar.gz chmod -R arX NPB3.4.3 WORKDIR ./NPB3.4.3/NPB3.4-OMP这里有两个值得注意的工程细节选择的是NPB3.4-OMPOpenMP 并行版本子目录意味着 EP 基准将使用 OpenMP 线程模型在容器内并行计算从而能充分利用 Kubernetes 为其分配的多个 CPUchmod -R arX以及下一段对脚本的sed修改都在注释中说明是为了QEMU 模拟下的跨架构构建例如在 x86 构建机上交叉构建 arm64/ppc64le 镜像——缺少可执行权限或 shebang 会导致make调用的 shell 脚本在模拟环境中执行失败# Add missing shebangs to shell scripts - required for cross-build with QEMU emulation # Without shebangs, dash (default /bin/sh on Debian) fails to execute these scripts via make RUN sed -i 1i#!/bin/sh sys/print_header sys/print_instructions接着根据当前架构生成config/make.def配置文件并编译 EP 基准。NPB 为不同编译器提供样板配置这里选用 GCC 版本同时在非 x86_64 架构下去掉-mcmodelmedium编译选项该选项在部分架构上不可用或不需要RUN if [ $(arch) ! x86_64 ]; then \ sed s/-mcmodelmedium//g config/NAS.samples/make.def_gcc config/make.def; \ else \ cp config/NAS.samples/make.def_gcc config/make.def; \ fi RUN make EP CLASSDmake EP CLASSD的含义是编译 EP 基准并指定CLASSD 问题规模。NPB 使用 CLASSS/A/B/C/D/E表示从小到大的问题规模与内存占用Kubernetes 在 e2e 测试中选用 CLASSD需要与该镜像在 npb_ep.go 中声明的48Gi内存请求相匹配详见下文。编译产物为bin/ep.D.x。第一阶段结束时构建脚本还把系统动态库集中复制到/lib-copy以便在第二阶段精简镜像中直接注入避免运行时依赖缺失RUN mkdir -p /lib-copy find /usr/lib -name *.so.* -exec cp {} /lib-copy \;第二阶段组装运行时镜像最终镜像重新基于$BASEIMAGE不含编译器只把 EP 可执行文件与动态库复制进来并设置LD_LIBRARY_PATH指向库目录FROM $BASEIMAGE COPY --frombuild_node_perf_npb_ep /NPB3.4.3/NPB3.4-OMP/bin/ep.D.x / COPY --frombuild_node_perf_npb_ep /lib-copy /lib-copy ENV LD_LIBRARY_PATH${LD_LIBRARY_PATH}:/lib-copy ENTRYPOINT /ep.D.x也就是说容器启动后直接执行根目录下的/ep.D.xEP 基准 D 规模的可执行文件基准程序自行输出执行耗时。这种两阶段方案使最终镜像大幅瘦身——只保留运行基准所需的二进制与动态库编译器等构建期依赖全部留在中间层符合 Kubernetes 官方镜像追求精简的理念。多架构基础镜像与版本管理BASEIMAGE一套 Dockerfile 覆盖四种 CPU 架构BASEIMAGE 按架构镜像的键值对声明该 Dockerfile 在每种架构下应使用的基础镜像linux/amd64debian:bookworm-slim linux/arm64arm64v8/debian:bookworm-slim linux/ppc64leppc64le/debian:bookworm-slim linux/s390xs390x/debian:bookworm-slim四个条目全部选用Debian bookworm-slim精简镜像且 arm64、ppc64le、s390x 均使用各架构官方命名的镜像变体保证同一份 Dockerfile 可以被构建体系以不同--platform分别产出四个架构的镜像。上文提到的 QEMU 兼容处理补 shebang、chmod arX、按arch分支调整make.def正是为了让构建能在任意架构宿主上正确产出多架构产物。VERSION 与镜像仓库登记VERSION 文件内容为1.6.0即该镜像当前的发布版本。镜像的仓库定位在 e2e 镜像工具中登记——test/utils/image/manifest.go 维护了镜像键到仓库与标签的映射configs[NodePerfNpbEp] Config{list.PromoterE2eRegistry, node-perf/npb-ep, 1.6.0}即NodePerfNpbEp镜像被登记为路径node-perf/npb-ep、标签1.6.0与VERSION文件保持一致。e2e 测试代码通过imageutils.GetE2EImage(imageutils.NodePerfNpbEp)获取最终的完整镜像地址见 npb_ep.go而 image_list.go 会在测试框架层面对这些镜像做统一管理。镜像构建与发布README 给出的两条命令README 中如何发布How to release一节给出了镜像发布的标准操作这也是整份文档最核心的可执行内容# 构建 $ cd $K8S_ROOT/test/images $ make all WHATnode-perf/npb-ep # 推送 $ cd $K8S_ROOT/test/images $ make all-push WHATnode-perf/npb-ep这两条命令说明以下几点$K8S_ROOT指 Kubernetes 源码仓库根目录执行前需把当前目录切换到本仓库下的test/images即包含全部测试镜像子目录的位置make all在 test/images 的 Makefile 体系驱动下为test/images下所有含Dockerfile的子目录执行镜像构建WHATnode-perf/npb-ep则把范围收窄到npb-ep这一个镜像即只对npb-ep/子目录执行目标make all-push与make all对应完成构建后将镜像推送到 manifest 中登记的 e2e 镜像仓库NodePerfNpbEp对应的PromoterE2eRegistry。BASEIMAGE 中的多架构声明会在构建流程中被解析指定WHATnode-perf/npb-ep后构建逻辑逐一取出 BASEIMAGE 中列出的架构条目为每个架构执行一次 Docker 构建并可进一步聚合为多架构 manifest。这套目录名即镜像名、WHAT精确筛选的组织约定使新增性能测试镜像只需在 test/images 下新建目录并提供四个标准文件即可无缝接入发布流水线。e2e 节点测试中的实际调度与性能采集README 明确指出该镜像被用作节点性能测试中的工作负载。Kubernetes 中真正的运行与测量逻辑位于 e2e_node 测试代码下面把整条调用链串起来看。工作负载接口与 npb-ep 实现test/e2e_node/perf/workloads/workloads.go 将三个负载注册为统一接口的集合var NodePerfWorkloads []NodePerfWorkload{npbISWorkload{}, npbEPWorkload{}, pytorchWideDeepWorkload{}}npbEPWorkload定义在 npb_ep.go通过编译期断言var _ NodePerfWorkload npbEPWorkload{}确保其完整实现接口。其关键方法体现了 EP 基准对资源的苛刻要求与测试隔离意图Name()返回npb-ep作为 Pod 命名等工作负载标识PodSpec()为 EP 容器声明Requests与Limits均为CPU 15000m15 核、内存 48Gi容器以/bin/sh -c /ep.D.x启动即直接运行镜像内编译好的 EP D 规模可执行文件见 npb_ep.goTimeout()返回10 * time.Minute作为允许基准完成的最长等待时间KubeletConfig()为本次测试动态改写 kubelet 配置——把 CPU Manager 策略切换为staticcpumanager.PolicyStatic并将 reconcile 周期设为 10 秒源码注释解释了配套细节启用静态策略后若kube-reserved/system-reserved未设置 kubelet 会 panic因此代码会确保kube-reserved[cpu]至少为200mPreTestExec() / PostTestExec()在测试前后删除/var/lib/kubelet/cpu_manager_state状态文件保证每次测试都以干净的 CPU 分配状态开始避免上一次测试的 CPU 独占残留影响本轮结果ExtractPerformanceFromLogs()从容器日志中定位Time in seconds 行把等号后的数值拼上s单位并解析为time.Duration作为最终上报的性能指标见 npb_ep.go。节点性能测试的完整执行流程test/e2e_node/node_perf_test.go 用 Ginkgo 框架编排整个 Node Performance Testing 套件覆盖全部三个负载其中npb-ep对应NodePerfWorkloads[1]见 node_perf_test.go。整条测试链路大致如下容量预检BeforeEach读取被测节点Status.Allocatable若 CPU 小于 15 或内存小于 48Gi 则Skipf跳过防止资源不足导致基准结果失真或 Pod 无法调度套用 kubelet 配置JustBeforeEach先执行工作负载的PreTestExec()随后setKubeletConfig()完成停止 kubelet → 写入新配置CPU Manager 静态策略→ 重启 kubelet → 轮询等待节点重新 Ready的序列运行工作负载runWorkload以npb-ep-pod命名创建 Pod通过WaitForPodCondition等待 Pod 进入Succeeded或Failed状态不用WaitForSuccess是为了在失败时仍能拿到容器日志用于排查见代码注释 #109295Pod 结束后读取容器日志交给ExtractPerformanceFromLogs解析出执行耗时并记录清理与还原cleanup删除 Pod 后特意等待 15 秒让 CPU Manager 完成释放 CPU 的收尾工作避免与PostTestExec删除 checkpoint 文件产生竞态、进而导致 kubelet 在重新配置时 panic随后执行PostTestExec()并把 kubelet 恢复为原始配置。由于测试需要修改 kubelet 配置并在受控节点上独占 15 核 CPUnode_perf_test.go 为套件标注了Serial串行执行与Slow耗时测试特性说明此类基准只适合在专用的节点性能测试环境运行。EP 与兄弟负载的分工对比 npb_is.go 可以看到负载设计的差异IS整数排序负载的Timeout()仅为 4 分钟且无需改动 kubelet 配置KubeletConfig直接返回原配置而 EP 负载专门搭配 CPU Manager 静态策略运行用于衡量容器在 CPU 独占绑定场景下的多核计算吞吐。二者分别从纯计算并行与内存/整数访存两个维度刻画节点性能画像而pytorch-wide-deep则覆盖 AI 训练类负载三者共同补齐了 Kubernetes 节点性能测试的负载矩阵。小结npb-ep镜像是一个完整的从基准源码到可观测性能指标的工程闭环构建侧Dockerfile 通过多阶段构建把 NPB 3.4.3 的 OpenMP 版 EP 程序编译为ep.D.x配合 BASEIMAGE 的多架构声明实现 amd64 / arm64 / ppc64le / s390x 四种架构发布VERSION 与 manifest.go 共同锁定镜像的版本与仓库定位测试侧npb_ep.go 把它封装为NodePerfWorkload接口实现15 核 / 48Gi、CPU Manager 静态策略、日志耗时解析node_perf_test.go 编排串行执行与状态清理最终产出可横向对比的基准耗时运维侧发布只需在 test/images 下执行 README 中给出的两条make命令配合WHAT参数即可精确构建并推送指定镜像。对希望在 Kubernetes 上做节点 CPU 性能基准的团队而言该目录提供了一套可复制的工程范式无论把基准替换成何种科学计算程序只要沿源码编译多阶段构建→ 精简运行镜像 → 工作负载接口封装 → e2e 编排与日志解析的链路落地就能无缝接入 Kubernetes 官方的节点性能测试体系获得可量化的 CPU 计算能力基线。【免费下载链接】kubernetesProduction-Grade Container Scheduling and Management项目地址: https://gitcode.com/GitHub_Trending/kuber/kubernetes创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
