尧图网页设计 
Kubernetes 节点性能测试与剖析完整指南集群搭建、E2E 测试、pprof 剖析与 BenchmarkSIG Node【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community导读本文是 Kubernetes SIG Node 官方《Measuring Node Performance》文档的深度展开版系统讲解在真实 Kubernetes 集群中测量 Node 组件尤其是 Kubelet性能时的常见陷阱、集群搭建要点以及四类可用的测量手段性能仪表盘、集群 E2E 性能测试、Node E2E 性能测试、Go pprof 剖析与 Benchmark。读完本文你将能够搭建可复现的基准环境正确运行kubelet_perf.go与node_perf_test.go两类性能测试并用go tool pprof定位 Kubelet 的 CPU 与堆内存热点最终产出一份可信、可比较的节点性能数据。为什么节点性能测量容易出错测量前的核心认知测量节点性能Measuring Node Performance并不只是跑一个压测脚本那么简单。文档开篇即指出有大量因素会显著影响节点性能数据因此在搭建集群时必须格外谨慎确保你测量的是你想要测量的东西。其中最容易被忽视的一点是性能会随 commit 变化剧烈波动。Kubernetes 是高速迭代的项目每次代码提交都可能引入性能回归或优化。因此文档强烈建议精确记录测量时使用的Kubernetes 版本或 commit记录容器运行时container runtime版本如 containerd、CRI-O 等记录集群的完整搭建配置节点规格、内核、cgroup 驱动等。只有把这些测量元数据写清楚后续才能在不同 commit 之间、不同版本之间做有意义的性能对比。从本仓库的定位来看该文档隶属于 SIG Node 开发文档是社区贡献者在开发 Kubelet 相关功能时必须掌握的测量方法论。影响测量结果的关键维度从文档与 Kubernetes 实现来看至少有以下维度必须在测量前明确维度影响应对建议Addon Pod 数量与分布默认 8 个 addon pod 每节点 2 个fluentd-elasticsearch与kube-proxy会消耗资源并周期性触发 Kubelet 工作记录每个节点上运行的 addon必要时禁用见下文Pod 数量0 个 pod 与 100 个 pod 的节点Kubelet 开销完全不同在多个 Pod 数量档位下分别测量并等待系统进入稳态Pod 负载类型空闲 pod 与有真实负载的 pod 结果不同默认用 pause 镜像特殊场景用轻量任务如 pingPod 功能特性是否配置探针、卷、容器数量等直接影响 Kubelet 工作按目标场景配置 liveness/readiness 探针、卷等节点数量单节点易管理多节点可并行采样更稳健按需选择并记录集群搭建Cluster Set-up建立可信的基准环境Addon Pod测量中最大的隐藏变量默认情况下Kubernetes 会运行8 个 addon pod并且在kube-system命名空间中每个节点还会额外运行2 个 podfluentd-elasticsearch和kube-proxy。这些 addon 会持续产生 CPU 与内存开销更重要的是它们会周期性唤醒 Kubelet 执行工作污染你的测量结果。一个典型例子是Heapster它会定期轮询每个节点收集 stats 数据。如果不禁用 HeapsterKubelet 就必须持续响应这些统计请求——这部分服务统计数据的性能成本会被计入你的测量结果导致你测到的不是节点自身开销而是节点 监控栈的开销。禁用 Heapster 可以隐藏这部分成本得到更纯粹的 Kubelet 数据。禁用 Addon 的方法禁用 addon 非常简单SSH 登录 Kubernetes master 节点将对应 addon 从/etc/kubernetes/addons/目录移动到备份位置即可。addon 清单的完整来源可参考 cluster/addons 目录。不过文档也提醒禁用 addon 虽然能获得更一致的测量结果但禁用本身也可能带来性能影响——例如缺少 kube-proxy 时网络路径行为不同缺少 fluentd 时日志采集路径不同。因此必须结合你的测量目标决定哪些 addon 需要禁用并在报告中明确记录。用多少个 Pod、什么样的 Pod性能数据会随节点上的 Pod 数量剧烈变化0 个 pod 和 100 个 pod 的节点Kubelet 的负载完全不是一个量级。因此文档建议在多个 Pod 数量档位下分别测量。在单节点集群中通过扩展 ReplicationController 可以轻松控制 Pod 数量例如$ kubectl scale replicationcontroller pause --replicas100关键细节必须等待系统进入稳态steady-state再开始测量。Pod 创建、镜像拉取、调度绑定、PLEG 同步等过程都会带来瞬时峰值只有稳态下的数据才具有可比性。关于 Pod 类型文档给出两条重要经验大多数情况下pause pod 能产生最一致的测量结果——因为系统不会被 Pod 内应用的真实负载所影响。pause 镜像是一个极简的空容器只负责保持 Pod 沙箱存在。但存在例外Kubernetes 在部分场景下专门对空闲 Pod做了优化例如cAdvisor housekeeping即 stats 收集逻辑会针对无所事事的容器做特殊处理。此时让 Pod 执行一个极轻量的任务比如简单的网络 ping反而更能反映真实成本。最后还应考虑目标 Pod 需要使用的特性如果目的是测量带探针场景下的性能就应该使用配置了liveness 或 readiness 探针的 Pod同样卷、容器数量、端口等特性都应按需配置。从 Kubelet 组件文档 可知探针由ProbeManager驱动稳态下每个探针都会周期性运行并触发结果更新这一机制正是带探针 Pod 开销更高的源码级解释。其他搭建建议节点数量是一个权衡单节点更容易管理日志、Pod、环境变量适合快速迭代测量方案多节点可以在并行收集更多数据得到更稳健的采样结果例如跨节点取均值、识别异常节点。建议在文档中记录最终采用的节点拓扑以及每种配置下的样本量。性能仪表盘Performance Dashboard持续追踪 Kubelet 资源占用自Kubernetes 1.22起Kubelet 的资源使用情况被纳入Kubernetes 性能仪表盘perf-dash进行跟踪地址为 perf-dash.k8s.io。该仪表盘由kubernetes/perf-tests仓库支撑用于持续监控上游 Kubelet 的 CPU / 内存资源占用趋势便于社区及早发现资源利用率的回归相关讨论可参见本仓库 sig-node/archive/ci-subgroup-notes-2021.md 中关于 perf 测试的会议记录。对于贡献者而言这提供了一个零成本的持续观测入口在自行搭建集群做单次测量之前可以先查看仪表盘上的历史趋势判断某个 commit 的改动是否已经引起资源占用变化。E2E 性能测试整体资源占用采集kubelet_perf.go测试定位与入口对于收集节点组件整体资源使用情况Kubernetes 提供了端到端测试test/e2e/node/kubelet_perf.go。该测试的定位是集群级 e2e 性能测试与仅测试 Kubelet 的 node e2e 测试不同它需要一套完整集群来运行。运行前置条件确保有一个按 集群搭建 一节正确配置的e2e 集群在运行文档使用kubetest --up拉起集群必须按上文要求做好 addon、Pod 数量等配置。运行命令$ kubetest --test --test_args--ginkgo.focusresource\susage\stracking--ginkgo.focus使用正则匹配要运行的测试用例这里的resource usage tracking即匹配 kubelet_perf 相关的性能测试规格。如果需要自定义测试中的 Pod 数量或其他参数请修改测试代码后重新编译测试二进制$ make WHATtest/e2e/e2e.test这是文档特别强调的一步e2e 测试二进制是预编译的修改参数后不重新编译改动不会生效。已知限制文档明确说明由于这些测试非常耗时目前并未在 CI 中运行见 kubernetes/kubernetes issue #81490 的讨论。这意味着该测试目前主要靠社区成员手动、按需运行运行结果不具备 CI 的持续覆盖因此更需要测量者严格遵守可复现性要求记录 commit、版本、配置。Node E2E 性能测试在性能敏感负载下测 Kubelet测试定位与入口与集群级 e2e 性能测试不同Node E2E 性能测试test/e2e_node/node_perf_test.go的目标是在部署了性能敏感工作负载之后测量节点Kubelet的性能表现。它属于 node e2e 测试体系只需单节点基础设施Kubelet kube-apiserver etcd无需完整控制平面。相关资源测试源码test/e2e_node/node_perf_test.go结果看板TestGrid 的sig-node-kubelet页面下的node-performance-test通道运行方法先按照 Node e2e 测试指南 完成环境准备本仓库中该指南详细覆盖了 etcd、containerd、CNI 插件的安装与配置然后运行$ make test-e2e-node FOCUSNode Performance Testing SKIP PARALLELISM1参数说明FOCUSNode Performance Testing只运行名称匹配该正则的性能测试SKIP不跳过任何用例node e2e 默认会跳过[Flaky]、[Slow]、[Serial]类用例此处显式清空PARALLELISM1串行执行保证性能测试之间互不干扰。Node E2E 测试机制的源码视角从本仓库 node e2e 代码文档 可以深入理解这套测试的底层机制node e2e 与常规 e2e 的本质区别在于只测节点组件 Kubelet基础设施只需要 Kubelet、kube-apiserver 与 etcd测试套件提供**本地运行器local runner与远程运行器remote runner目前仅集成 GCP**两个入口本地运行时make test-e2e-node会依次请求 sudo 权限 → 构建 Kubernetes 源码 → 启动本地 etcd、kube-apiserver、kubelet → 运行测试 → 输出结果到 STDOUT → 停止各进程启动顺序由test/e2e_node/services管理startEtcd→startAPIServer→startNamespaceControllerKubelet 则在测试框架中以子进程方式在后台拉起ginkgo.SynchronizedBeforeSuite阶段还会执行系统校验--system-validate-mode基于k8s.io/system-validators校验 docker/OS 等环境、按NodePrePullImageList预拉取测试镜像然后启动服务并waitForNodeReady()。这解释了为什么性能测试能拿到干净的数据整套基础设施由测试框架独立拉起与宿主环境隔离测量对象就是单节点上的 Kubelet 本身。更多运行控制参数e2e-node-tests.md 还提供了与性能测量强相关的控制参数本地有 swap 的机器需传TEST_ARGS--kubelet-flags--fail-swap-onfalse否则 Kubelet 默认拒绝启动远程运行时可用REMOTEtrue并配合IMAGES、HOSTS、IMAGE_PROJECT、INSTANCE_PREFIX等控制目标主机RUN_UNTIL_FAILUREtrue可让测试持续运行直到失败适合排查偶发性性能异常CLEANUPfalse保留 Kubelet 进程与二进制便于手工调试查看全部可用参数make test-e2e-node PRINT_HELPy。Profiling用 pprof 剖析 Kubelet 的 CPU 与内存启用 pprof 端点Kubelet 内置了Go pprof handlers来自net/http/pprof标准库可以通过 HTTP 端点直接拉取性能剖析数据。启用方式有两种任选其一以命令行 flag 方式启动 Kubelet--enable-debugging-handlerstrue在 Kubelet 配置文件中设置EnableDebuggingHandlerstrue采集 CPU profile启用后通过kubectl proxy建立本地代理即可用 curl 拉取 profile$ kubectl proxy Starting to serve on 127.0.0.1:8001 $ curl -G http://localhost:8001/api/v1/proxy/nodes/${NODE}:10250/debug/pprof/profile?seconds${DURATION_SECONDS} $OUTPUT $ KUBELET_BIN_output/dockerized/bin/linux/amd64/kubelet $ go tool pprof -web $KUBELET_BIN $OUTPUT命令逐段说明kubectl proxy 在本地127.0.0.1:8001建立到 API server 的代理curl 通过代理路径访问nodes/${NODE}:10250上的 Kubelet 调试端点${NODE}替换为目标节点名${DURATION_SECONDS}为采样时长例如 30${OUTPUT}为保存 profile 的文件路径KUBELET_BIN指向与运行中 Kubelet同版本的 kubelet 二进制符号表需要与之匹配pprof 才能正确解析调用栈go tool pprof -web在浏览器中打开调用关系图直观展示热点函数。提示--enable-debugging-handlerstrue会暴露调试端点请仅在你有权访问的测试/开发集群上开启并在测量完成后关闭。采集堆内存heapprofilepprof 同样可以提供堆使用情况来自/debug/pprof/heap端点$ curl -G http://localhost:8001/api/v1/proxy/nodes/${NODE}:10250/debug/pprof/heap $OUTPUT_HEAP $ go tool pprof -web $KUBELET_BIN $OUTPUT_HEAP堆 profile 可用于定位内存泄漏或高频分配热点。关于 Go profiling 的更多细节可参考 Go 官方的《Profiling Go Programs》。pprof 与 Kubelet 内部机制的对应结合 Kubelet 组件文档你可以把 profile 中的热点函数映射到实际工作机制上SyncLoop / SyncPodKubelet 的核心工作循环每个 Pod 都有独立的 worker goroutinepod_workers.goPod 数量越多这些 goroutine 的开销越明显——这正是Pod 数量影响性能的源码依据PLEGPod Lifecycle Event Generator默认每 ~2 秒轮询一次运行时以检测状态变化是稳态下周期性 CPU 开销的重要来源之一cAdvisor housekeepingstats 收集周期性采集容器统计信息即文档提到的针对空闲 Pod 做优化的机制所在探针ProbesProbeManager为每个配置了探针的 Pod 运行独立 worker 周期性探测。如果在 profile 中看到这些函数占据显著比例就能反向指导测量设计——例如区分稳态同步开销与Pod 创建峰值开销。Benchmarks在写代码前先考虑 Go Benchmark为什么先考虑 Benchmark文档给出了一条非常务实的工作流建议在费尽周折搭建真实集群测量之前先问自己——我需要的数据能否通过一个 Benchmark 测试获得Go 提供了极其简单的基准测试机制只需在_test.go文件中编写形如BenchmarkXxx(b *testing.B)的函数即可。对于纯逻辑、数据结构、算法层面的性能问题例如某种计算是否值得优化Benchmark 远比起一个真实集群快速、便宜、可复现。只有那些依赖真实运行时、真实调度、真实网络栈的问题才值得动用前文的集群测量手段。编写 Benchmark 的标准模式// In foo_test.go func BenchmarkFoo(b *testing.B) { b.StopTimer() setupFoo() // Perform any global setup b.StartTimer() for i : 0; i b.N; i { foo() // Functionality to measure } }要点b.StopTimer()/b.StartTimer()把全局初始化开销排除在计时之外——setupFoo()这类一次性准备工作不应计入被测函数的耗时循环体for i : 0; i b.N; ib.N由 testing 框架自动调整从 1 开始倍增直到运行时间稳定在基准时长阈值附近被测函数必须放在这个循环内执行被测对象foo()只放需要测量的函数不要混入无关工作。运行 Benchmark$ go test -bench. -benchtime${SECONDS}s foo_test.go参数说明-bench.正则匹配所有 Benchmark 函数.匹配全部也可写-benchBenchmarkFoo只跑特定函数-benchtime${SECONDS}s每个 Benchmark 至少运行指定的秒数例如-benchtime10s比默认的固定迭代次数更能反映稳态性能foo_test.go被测测试文件路径。现状与后续方向原文档 TODO 的延续原文档列出的 TODO 反映了该领域仍在演进测量 docker 性能taotao 认领扩充集群搭建章节测量磁盘使用情况vishh 认领测量内存使用情况yujuhong 认领增加监控 Kubelet 指标例如使用 Prometheus的章节。结合本仓库 sig-node/archive/ci-subgroup-notes-2021.md 中的记录可以看到后续进展社区曾讨论 node performance 测试文档的现状与重构指向本文所依据的 node-performance-testing.md、kubelet_perf.go为何未进入kubelet-serial测试、以及资源利用回归被纳入kubernetes/perf-tests仓库跟踪等议题。这说明节点性能测量是一个持续演化的领域社区正在逐步把手动测量沉淀为持续跟踪。总结一份可信的节点性能测量清单把全文要点浓缩为可直接执行的检查清单记录测量元数据Kubernetes commit/版本、容器运行时版本、集群拓扑与配置控制变量明确 addon pod必要时按需禁用、Pod 数量多档位、Pod 类型默认 pause特殊场景用轻量任务、Pod 特性探针、卷等、节点数量等待稳态任何测量开始前确保系统已进入稳态选择测量工具持续趋势 → Kubernetes 性能仪表盘1.22集群整体资源占用 →kubelet_perf.gokubetest --test --test_args--ginkgo.focusresource\susage\stracking改参数后记得make WHATtest/e2e/e2e.test单节点 Kubelet 性能 →node_perf_test.gomake test-e2e-node FOCUSNode Performance Testing SKIP PARALLELISM1定位热点 → Kubelet pprof--enable-debugging-handlerstruego tool pprof -web纯逻辑性能 → 先写 Go Benchmarkgo test -bench. -benchtime...如实记录测量结果必须与第 1 步的元数据绑定才能跨版本、跨 commit 比较。参考文档仓库内节点性能测量原文档Node e2e 测试运行指南Node e2e 测试代码机制说明Kubelet 组件结构与同步循环解析SIG Node 开发文档总览SIG Node 职责与范围【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Kubernetes 节点性能测试与剖析完整指南：集群搭建、E2E 测试、pprof 剖析与 Benchmark（SIG Node）
Kubernetes 节点性能测试与剖析完整指南集群搭建、E2E 测试、pprof 剖析与 BenchmarkSIG Node【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community导读本文是 Kubernetes SIG Node 官方《Measuring Node Performance》文档的深度展开版系统讲解在真实 Kubernetes 集群中测量 Node 组件尤其是 Kubelet性能时的常见陷阱、集群搭建要点以及四类可用的测量手段性能仪表盘、集群 E2E 性能测试、Node E2E 性能测试、Go pprof 剖析与 Benchmark。读完本文你将能够搭建可复现的基准环境正确运行kubelet_perf.go与node_perf_test.go两类性能测试并用go tool pprof定位 Kubelet 的 CPU 与堆内存热点最终产出一份可信、可比较的节点性能数据。为什么节点性能测量容易出错测量前的核心认知测量节点性能Measuring Node Performance并不只是跑一个压测脚本那么简单。文档开篇即指出有大量因素会显著影响节点性能数据因此在搭建集群时必须格外谨慎确保你测量的是你想要测量的东西。其中最容易被忽视的一点是性能会随 commit 变化剧烈波动。Kubernetes 是高速迭代的项目每次代码提交都可能引入性能回归或优化。因此文档强烈建议精确记录测量时使用的Kubernetes 版本或 commit记录容器运行时container runtime版本如 containerd、CRI-O 等记录集群的完整搭建配置节点规格、内核、cgroup 驱动等。只有把这些测量元数据写清楚后续才能在不同 commit 之间、不同版本之间做有意义的性能对比。从本仓库的定位来看该文档隶属于 SIG Node 开发文档是社区贡献者在开发 Kubelet 相关功能时必须掌握的测量方法论。影响测量结果的关键维度从文档与 Kubernetes 实现来看至少有以下维度必须在测量前明确维度影响应对建议Addon Pod 数量与分布默认 8 个 addon pod 每节点 2 个fluentd-elasticsearch与kube-proxy会消耗资源并周期性触发 Kubelet 工作记录每个节点上运行的 addon必要时禁用见下文Pod 数量0 个 pod 与 100 个 pod 的节点Kubelet 开销完全不同在多个 Pod 数量档位下分别测量并等待系统进入稳态Pod 负载类型空闲 pod 与有真实负载的 pod 结果不同默认用 pause 镜像特殊场景用轻量任务如 pingPod 功能特性是否配置探针、卷、容器数量等直接影响 Kubelet 工作按目标场景配置 liveness/readiness 探针、卷等节点数量单节点易管理多节点可并行采样更稳健按需选择并记录集群搭建Cluster Set-up建立可信的基准环境Addon Pod测量中最大的隐藏变量默认情况下Kubernetes 会运行8 个 addon pod并且在kube-system命名空间中每个节点还会额外运行2 个 podfluentd-elasticsearch和kube-proxy。这些 addon 会持续产生 CPU 与内存开销更重要的是它们会周期性唤醒 Kubelet 执行工作污染你的测量结果。一个典型例子是Heapster它会定期轮询每个节点收集 stats 数据。如果不禁用 HeapsterKubelet 就必须持续响应这些统计请求——这部分服务统计数据的性能成本会被计入你的测量结果导致你测到的不是节点自身开销而是节点 监控栈的开销。禁用 Heapster 可以隐藏这部分成本得到更纯粹的 Kubelet 数据。禁用 Addon 的方法禁用 addon 非常简单SSH 登录 Kubernetes master 节点将对应 addon 从/etc/kubernetes/addons/目录移动到备份位置即可。addon 清单的完整来源可参考 cluster/addons 目录。不过文档也提醒禁用 addon 虽然能获得更一致的测量结果但禁用本身也可能带来性能影响——例如缺少 kube-proxy 时网络路径行为不同缺少 fluentd 时日志采集路径不同。因此必须结合你的测量目标决定哪些 addon 需要禁用并在报告中明确记录。用多少个 Pod、什么样的 Pod性能数据会随节点上的 Pod 数量剧烈变化0 个 pod 和 100 个 pod 的节点Kubelet 的负载完全不是一个量级。因此文档建议在多个 Pod 数量档位下分别测量。在单节点集群中通过扩展 ReplicationController 可以轻松控制 Pod 数量例如$ kubectl scale replicationcontroller pause --replicas100关键细节必须等待系统进入稳态steady-state再开始测量。Pod 创建、镜像拉取、调度绑定、PLEG 同步等过程都会带来瞬时峰值只有稳态下的数据才具有可比性。关于 Pod 类型文档给出两条重要经验大多数情况下pause pod 能产生最一致的测量结果——因为系统不会被 Pod 内应用的真实负载所影响。pause 镜像是一个极简的空容器只负责保持 Pod 沙箱存在。但存在例外Kubernetes 在部分场景下专门对空闲 Pod做了优化例如cAdvisor housekeeping即 stats 收集逻辑会针对无所事事的容器做特殊处理。此时让 Pod 执行一个极轻量的任务比如简单的网络 ping反而更能反映真实成本。最后还应考虑目标 Pod 需要使用的特性如果目的是测量带探针场景下的性能就应该使用配置了liveness 或 readiness 探针的 Pod同样卷、容器数量、端口等特性都应按需配置。从 Kubelet 组件文档 可知探针由ProbeManager驱动稳态下每个探针都会周期性运行并触发结果更新这一机制正是带探针 Pod 开销更高的源码级解释。其他搭建建议节点数量是一个权衡单节点更容易管理日志、Pod、环境变量适合快速迭代测量方案多节点可以在并行收集更多数据得到更稳健的采样结果例如跨节点取均值、识别异常节点。建议在文档中记录最终采用的节点拓扑以及每种配置下的样本量。性能仪表盘Performance Dashboard持续追踪 Kubelet 资源占用自Kubernetes 1.22起Kubelet 的资源使用情况被纳入Kubernetes 性能仪表盘perf-dash进行跟踪地址为 perf-dash.k8s.io。该仪表盘由kubernetes/perf-tests仓库支撑用于持续监控上游 Kubelet 的 CPU / 内存资源占用趋势便于社区及早发现资源利用率的回归相关讨论可参见本仓库 sig-node/archive/ci-subgroup-notes-2021.md 中关于 perf 测试的会议记录。对于贡献者而言这提供了一个零成本的持续观测入口在自行搭建集群做单次测量之前可以先查看仪表盘上的历史趋势判断某个 commit 的改动是否已经引起资源占用变化。E2E 性能测试整体资源占用采集kubelet_perf.go测试定位与入口对于收集节点组件整体资源使用情况Kubernetes 提供了端到端测试test/e2e/node/kubelet_perf.go。该测试的定位是集群级 e2e 性能测试与仅测试 Kubelet 的 node e2e 测试不同它需要一套完整集群来运行。运行前置条件确保有一个按 集群搭建 一节正确配置的e2e 集群在运行文档使用kubetest --up拉起集群必须按上文要求做好 addon、Pod 数量等配置。运行命令$ kubetest --test --test_args--ginkgo.focusresource\susage\stracking--ginkgo.focus使用正则匹配要运行的测试用例这里的resource usage tracking即匹配 kubelet_perf 相关的性能测试规格。如果需要自定义测试中的 Pod 数量或其他参数请修改测试代码后重新编译测试二进制$ make WHATtest/e2e/e2e.test这是文档特别强调的一步e2e 测试二进制是预编译的修改参数后不重新编译改动不会生效。已知限制文档明确说明由于这些测试非常耗时目前并未在 CI 中运行见 kubernetes/kubernetes issue #81490 的讨论。这意味着该测试目前主要靠社区成员手动、按需运行运行结果不具备 CI 的持续覆盖因此更需要测量者严格遵守可复现性要求记录 commit、版本、配置。Node E2E 性能测试在性能敏感负载下测 Kubelet测试定位与入口与集群级 e2e 性能测试不同Node E2E 性能测试test/e2e_node/node_perf_test.go的目标是在部署了性能敏感工作负载之后测量节点Kubelet的性能表现。它属于 node e2e 测试体系只需单节点基础设施Kubelet kube-apiserver etcd无需完整控制平面。相关资源测试源码test/e2e_node/node_perf_test.go结果看板TestGrid 的sig-node-kubelet页面下的node-performance-test通道运行方法先按照 Node e2e 测试指南 完成环境准备本仓库中该指南详细覆盖了 etcd、containerd、CNI 插件的安装与配置然后运行$ make test-e2e-node FOCUSNode Performance Testing SKIP PARALLELISM1参数说明FOCUSNode Performance Testing只运行名称匹配该正则的性能测试SKIP不跳过任何用例node e2e 默认会跳过[Flaky]、[Slow]、[Serial]类用例此处显式清空PARALLELISM1串行执行保证性能测试之间互不干扰。Node E2E 测试机制的源码视角从本仓库 node e2e 代码文档 可以深入理解这套测试的底层机制node e2e 与常规 e2e 的本质区别在于只测节点组件 Kubelet基础设施只需要 Kubelet、kube-apiserver 与 etcd测试套件提供**本地运行器local runner与远程运行器remote runner目前仅集成 GCP**两个入口本地运行时make test-e2e-node会依次请求 sudo 权限 → 构建 Kubernetes 源码 → 启动本地 etcd、kube-apiserver、kubelet → 运行测试 → 输出结果到 STDOUT → 停止各进程启动顺序由test/e2e_node/services管理startEtcd→startAPIServer→startNamespaceControllerKubelet 则在测试框架中以子进程方式在后台拉起ginkgo.SynchronizedBeforeSuite阶段还会执行系统校验--system-validate-mode基于k8s.io/system-validators校验 docker/OS 等环境、按NodePrePullImageList预拉取测试镜像然后启动服务并waitForNodeReady()。这解释了为什么性能测试能拿到干净的数据整套基础设施由测试框架独立拉起与宿主环境隔离测量对象就是单节点上的 Kubelet 本身。更多运行控制参数e2e-node-tests.md 还提供了与性能测量强相关的控制参数本地有 swap 的机器需传TEST_ARGS--kubelet-flags--fail-swap-onfalse否则 Kubelet 默认拒绝启动远程运行时可用REMOTEtrue并配合IMAGES、HOSTS、IMAGE_PROJECT、INSTANCE_PREFIX等控制目标主机RUN_UNTIL_FAILUREtrue可让测试持续运行直到失败适合排查偶发性性能异常CLEANUPfalse保留 Kubelet 进程与二进制便于手工调试查看全部可用参数make test-e2e-node PRINT_HELPy。Profiling用 pprof 剖析 Kubelet 的 CPU 与内存启用 pprof 端点Kubelet 内置了Go pprof handlers来自net/http/pprof标准库可以通过 HTTP 端点直接拉取性能剖析数据。启用方式有两种任选其一以命令行 flag 方式启动 Kubelet--enable-debugging-handlerstrue在 Kubelet 配置文件中设置EnableDebuggingHandlerstrue采集 CPU profile启用后通过kubectl proxy建立本地代理即可用 curl 拉取 profile$ kubectl proxy Starting to serve on 127.0.0.1:8001 $ curl -G http://localhost:8001/api/v1/proxy/nodes/${NODE}:10250/debug/pprof/profile?seconds${DURATION_SECONDS} $OUTPUT $ KUBELET_BIN_output/dockerized/bin/linux/amd64/kubelet $ go tool pprof -web $KUBELET_BIN $OUTPUT命令逐段说明kubectl proxy 在本地127.0.0.1:8001建立到 API server 的代理curl 通过代理路径访问nodes/${NODE}:10250上的 Kubelet 调试端点${NODE}替换为目标节点名${DURATION_SECONDS}为采样时长例如 30${OUTPUT}为保存 profile 的文件路径KUBELET_BIN指向与运行中 Kubelet同版本的 kubelet 二进制符号表需要与之匹配pprof 才能正确解析调用栈go tool pprof -web在浏览器中打开调用关系图直观展示热点函数。提示--enable-debugging-handlerstrue会暴露调试端点请仅在你有权访问的测试/开发集群上开启并在测量完成后关闭。采集堆内存heapprofilepprof 同样可以提供堆使用情况来自/debug/pprof/heap端点$ curl -G http://localhost:8001/api/v1/proxy/nodes/${NODE}:10250/debug/pprof/heap $OUTPUT_HEAP $ go tool pprof -web $KUBELET_BIN $OUTPUT_HEAP堆 profile 可用于定位内存泄漏或高频分配热点。关于 Go profiling 的更多细节可参考 Go 官方的《Profiling Go Programs》。pprof 与 Kubelet 内部机制的对应结合 Kubelet 组件文档你可以把 profile 中的热点函数映射到实际工作机制上SyncLoop / SyncPodKubelet 的核心工作循环每个 Pod 都有独立的 worker goroutinepod_workers.goPod 数量越多这些 goroutine 的开销越明显——这正是Pod 数量影响性能的源码依据PLEGPod Lifecycle Event Generator默认每 ~2 秒轮询一次运行时以检测状态变化是稳态下周期性 CPU 开销的重要来源之一cAdvisor housekeepingstats 收集周期性采集容器统计信息即文档提到的针对空闲 Pod 做优化的机制所在探针ProbesProbeManager为每个配置了探针的 Pod 运行独立 worker 周期性探测。如果在 profile 中看到这些函数占据显著比例就能反向指导测量设计——例如区分稳态同步开销与Pod 创建峰值开销。Benchmarks在写代码前先考虑 Go Benchmark为什么先考虑 Benchmark文档给出了一条非常务实的工作流建议在费尽周折搭建真实集群测量之前先问自己——我需要的数据能否通过一个 Benchmark 测试获得Go 提供了极其简单的基准测试机制只需在_test.go文件中编写形如BenchmarkXxx(b *testing.B)的函数即可。对于纯逻辑、数据结构、算法层面的性能问题例如某种计算是否值得优化Benchmark 远比起一个真实集群快速、便宜、可复现。只有那些依赖真实运行时、真实调度、真实网络栈的问题才值得动用前文的集群测量手段。编写 Benchmark 的标准模式// In foo_test.go func BenchmarkFoo(b *testing.B) { b.StopTimer() setupFoo() // Perform any global setup b.StartTimer() for i : 0; i b.N; i { foo() // Functionality to measure } }要点b.StopTimer()/b.StartTimer()把全局初始化开销排除在计时之外——setupFoo()这类一次性准备工作不应计入被测函数的耗时循环体for i : 0; i b.N; ib.N由 testing 框架自动调整从 1 开始倍增直到运行时间稳定在基准时长阈值附近被测函数必须放在这个循环内执行被测对象foo()只放需要测量的函数不要混入无关工作。运行 Benchmark$ go test -bench. -benchtime${SECONDS}s foo_test.go参数说明-bench.正则匹配所有 Benchmark 函数.匹配全部也可写-benchBenchmarkFoo只跑特定函数-benchtime${SECONDS}s每个 Benchmark 至少运行指定的秒数例如-benchtime10s比默认的固定迭代次数更能反映稳态性能foo_test.go被测测试文件路径。现状与后续方向原文档 TODO 的延续原文档列出的 TODO 反映了该领域仍在演进测量 docker 性能taotao 认领扩充集群搭建章节测量磁盘使用情况vishh 认领测量内存使用情况yujuhong 认领增加监控 Kubelet 指标例如使用 Prometheus的章节。结合本仓库 sig-node/archive/ci-subgroup-notes-2021.md 中的记录可以看到后续进展社区曾讨论 node performance 测试文档的现状与重构指向本文所依据的 node-performance-testing.md、kubelet_perf.go为何未进入kubelet-serial测试、以及资源利用回归被纳入kubernetes/perf-tests仓库跟踪等议题。这说明节点性能测量是一个持续演化的领域社区正在逐步把手动测量沉淀为持续跟踪。总结一份可信的节点性能测量清单把全文要点浓缩为可直接执行的检查清单记录测量元数据Kubernetes commit/版本、容器运行时版本、集群拓扑与配置控制变量明确 addon pod必要时按需禁用、Pod 数量多档位、Pod 类型默认 pause特殊场景用轻量任务、Pod 特性探针、卷等、节点数量等待稳态任何测量开始前确保系统已进入稳态选择测量工具持续趋势 → Kubernetes 性能仪表盘1.22集群整体资源占用 →kubelet_perf.gokubetest --test --test_args--ginkgo.focusresource\susage\stracking改参数后记得make WHATtest/e2e/e2e.test单节点 Kubelet 性能 →node_perf_test.gomake test-e2e-node FOCUSNode Performance Testing SKIP PARALLELISM1定位热点 → Kubelet pprof--enable-debugging-handlerstruego tool pprof -web纯逻辑性能 → 先写 Go Benchmarkgo test -bench. -benchtime...如实记录测量结果必须与第 1 步的元数据绑定才能跨版本、跨 commit 比较。参考文档仓库内节点性能测量原文档Node e2e 测试运行指南Node e2e 测试代码机制说明Kubelet 组件结构与同步循环解析SIG Node 开发文档总览SIG Node 职责与范围【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考