Kubernetes 节点性能基准测试镜像解析基于 NAS 并行基准套件 Integer SortNPB-IS的实践指南【免费下载链接】kubernetesProduction-Grade Container Scheduling and Management项目地址: https://gitcode.com/GitHub_Trending/kuber/kubernetes本文聚焦 Kubernetes 仓库 test/images/node-perf/npb-is/README.md 所描述的容器镜像——NPB Integer SortIS基准测试负载。该镜像面向 Kubernetes 节点性能Node Performance测试场景用于量化节点 CPU、内存子系统在计算密集型负载下的调度与运行表现。读完本文你将掌握该镜像的目录组成、镜像构建原理含 arm64 交叉构建细节、一键构建与发布流程以及它在节点 e2e 测试中如何作为标准负载被调度执行、如何从日志中提取性能指标。一、为什么需要 NPB-IS 这样的计算密集型镜像Kubernetes 的 Node Performance Testing见 test/e2e_node/node_perf_test.go是一组**串行Serial、慢速Slow**的节点端到端测试其目的是在真实工作负载下观测 kubelet 所在节点的表现。这类测试需要三类覆盖不同计算特征的负载在 test/e2e_node/perf/workloads/workloads.go#L52-L54 中统一定义var NodePerfWorkloads []NodePerfWorkload{npbISWorkload{}, npbEPWorkload{}, pytorchWideDeepWorkload{}}其中npbISWorkload{}对应的正是 NPB Integer Sort 基准。IS 基准的核心计算特征是大整数桶排序bucket sort——它通过大量随机数生成、桶分配与排序操作对节点的整数运算能力、内存带宽与 Cache 行为产生持续高强度的压力。相比 EPEmbarrassingly Parallel高度并行、几乎无通信负载IS 包含真实的数据依赖与访存模式能让节点性能测试覆盖到更贴近实际计算任务的场景。因此该镜像的定位不是演示用容器而是被 e2e 框架当作标准可重复的计算探针。二、镜像目录构成一份镜像所需的最小文件集合npb-is镜像的完整上下文位于仓库根目录相对路径 test/images/node-perf/npb-is/ 下共四个文件每个文件各司其职文件作用Dockerfile多阶段构建脚本负责编译 NPB IS 并组装运行镜像VERSION镜像版本号当前为1.7.0BASEIMAGE各架构基础镜像映射支持多架构构建README.md镜像用途与发布命令说明BASEIMAGE 明确了多架构基础镜像策略文件内容linux/amd64debian:bookworm-slim linux/arm64arm64v8/debian:bookworm-slimVERSION并非装饰性文件。镜像注册信息位于 test/utils/image/manifest.go#L186-L187 与 #L230它把NodePerfNpbIs这个镜像常量解析为完整的镜像拉取地址// NodePerfNpbIs image NodePerfNpbIs ... configs[NodePerfNpbIs] Config{list.PromoterE2eRegistry, node-perf/npb-is, 1.7.0}也就是说e2e 测试实际拉取的镜像是registry.k8s.io/e2e-test-images/node-perf/npb-is:1.7.0list.PromoterE2eRegistry即e2e-test-images仓库。发布镜像时必须同步更新VERSION与manifest.go中的版本号否则 e2e 拉取的仍是旧镜像。三、深入 Dockerfile从源码编译到可执行负载的完整链路Dockerfile 采用多阶段构建multi-stage build完整还原了从 NASA NPB 源码到单二进制负载镜像的过程3.1 构建阶段下载并编译 NPB 3.3.1ARG BASEIMAGE FROM $BASEIMAGE AS build_node_perf_npb_is RUN apt-get update apt-get install -y build-essential gfortran ADD http://www.nas.nasa.gov/assets/npb/NPB3.3.1.tar.gz . RUN tar xzf NPB3.3.1.tar.gz chmod -R arX NPB3.3.1要点说明BASEIMAGE通过ARG注入实际取值来自上文BASEIMAGE文件由image-util.sh构建脚本按目标架构传递NPB 的 IS 基准主体由 Fortran/MPI 与 OpenMP 版本构成因此构建阶段安装gfortranFortran 编译器与build-essential这里的版本是NPB3.3.1发行版chmod -R arX修正文件权限是为了配合QEMU 模拟的交叉构建例如在 amd64 宿主机上构建 arm64 镜像。3.2 针对交叉构建的兼容性修补WORKDIR ./NPB3.3.1/NPB3.3-OMP # 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构建使用OpenMP 版 ISNPB3.3-OMP需要先运行make的打印头/打印指令脚本。上游发布的sys/print_header与sys/print_instructions缺少 shebang在原生 glibc 环境下可能尚能执行但在 QEMU 模拟的交叉构建环境下 Debian 默认/bin/shdash会拒绝执行这类脚本因此用sed在文件首行注入#!/bin/sh。这是容器可复现构建中典型的兼容性修补案例。3.3 按架构生成编译配置RUN if [ $(arch) aarch64 ]; then \ sed s/-mcmodelmedium/-mcmodellarge -fno-PIE -mno-outline-atomics/g config/NAS.samples/make.def.gcc_x86 config/make.def; \ else \ cp config/NAS.samples/make.def.gcc_x86 config/make.def; \ fi RUN make IS CLASSDNPB 使用config/make.def作为编译配置上游随包提供了config/NAS.samples/make.def.gcc_x86模板。这里按目标架构分支处理x86_64amd64直接复制gcc_x86模板即可aarch64arm64需把编译器选项-mcmodelmedium替换为-mcmodellarge -fno-PIE -mno-outline-atomics。原因在 Dockerfile 注释中已说明-mcmodellarge使用大代码模型以容纳超出默认寻址范围的大型二进制-fno-PIE关闭与 large model 不兼容的位置无关可执行文件-mno-outline-atomics要求内联原子操作以避免链接期问题——这些都是在 arm64 上编译大体积 Fortran/OpenMP 程序时的实际工程经验。make IS CLASSD表示以CLASSD最大问题规模编译 IS 基准生成的可执行文件为bin/is.D.x。CLASS 是 NPB 的问题规模分级S/W/A/B/C/D……CLASSD 代表大数据集能对节点产生足够长的饱和计算压力。3.4 依赖库收集与运行阶段组装RUN mkdir -p /lib-copy find /usr/lib -name *.so.* -exec cp {} /lib-copy \; FROM $BASEIMAGE COPY --frombuild_node_perf_npb_is /NPB3.3.1/NPB3.3-OMP/bin/is.D.x / COPY --frombuild_node_perf_npb_is /lib-copy /lib-copy ENV LD_LIBRARY_PATH${LD_LIBRARY_PATH}:/lib-copy ENTRYPOINT /is.D.x最终运行阶段只保留最精简的内容把编译产物is.D.x复制到根目录/把构建阶段收集到的共享库/usr/lib下所有*.so.*复制到/lib-copy并通过LD_LIBRARY_PATH注入——这是为了让is.D.x在未安装gfortran运行库的精简基础镜像bookworm-slim中也能正常动态链接执行容器启动即运行/is.D.x基准完成后进程退出退出码 0容器状态随之变为 Completed——这一跑完即退出的设计正好契合测试框架对 Job 型负载的断言方式。四、构建与发布一条命令完成镜像的编译和推送test/images/node-perf/npb-is/README.md 给出了两个发布命令都基于test/images目录下统一的镜像构建体系# 构建 $ cd $K8S_ROOT/test/images $ make all WHATnode-perf/npb-is # 推送 $ cd $K8S_ROOT/test/images $ make all-push WHATnode-perf/npb-is这里的$K8S_ROOT指仓库根目录。追踪 test/images/Makefile 可以看到这些 target 的真实行为REPO_ROOT:${CURDIR}/../.. REGISTRY ? registry.k8s.io/e2e-test-images all: all-container all-container: ./image-util.sh build $(WHAT) docker all-push: bash -x ./image-util.sh build $(WHAT) registry bash -x ./image-util.sh push $(WHAT) all-build-and-push: ./image-util.sh build_and_push ${WHAT}几个关键点WHAT是必需变量未传WHAT时 Makefile 直接报错WHAT is a required variable它的值是test/images下相对目录名node-perf/npb-is即指向 node-perf 子目录里的npb-is镜像make all WHATnode-perf/npb-is只做本地构建docker驱动产物可用于本地调试make all-push WHATnode-perf/npb-is会先按registry驱动构建依据 BASEIMAGE 完成多架构构建并推送到注册表再执行push。最终镜像将推送到默认注册表registry.k8s.io/e2e-test-images/node-perf/npb-is标签来自 VERSION 的1.7.0若需一条命令同时完成构建与推送也可使用make all-build-and-push WHATnode-perf/npb-is。镜像版本演进1.7.0需要与 test/utils/image/manifest.go#L230 的注册配置保持一致否则 e2e 测试引用的镜像与最新发布版本会出现偏差。五、镜像在节点性能 e2e 测试中的消费方式镜像本身只是载体真正的工作负载定义在 e2e 侧。理解 test/e2e_node/perf/workloads/npb_is.go 能让你看清楚一个被拉起的 IS 基准容器在节点测试里究竟占用多少资源、如何被断言成功。5.1 工作负载接口NodePerfWorkloadtest/e2e_node/perf/workloads/workloads.go#L28-L50 定义了所有节点性能负载必须实现的接口type NodePerfWorkload interface { Name() string // 负载名称如 npb-is PodSpec() v1.PodSpec // 运行该负载所需的 Pod 规格 Timeout() time.Duration // 预期完成时间 KubeletConfig(old *kubeletconfig.KubeletConfiguration) (new ..., err error) // 负载所需的 kubelet 配置 PreTestExec() error // 重启 kubelet 前的逻辑 PostTestExec() error // 负载完成后的逻辑 ExtractPerformanceFromLogs(logs string) (perf time.Duration, err error) // 从日志解析性能 }npbISWorkloadnpb_is.go完整实现了该接口Name()返回npb-isTimeout()为4 分钟4 * time.MinuteKubeletConfig/PreTestExec/PostTestExec均返回空操作说明 IS 负载不依赖特殊 kubelet 配置与需要 CPU Manager 介入的某些负载不同。5.2 资源规格一份需要大节点的负载npbISWorkload.PodSpec()npb_is.go#L41-L65声明了非常明确且严格的资源账本ctn : v1.Container{ Name: fmt.Sprintf(%s-ctn, w.Name()), Image: imageutils.GetE2EImage(imageutils.NodePerfNpbIs), Resources: v1.ResourceRequirements{ Requests: v1.ResourceList{ v1.ResourceName(v1.ResourceCPU): resource.MustParse(15000m), v1.ResourceName(v1.ResourceMemory): resource.MustParse(48Gi), }, Limits: v1.ResourceList{ v1.ResourceName(v1.ResourceCPU): resource.MustParse(15000m), v1.ResourceName(v1.ResourceMemory): resource.MustParse(48Gi), }, }, Command: []string{/bin/sh}, Args: []string{-c, /is.D.x}, }关键工程含义15 个 CPU15000m与 48Gi 内存且 Requests 与 Limits 相等——这是一份 Guaranteed QoS 的大胃口负载要求被测节点拥有至少 15 核可用 CPU 与 48Gi 以上可分配内存。这也解释了为什么测试运行前要执行资源预检见下文 5.4启动命令并非直接执行ENTRYPOINT的/is.D.x而是经/bin/sh -c /is.D.x包一层便于在真实 Pod 环境中捕获子进程输出到容器日志RestartPolicy: Never基准是一次性计算任务跑完即 Pod 成功退出不允许重启重试避免污染性能读数。5.3 性能指标提取从日志中解析Time in secondsNPB 基准运行结束会在标准输出打印Time in seconds xxx。ExtractPerformanceFromLogsnpb_is.go#L83-L93从 Pod 日志里精确取出该行把后的数值拼接成 Go 可解析的时长字符串例如42.35s再用time.ParseDuration转成time.Duration返回——这就是该轮节点性能测试的最终指标完成 IS(D) 基准所消耗的墙钟时间。5.4 测试主流程从资源预检到指标落盘test/e2e_node/node_perf_test.go 完整串联了镜像负载与测试框架的交互资源预检BeforeEachL146-L159读取被测节点的 Allocatable CPU 与内存若低于 15 核或 48Gi 则直接 Skip 该用例避免在小节点上误报失败Kubelet 配置装载JustBeforeEach依次执行PreTestExec→ 读取当前 kubelet 配置 → 应用负载所需配置 → 必要时停止并重启 kubeletIS 负载无需改动走空路径创建并等待 PodrunWorkloadL113-L144以npb-is-pod命名创建 Pod在 4 分钟超时内轮询等待 Pod 进入Succeeded或Failed状态失败时主动抓取容器日志辅助排查提取并记录性能调用ExtractPerformanceFromLogs得到time.Duration通过framework.Logf输出Time to complete workload npb-is: ...清理删除 Pod 并等待 15 秒让 CPU Manager 等组件完成收尾再恢复原始 kubelet 配置。从测试组织方式看npb-is与npb-ep、pytorch-wide-deep并列为三组It用例L161-L187共同组成Node Performance Testing这一 Slow/Serial 测试套件。六、快速自查清单与适用前提结合前文使用或复现 npb-is 镜像时建议按以下清单核对目录上下文齐全npb-is/下必须同时存在Dockerfile、VERSION、BASEIMAGE与README.md缺一不可版本同步修改VERSION后需同步更新 test/utils/image/manifest.go#L230 中的版本常量确保 e2e 引用一致构建环境构建阶段需访问外网以下载 NASA NPB3.3.1 源码包若目标为 arm64 且宿主为 x86_64需具备 QEMU 模拟能力Dockerfile 已内置相关兼容处理运行环境直接运行该镜像需要节点提供约 15 核 CPU 与 48Gi 内存Guaranteed 级资源不足时 e2e 用例会跳过而非失败结果判定容器正常退出即代表 IS(D) 基准跑完性能参考值为日志中Time in seconds对应的时长越短代表该节点在同类计算负载下完成基准越快。总体上test/images/node-perf/npb-is/ 呈现了一个上游 HPC 基准 → 容器化 → 被 e2e 框架标准化消费的完整范例既适合作为理解 Kubernetes 多架构镜像构建流水线的入门样本多阶段构建、QEMU 交叉编译、动态库收集也为节点性能测试体系的负载设计提供了可参照的实现范式。【免费下载链接】kubernetesProduction-Grade Container Scheduling and Management项目地址: https://gitcode.com/GitHub_Trending/kuber/kubernetes创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Kubernetes 节点性能基准测试镜像解析：基于 NAS 并行基准套件 Integer Sort（NPB-IS）的实践指南
Kubernetes 节点性能基准测试镜像解析基于 NAS 并行基准套件 Integer SortNPB-IS的实践指南【免费下载链接】kubernetesProduction-Grade Container Scheduling and Management项目地址: https://gitcode.com/GitHub_Trending/kuber/kubernetes本文聚焦 Kubernetes 仓库 test/images/node-perf/npb-is/README.md 所描述的容器镜像——NPB Integer SortIS基准测试负载。该镜像面向 Kubernetes 节点性能Node Performance测试场景用于量化节点 CPU、内存子系统在计算密集型负载下的调度与运行表现。读完本文你将掌握该镜像的目录组成、镜像构建原理含 arm64 交叉构建细节、一键构建与发布流程以及它在节点 e2e 测试中如何作为标准负载被调度执行、如何从日志中提取性能指标。一、为什么需要 NPB-IS 这样的计算密集型镜像Kubernetes 的 Node Performance Testing见 test/e2e_node/node_perf_test.go是一组**串行Serial、慢速Slow**的节点端到端测试其目的是在真实工作负载下观测 kubelet 所在节点的表现。这类测试需要三类覆盖不同计算特征的负载在 test/e2e_node/perf/workloads/workloads.go#L52-L54 中统一定义var NodePerfWorkloads []NodePerfWorkload{npbISWorkload{}, npbEPWorkload{}, pytorchWideDeepWorkload{}}其中npbISWorkload{}对应的正是 NPB Integer Sort 基准。IS 基准的核心计算特征是大整数桶排序bucket sort——它通过大量随机数生成、桶分配与排序操作对节点的整数运算能力、内存带宽与 Cache 行为产生持续高强度的压力。相比 EPEmbarrassingly Parallel高度并行、几乎无通信负载IS 包含真实的数据依赖与访存模式能让节点性能测试覆盖到更贴近实际计算任务的场景。因此该镜像的定位不是演示用容器而是被 e2e 框架当作标准可重复的计算探针。二、镜像目录构成一份镜像所需的最小文件集合npb-is镜像的完整上下文位于仓库根目录相对路径 test/images/node-perf/npb-is/ 下共四个文件每个文件各司其职文件作用Dockerfile多阶段构建脚本负责编译 NPB IS 并组装运行镜像VERSION镜像版本号当前为1.7.0BASEIMAGE各架构基础镜像映射支持多架构构建README.md镜像用途与发布命令说明BASEIMAGE 明确了多架构基础镜像策略文件内容linux/amd64debian:bookworm-slim linux/arm64arm64v8/debian:bookworm-slimVERSION并非装饰性文件。镜像注册信息位于 test/utils/image/manifest.go#L186-L187 与 #L230它把NodePerfNpbIs这个镜像常量解析为完整的镜像拉取地址// NodePerfNpbIs image NodePerfNpbIs ... configs[NodePerfNpbIs] Config{list.PromoterE2eRegistry, node-perf/npb-is, 1.7.0}也就是说e2e 测试实际拉取的镜像是registry.k8s.io/e2e-test-images/node-perf/npb-is:1.7.0list.PromoterE2eRegistry即e2e-test-images仓库。发布镜像时必须同步更新VERSION与manifest.go中的版本号否则 e2e 拉取的仍是旧镜像。三、深入 Dockerfile从源码编译到可执行负载的完整链路Dockerfile 采用多阶段构建multi-stage build完整还原了从 NASA NPB 源码到单二进制负载镜像的过程3.1 构建阶段下载并编译 NPB 3.3.1ARG BASEIMAGE FROM $BASEIMAGE AS build_node_perf_npb_is RUN apt-get update apt-get install -y build-essential gfortran ADD http://www.nas.nasa.gov/assets/npb/NPB3.3.1.tar.gz . RUN tar xzf NPB3.3.1.tar.gz chmod -R arX NPB3.3.1要点说明BASEIMAGE通过ARG注入实际取值来自上文BASEIMAGE文件由image-util.sh构建脚本按目标架构传递NPB 的 IS 基准主体由 Fortran/MPI 与 OpenMP 版本构成因此构建阶段安装gfortranFortran 编译器与build-essential这里的版本是NPB3.3.1发行版chmod -R arX修正文件权限是为了配合QEMU 模拟的交叉构建例如在 amd64 宿主机上构建 arm64 镜像。3.2 针对交叉构建的兼容性修补WORKDIR ./NPB3.3.1/NPB3.3-OMP # 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构建使用OpenMP 版 ISNPB3.3-OMP需要先运行make的打印头/打印指令脚本。上游发布的sys/print_header与sys/print_instructions缺少 shebang在原生 glibc 环境下可能尚能执行但在 QEMU 模拟的交叉构建环境下 Debian 默认/bin/shdash会拒绝执行这类脚本因此用sed在文件首行注入#!/bin/sh。这是容器可复现构建中典型的兼容性修补案例。3.3 按架构生成编译配置RUN if [ $(arch) aarch64 ]; then \ sed s/-mcmodelmedium/-mcmodellarge -fno-PIE -mno-outline-atomics/g config/NAS.samples/make.def.gcc_x86 config/make.def; \ else \ cp config/NAS.samples/make.def.gcc_x86 config/make.def; \ fi RUN make IS CLASSDNPB 使用config/make.def作为编译配置上游随包提供了config/NAS.samples/make.def.gcc_x86模板。这里按目标架构分支处理x86_64amd64直接复制gcc_x86模板即可aarch64arm64需把编译器选项-mcmodelmedium替换为-mcmodellarge -fno-PIE -mno-outline-atomics。原因在 Dockerfile 注释中已说明-mcmodellarge使用大代码模型以容纳超出默认寻址范围的大型二进制-fno-PIE关闭与 large model 不兼容的位置无关可执行文件-mno-outline-atomics要求内联原子操作以避免链接期问题——这些都是在 arm64 上编译大体积 Fortran/OpenMP 程序时的实际工程经验。make IS CLASSD表示以CLASSD最大问题规模编译 IS 基准生成的可执行文件为bin/is.D.x。CLASS 是 NPB 的问题规模分级S/W/A/B/C/D……CLASSD 代表大数据集能对节点产生足够长的饱和计算压力。3.4 依赖库收集与运行阶段组装RUN mkdir -p /lib-copy find /usr/lib -name *.so.* -exec cp {} /lib-copy \; FROM $BASEIMAGE COPY --frombuild_node_perf_npb_is /NPB3.3.1/NPB3.3-OMP/bin/is.D.x / COPY --frombuild_node_perf_npb_is /lib-copy /lib-copy ENV LD_LIBRARY_PATH${LD_LIBRARY_PATH}:/lib-copy ENTRYPOINT /is.D.x最终运行阶段只保留最精简的内容把编译产物is.D.x复制到根目录/把构建阶段收集到的共享库/usr/lib下所有*.so.*复制到/lib-copy并通过LD_LIBRARY_PATH注入——这是为了让is.D.x在未安装gfortran运行库的精简基础镜像bookworm-slim中也能正常动态链接执行容器启动即运行/is.D.x基准完成后进程退出退出码 0容器状态随之变为 Completed——这一跑完即退出的设计正好契合测试框架对 Job 型负载的断言方式。四、构建与发布一条命令完成镜像的编译和推送test/images/node-perf/npb-is/README.md 给出了两个发布命令都基于test/images目录下统一的镜像构建体系# 构建 $ cd $K8S_ROOT/test/images $ make all WHATnode-perf/npb-is # 推送 $ cd $K8S_ROOT/test/images $ make all-push WHATnode-perf/npb-is这里的$K8S_ROOT指仓库根目录。追踪 test/images/Makefile 可以看到这些 target 的真实行为REPO_ROOT:${CURDIR}/../.. REGISTRY ? registry.k8s.io/e2e-test-images all: all-container all-container: ./image-util.sh build $(WHAT) docker all-push: bash -x ./image-util.sh build $(WHAT) registry bash -x ./image-util.sh push $(WHAT) all-build-and-push: ./image-util.sh build_and_push ${WHAT}几个关键点WHAT是必需变量未传WHAT时 Makefile 直接报错WHAT is a required variable它的值是test/images下相对目录名node-perf/npb-is即指向 node-perf 子目录里的npb-is镜像make all WHATnode-perf/npb-is只做本地构建docker驱动产物可用于本地调试make all-push WHATnode-perf/npb-is会先按registry驱动构建依据 BASEIMAGE 完成多架构构建并推送到注册表再执行push。最终镜像将推送到默认注册表registry.k8s.io/e2e-test-images/node-perf/npb-is标签来自 VERSION 的1.7.0若需一条命令同时完成构建与推送也可使用make all-build-and-push WHATnode-perf/npb-is。镜像版本演进1.7.0需要与 test/utils/image/manifest.go#L230 的注册配置保持一致否则 e2e 测试引用的镜像与最新发布版本会出现偏差。五、镜像在节点性能 e2e 测试中的消费方式镜像本身只是载体真正的工作负载定义在 e2e 侧。理解 test/e2e_node/perf/workloads/npb_is.go 能让你看清楚一个被拉起的 IS 基准容器在节点测试里究竟占用多少资源、如何被断言成功。5.1 工作负载接口NodePerfWorkloadtest/e2e_node/perf/workloads/workloads.go#L28-L50 定义了所有节点性能负载必须实现的接口type NodePerfWorkload interface { Name() string // 负载名称如 npb-is PodSpec() v1.PodSpec // 运行该负载所需的 Pod 规格 Timeout() time.Duration // 预期完成时间 KubeletConfig(old *kubeletconfig.KubeletConfiguration) (new ..., err error) // 负载所需的 kubelet 配置 PreTestExec() error // 重启 kubelet 前的逻辑 PostTestExec() error // 负载完成后的逻辑 ExtractPerformanceFromLogs(logs string) (perf time.Duration, err error) // 从日志解析性能 }npbISWorkloadnpb_is.go完整实现了该接口Name()返回npb-isTimeout()为4 分钟4 * time.MinuteKubeletConfig/PreTestExec/PostTestExec均返回空操作说明 IS 负载不依赖特殊 kubelet 配置与需要 CPU Manager 介入的某些负载不同。5.2 资源规格一份需要大节点的负载npbISWorkload.PodSpec()npb_is.go#L41-L65声明了非常明确且严格的资源账本ctn : v1.Container{ Name: fmt.Sprintf(%s-ctn, w.Name()), Image: imageutils.GetE2EImage(imageutils.NodePerfNpbIs), Resources: v1.ResourceRequirements{ Requests: v1.ResourceList{ v1.ResourceName(v1.ResourceCPU): resource.MustParse(15000m), v1.ResourceName(v1.ResourceMemory): resource.MustParse(48Gi), }, Limits: v1.ResourceList{ v1.ResourceName(v1.ResourceCPU): resource.MustParse(15000m), v1.ResourceName(v1.ResourceMemory): resource.MustParse(48Gi), }, }, Command: []string{/bin/sh}, Args: []string{-c, /is.D.x}, }关键工程含义15 个 CPU15000m与 48Gi 内存且 Requests 与 Limits 相等——这是一份 Guaranteed QoS 的大胃口负载要求被测节点拥有至少 15 核可用 CPU 与 48Gi 以上可分配内存。这也解释了为什么测试运行前要执行资源预检见下文 5.4启动命令并非直接执行ENTRYPOINT的/is.D.x而是经/bin/sh -c /is.D.x包一层便于在真实 Pod 环境中捕获子进程输出到容器日志RestartPolicy: Never基准是一次性计算任务跑完即 Pod 成功退出不允许重启重试避免污染性能读数。5.3 性能指标提取从日志中解析Time in secondsNPB 基准运行结束会在标准输出打印Time in seconds xxx。ExtractPerformanceFromLogsnpb_is.go#L83-L93从 Pod 日志里精确取出该行把后的数值拼接成 Go 可解析的时长字符串例如42.35s再用time.ParseDuration转成time.Duration返回——这就是该轮节点性能测试的最终指标完成 IS(D) 基准所消耗的墙钟时间。5.4 测试主流程从资源预检到指标落盘test/e2e_node/node_perf_test.go 完整串联了镜像负载与测试框架的交互资源预检BeforeEachL146-L159读取被测节点的 Allocatable CPU 与内存若低于 15 核或 48Gi 则直接 Skip 该用例避免在小节点上误报失败Kubelet 配置装载JustBeforeEach依次执行PreTestExec→ 读取当前 kubelet 配置 → 应用负载所需配置 → 必要时停止并重启 kubeletIS 负载无需改动走空路径创建并等待 PodrunWorkloadL113-L144以npb-is-pod命名创建 Pod在 4 分钟超时内轮询等待 Pod 进入Succeeded或Failed状态失败时主动抓取容器日志辅助排查提取并记录性能调用ExtractPerformanceFromLogs得到time.Duration通过framework.Logf输出Time to complete workload npb-is: ...清理删除 Pod 并等待 15 秒让 CPU Manager 等组件完成收尾再恢复原始 kubelet 配置。从测试组织方式看npb-is与npb-ep、pytorch-wide-deep并列为三组It用例L161-L187共同组成Node Performance Testing这一 Slow/Serial 测试套件。六、快速自查清单与适用前提结合前文使用或复现 npb-is 镜像时建议按以下清单核对目录上下文齐全npb-is/下必须同时存在Dockerfile、VERSION、BASEIMAGE与README.md缺一不可版本同步修改VERSION后需同步更新 test/utils/image/manifest.go#L230 中的版本常量确保 e2e 引用一致构建环境构建阶段需访问外网以下载 NASA NPB3.3.1 源码包若目标为 arm64 且宿主为 x86_64需具备 QEMU 模拟能力Dockerfile 已内置相关兼容处理运行环境直接运行该镜像需要节点提供约 15 核 CPU 与 48Gi 内存Guaranteed 级资源不足时 e2e 用例会跳过而非失败结果判定容器正常退出即代表 IS(D) 基准跑完性能参考值为日志中Time in seconds对应的时长越短代表该节点在同类计算负载下完成基准越快。总体上test/images/node-perf/npb-is/ 呈现了一个上游 HPC 基准 → 容器化 → 被 e2e 框架标准化消费的完整范例既适合作为理解 Kubernetes 多架构镜像构建流水线的入门样本多阶段构建、QEMU 交叉编译、动态库收集也为节点性能测试体系的负载设计提供了可参照的实现范式。【免费下载链接】kubernetesProduction-Grade Container Scheduling and Management项目地址: https://gitcode.com/GitHub_Trending/kuber/kubernetes创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考