Cilium Connectivity Perf 完全指南：用 `cilium connectivity perf` 精确测量 eBPF 数据面网络性能

Cilium Connectivity Perf 完全指南用cilium connectivity perf精确测量 eBPF 数据面网络性能【免费下载链接】ciliumeBPF-based Networking, Security, and Observability项目地址: https://gitcode.com/GitHub_Trending/ci/cilium导读cilium connectivity perf是 Cilium CLI 内置的网络性能基准测试子命令用于在 Kubernetes 集群中通过 netperf 对 Cilium eBPF 数据面进行系统化的吞吐量、延迟与 QoS 测量。本文以该命令的完整参数手册为骨架结合 Cilium 仓库源码cilium-cli/cli/connectivity.go、cilium-cli/connectivity/perf/benchmarks/netperf/等深度剖析其测试场景编排、指标解析、报告导出与内核性能分析机制帮助你掌握从单条命令到源码级定制性能测试的完整技能。命令概览一次命令多维性能画像cilium connectivity perf以一句话概括其用途——Test network performance测试网络性能。它属于cilium connectivity命令族的子命令参见 cilium connectivity后者定位是 Connectivity troubleshooting 连通性排障工具族用法如下cilium connectivity perf [flags]该命令在真实集群中自动完成以下工作在选定的节点上以 Deployment 形式拉起专用的性能测试 Pod镜像默认为quay.io/cilium/network-perf:...在 Pod 与 Pod、Pod 与 Host、Host 与 Host 等多种流量场景之间运行 netperf 基准最终在终端输出结构化汇总表。从源码看命令的PreRunE钩子cilium-cli/cli/connectivity.go#L249-L268会强制设置三个关键参数params.Perf true声明本次运行是性能测试模式params.ForceDeploy true强制重新部署测试资源params.Hubble false性能测试期间关闭 Hubble 流采集避免观测开销干扰测量结果。此外如果指定了--report-dir会预先创建报告目录若只请求内核 profile 而未设置报告目录则会给出警告并自动禁用 profile 采集。核心参数全解掌握性能测试的每一个旋钮perf子命令的参数可划分为四类测试类型选择、流量拓扑与节点控制、测试执行控制、环境与输出控制。以下参数默认值均取自当前仓库cilium-cli/cli/connectivity.go#L272-L306。测试类型参数吞吐量、延迟与 QoS参数默认值说明--throughputtrue运行吞吐量测试TCP_STREAM关闭可跳过--throughput-multitrue运行多流多连接吞吐量测试并行度由--streams控制--rrtrue运行 Request/ResponseTCP_RR往返延迟测试--crrfalse运行 Connect/Request/ResponseTCP_CRR测试包含建连开销--udpfalse启用 UDP 测试配合上述开关生成 UDP_STREAM / UDP_STREAM_MULTI / UDP_RR--net-qosfalse测试 Pod 网络 QoS服务质量管理针对带宽优先级注解--bandwidthfalse测试 Pod 网络带宽限制bandwidth limit 强制从 netperf/perfpod.go#L52-L77 可以看到测试矩阵的组装逻辑Throughput决定加入TCP_STREAMThroughputMulti决定加入TCP_STREAM_MULTIUDP为每个 STREAM 测试追加对应 UDP 变体CRR与RR分别追加TCP_CRR、TCP_RR。也就是说默认执行的是 TCP_STREAM、TCP_STREAM_MULTI、TCP_RR 三类测试。流量拓扑参数谁到谁、同节点还是跨节点参数默认值说明--host-nettrue测试 Host 网络客户端与服务端均为 HostNetwork Pod--pod-nettrue测试 Pod 网络两端均为普通 Pod流量穿越 Cilium eBPF 数据面--pod-to-hostfalse测试 Pod → Host 方向流量--host-to-podfalse测试 Host → Pod 方向流量--same-nodetrue客户端与服务端调度到同一节点--other-nodetrue客户端与服务端调度到不同节点跨节点流量源码在 netperf/perfpod.go#L92-L103 通过检查 Pod 名称中是否包含PerfHostName标记来决定场景归属clientHost serverHost走HostNetclientHost !serverHost走HostToPod!clientHost serverHost走PodToHost两端都不是 Host 则走PodNet同时通过名称中的PerfOtherNode标记区分same-node与other-node场景名最终形如pod-to-pod_same-node、pod-to-pod_other-node等组合。注意当--net-qos或--bandwidth开启时框架会自动关闭无关拓扑维度。见 deployment.go#L2499-L2530NetQos会强制HostNetfalseBandwidth会强制HostNet、PodNet、SameNode、OtherNode全部为false仅保留专门的带宽限制验证场景。执行控制参数时长、样本、并行度参数默认值说明--duration duration10s每个性能测试的执行时长--samples int1每组测试重复采样的次数多轮取多次结果--streams uint4多流测试的并行连接数--msg-size int1024UDP 测试的消息大小字节TCP 不受影响--setup-delay duration0开始性能测试前的额外等待时长samples参数对应 perfpod.go#L89 的外层循环setup-delay在 perfpod.go#L79-L87 中实现——若大于 0会在启动测试前睡眠该时长常用于等待节点预热、负载均衡器收敛或集群处于稳定状态后再开始测量。环境与输出参数参数默认值说明--performance-image stringquay.io/cilium/network-perf:3.21-1788350426-c114a5dsha256:9c317f...性能测试镜像路径digest 固定以保证可复现性定义于 defaults/defaults.go#L190--report-dir string空将性能结果以 JSON 格式保存到该目录同时是 kernel profile 的保存目录--unsafe-capture-kernel-profilesfalse测试期间采集内核性能 profile警告仅建议在一次性disposable节点上运行因为它会在节点上安装额外软件并修改其配置--print-image-artifactsfalse打印使用的镜像制品信息--node-selector-server stringcilium.io/no-schedule!true服务端 Pod及同节点客户端的节点选择器label query--node-selector-client stringcilium.io/no-schedule!true跨节点客户端的节点选择器--test-namespace stringcilium-test执行连通性/性能测试的命名空间会按测试并发参数追加序号如cilium-test-1--namespace-labels map空为测试命名空间添加标签--tolerations strings空为测试 Pod 添加额外的 NoSchedule 容忍-d, --debugfalse显示调试消息关于节点选择器connectivity.go#L294-L303 有重要说明默认值排除非 Cilium 节点即打上cilium.io/no-schedule标签、例如通过cilium install --nodes-without-cilium加入的节点因为在这些节点上 perf Pod 永远无法就绪——agent-not-readyNoExecute 污点只有在节点上运行了 Cilium Pod 后才会被移除。如果调用方确实想定向到这类节点如 scale-egw 场景可用自定义 selector 覆盖。父命令继承参数perf继承自cilium connectivity的通用认证与集群参数参数默认值说明--as string空以指定用户名普通用户或 ServiceAccount模拟执行操作--as-group stringArray空模拟的用户组可重复指定多个--context string空Kubernetes 配置上下文--helm-release-name stringciliumHelm release 名称--kubeconfig string空kubeconfig 文件路径-n, --namespace stringkube-systemCilium 运行所在命名空间也可通过环境变量CILIUM_NAMESPACE设置典型使用场景与命令示例1. 默认性能基线测量不附加任何参数即可对集群执行 Pod 网络 Host 网络、同节点 跨节点、吞吐 多流吞吐 往返延迟的完整基线测试每类测试运行 10 秒cilium connectivity perf2. 聚焦 Pod 网络的 UDP 多流吞吐关闭 Host 网络与延迟类测试仅跑 Pod 网络下的 UDP 多流吞吐消息大小调至 1400 字节接近典型 MTU 的 payload 尺寸使用 8 条并行流cilium connectivity perf \ --host-netfalse \ --pod-nettrue \ --throughputtrue \ --throughput-multitrue \ --rrfalse \ --udp \ --msg-size 1400 \ --streams 83. 高精度采样多轮样本与结果落盘--samples 3让每组测试重复 3 次--report-dir会把结果以 perfdash 兼容格式写入 JSON 文件cilium connectivity perf \ --samples 3 \ --duration 30s \ --report-dir ./perf-results4. 验证带宽限制Bandwidth Enforcement--bandwidth模式会为 Pod 设置带宽限速注解并验证吞吐被正确限制源码中累计吞吐超过阈值即判定失败见下文源码解析cilium connectivity perf --bandwidth5. 验证网络 QoS优先级带宽分配--net-qos模式会创建高/低优先级客户端通过bw-priority注解区分跨节点向同一服务端打流并校验高优流量与低优流量的带宽比例是否落在预期区间cilium connectivity perf --net-qos6. 定向到特定节点组通过选择器将服务端与跨节点客户端固定到指定标签的节点上默认排除cilium.io/no-schedule!true的节点cilium connectivity perf \ --node-selector-server kubernetes.io/hostnamenode-a \ --node-selector-client kubernetes.io/hostnamenode-b节点选择逻辑见 deployment.go#L2470-L2497CLI 会按 selector 分别列出节点并挑选服务端节点与客户端节点若两者处于不同可用区zone还会打印警告提示你可能并非本意。输出与报告解读从终端表格到 perfdash 兼容 JSON终端汇总表测试完成后框架在 context.go#L592-L638 输出两段汇总延迟表列包含Scenario | Node | Test | Duration | Min | Mean | Max | P50 | P90 | P99 | Transaction rate OP/s吞吐表列包含Scenario | Node | Test | Duration | Throughput Mb/s。其中Node列显示same-node或other-nodeTest列显示TCP_STREAM、TCP_STREAM_MULTI、TCP_RR等名称。例如延迟表的一行 pod-to-pod | same-node | TCP_RR | 10s | ... | ... | ... | ... | ... | ... | 12345.67netperf 指标解析细节所有结果都由 perfpod.go#L189-L229 的parseNetperfResult解析值得关注的点netperf 输出行以逗号分隔 9 个字段分别映射为延迟Min/Mean/Max/P50/P90/P99、事务速率Trans/s与吞吐量netperf 的延迟默认以**微秒µs**为单位、吞吐量以10^6 bits/s为单位代码通过parseDuration(valueus)和Throughput*1000000完成单位换算对于_STREAM结尾的测试丢弃延迟与事务速率字段并校验吞吐单位确为10^6bits/s否则直接判定失败对于_RR/_CRR测试则丢弃吞吐字段多流测试_MULTIperfpod.go#L239-L284会把--streams个 netperf 进程并行跑起来各进程输出先写入临时文件再统一cat避免交错输出只有 STREAM 类测试支持并行其余类型会直接报错。最终多流吞吐为各流结果求和。JSON 报告perfdash 兼容格式设置--report-dir后common/metrics.go#L151-L198 的ExportPerfSummaries会把全部结果按节点类型same-node / other-node与工具类型分组导出文件名为NetworkPerformance_benchmark_RFC3339时间戳.json。其数据模型dataItem/perfData借鉴自kubernetes/perf-tests的 perfdash 方案包含延迟指标只导出 P50/P90/P99 三个分位数注释明确说明 Max 会扭曲结果不适合长期追踪单位us事务速率单位ops/s吞吐量单位Mb/s。这意味着 Cilium CI 的性能回归数据可以直接对接 perfdash 这类可视化看板进行趋势追踪。源码级剖析测试资源编排与场景实现性能 Pod 的部署拓扑性能测试使用专门的 Deployment 集合见 deployment.go#L2341-L2460 区域服务端 perf Deployment可运行在 Host 网络或 Pod 网络同节点客户端 Deployment与服务端同节点跨节点客户端 DeploymentPerfOtherNode调度到另一节点可选的 profiler 容器用于内核 profile 采集。框架依据--host-net/--pod-net/--pod-to-host/--host-to-pod/--same-node/--other-node的组合动态决定创建哪些 Deployment、以何种 networkMode 启动。这也解释了为什么--net-qos/--bandwidth模式会自动关闭无关拓扑——它们各自有独立且更简单的部署模型。场景一Netperf通用性能基准构建入口在 builder/network_perf.gonetworkPerf.build注册名为network-perf的测试绑定netperf.Netperf()场景。运行时perfpod.go#L45-L164根据Throughput/ThroughputMulti/CRR/RR/UDP组装测试列表若SetupDelay 0先等待按Samples循环遍历所有客户端与服务端 Pod 组合按拓扑开关过滤出合法场景对每组组合运行NetperfCmd并通过PerfResults累积结果。底层 netperf 命令通过buildExecCommandperfpod.go#L166-L171构造/usr/local/bin/netperf -H serverIP -l duration -t TEST -- -R 1 \ -o MIN_LATENCY,MEAN_LATENCY,MAX_LATENCY,P50_LATENCY,P90_LATENCY,P99_LATENCY,TRANSACTION_RATE,THROUGHPUT,THROUGHPUT_UNITS-R 1表示取单次结果而非多次取均值方便 CLI 端做统一解析与单位校验。场景二Network QoS带宽优先级验证构建入口在 builder/network_qos.go实现为 netperf/priority.go 的NetQos场景。部署阶段deployment.go#L2499-L2510会创建两个不同优先级注解的客户端低优先级客户端bw-prio: 5高优先级客户端bw-prio: 6。测试以 30 秒时长、1.5MB 消息大小MsgSize: 1500000跑 TCP_STREAMpod-to-pod、跨节点分别累计高优与低优客户端的吞吐priority.go#L84-L104并校验高优/低优吞吐比例ratio必须落在[8, 9]区间否则测试失败——这是对 Cilium 带宽 QoS 机制通过bw-prio注解映射到 eBPF 数据面的优先级队列的直接端到端验证。场景三Bandwidth Limit带宽上限强制构建入口在 builder/network_bandwidth_limit.go实现为 netperf/bandwidth.go 的NetBandwidth场景。测试同样以 30 秒时长、1.5MB 消息大小运行 TCP_STREAM但客户端分为 ingress/egress 两组通过 Pod 名称中的ingress/egress关键字归类见getTestSet最终按组累计吞吐Mbit/s若某组累计吞吐超过 11 则判定 Bandwidth limit failed to enforced。该阈值对应设置了带宽限速注解如kubernetes.io/egress-bandwidth/kubernetes.io/ingress-bandwidth后允许的带宽上限。内核性能剖析--unsafe-capture-kernel-profiles的机制与风险该参数对应源码中的KernelProfilesprofiler/profiler.go。其工作流程仅当同时设置了--report-dir时才生效否则命令会打印 Requested kernel profiles, but report-dir is unset, skipping 并自动关闭connectivity.go#L258-L265测试期间服务端节点始终采集 profile跨节点场景下客户端节点也会采集采集通过nsenter --target1 --mount --进入节点 PID/mount 命名空间再执行perf record --freq 99 --all-cpus -g --delay delay -o /tmp/perf.data -- sleep duration为避免 profile 覆盖到非测试时间段记录会在测试开始后延迟1/10 时长启动并提前1/10 时长结束即实际记录窗口约为测试时长的 80%profiler.go#L63-L75采样频率 99Hz、覆盖所有 CPU、带调用栈-g随后通过perf script导出文本保存为report-dir/testName_server.perf与testName_client.perf。风险提示采集过程会在节点上安装/使用perf工具并通过 nsenter 侵入宿主机命名空间可能修改节点配置因此官方警告只能在可丢弃的一次性节点上运行。相关挂载校验逻辑可在 context.go#L592-L639 与 deployment.go#L2594-L2610 中看到。测试入口与 CI 使用建议perf子命令本身注册于 cilium-cli/cli/connectivity.go#L244-L310与cilium connectivity test共享同一套执行框架RunE区别仅在于perf 强制关闭 Hubble、强制重新部署并以性能结果而非连通性断言为输出。这意味着它天然可嵌入 CI通过--samples多次采样取中位数消除噪声通过--report-dir落盘 JSON 对接 perfdash 做长期回归通过--node-selector-*固定到专用性能节点避免被共享节点干扰。总结cilium connectivity perf是一个围绕 netperf 封装的、面向 Cilium eBPF 数据面的完整性能测量框架它用一组开关组合出吞吐单流/多流、延迟RR/CRR、UDP、带宽限制、QoS 五大维度支持 Pod/Host 四种拓扑与同/跨节点两种部署形态提供多样本采样、JSON 报告与内核 profile 三重输出能力。结合仓库源码cilium-cli/connectivity/perf/benchmarks/netperf/可以确认所有指标都经过严格的单位校验与解析微秒级延迟、10^6 bits/s 吞吐QoS 比例与带宽上限有明确的通过阈值报告格式兼容 perfdash——这让它既是日常性能排查的实用工具也是可接入 CI 的回归测试基座。【免费下载链接】ciliumeBPF-based Networking, Security, and Observability项目地址: https://gitcode.com/GitHub_Trending/ci/cilium创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考