ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

LinuxKit virtio/Hyper-V Socket 压力测试实战:从镜像构建到 Windows 端压测

LinuxKit virtio/Hyper-V Socket 压力测试实战:从镜像构建到 Windows 端压测 操作系统云原生容器运行时【免费下载链接】linuxkitA toolkit for building secure, portable and lean operating systems for containers项目地址https://gitcode.com/gh_mirrors/li/linuxkit点击查看免费下载导读本文围绕 LinuxKit 仓库中 test/pkg/virtsock/README.md 所述的压力测试方案展开讲解如何构建一个内置 virtio socket 与 Hyper-V socket 服务端的 LinuxKit 镜像并在 Windows 宿主机的 Hyper-V 虚拟机中完成大规模并发连接压测。读完本文你将掌握该测试容器的构建链路Dockerfile、镜像配置、服务端/客户端角色划分、完整的 Windows 端操作步骤以及sock_stress系列工具的常见参数用法。一、测试目标验证 VM 与宿主之间的 socket 通道LinuxKit 构建出的极简操作系统常以虚拟机形态运行如 Hyper-V、HyperKit、QEMU 等。当 guest 虚拟机与宿主机需要通信时除了网络接口之外还有一种更轻量的通道virtio socketvsock与 Hyper-V socketHvSocket / AF_HYPERV。前者用于 virtio 类虚拟化平台后者用于微软 Hyper-V 平台。test/pkg/virtsock/README.md 所描述的就是一套针对这两类 socket 的**压力测试stress test**方案目录内文件用于构建并运行一个容器容器中装有 socket 压力测试程序测试采用典型的server/client服务端/客户端模型服务端运行在虚拟机内部客户端运行在宿主机上本文场景为 Windows客户端会创建大量并发连接并向服务端发送随机数据服务端回显数据以此检验 virtio/Hyper-V socket 通道在高并发、短连接场景下的稳定性与吞吐表现。二、测试套件在仓库中的组成该测试套件由以下文件构成文件作用test/pkg/virtsock/Dockerfile多阶段构建产出内置压力测试程序的最小容器镜像test/pkg/virtsock/build.ymlLinuxKit 包构建元数据声明镜像名、架构与网络需求test/pkg/virtsock/README.md使用说明本文依据的原始文档从 README 的原始描述看构建脚本原指向../../cases/test-virtsock-server.yml按仓库根路径换算即test/cases/test-virtsock-server.yml该 YAML 的作用是构建一个在虚拟机内启动服务端的镜像不过在当前仓库树中该用例文件并未包含镜像构建的实际可执行证据以 test/pkg/virtsock/build.yml 为准。build.yml 内容非常简洁image: test-virtsock network: true arches: - amd64它声明了image: test-virtsock构建出的镜像名network: true镜像在构建/运行阶段需要网络能力Dockerfile 中需要联网git clone源码arches: [amd64]当前仅针对 amd64 架构构建Hyper-V 场景通常为 x86_64 宿主。三、服务端镜像的构建链路Dockerfile 深度解析test/pkg/virtsock/Dockerfile 采用 LinuxKit 常见的多阶段构建模式完整还原了服务端二进制sock_stress的产出过程第一阶段mirror基础运行环境FROM linuxkit/alpine:7f3944798557de5518a56e3437d7ed982701f224 AS mirror RUN mkdir -p /out/etc/apk cp -r /etc/apk/* /out/etc/apk/ RUN apk add --no-cache --initdb -p /out \ tini RUN rm -rf /out/etc/apk /out/lib/apk /out/var/cache基于 LinuxKit 官方 Alpine 基础镜像仅安装tini极简 init 进程用于正确回收僵尸进程并将 apk 元数据复制到/out随后清理缓存得到一个最小化的可运行根文件系统。第二阶段build编译 sock_stressFROM linuxkit/alpine:7f3944798557de5518a56e3437d7ed982701f224 AS build RUN apk add --no-cache go musl-dev git make ENV GOPATH/go PATH$PATH:/go/bin GO111MODULEoff ENV VIRTSOCK_COMMITf1e32d3189e0dbb81c0e752a4e214617487eb41f RUN mkdir -p $GOPATH/src/github.com/linuxkit \ cd $GOPATH/src/github.com/linuxkit \ git clone https://github.com/linuxkit/virtsock.git WORKDIR $GOPATH/src/github.com/linuxkit/virtsock RUN git checkout $VIRTSOCK_COMMIT RUN make bin/sock_stress.linux \ cp -a bin/sock_stress.linux /sock_stress安装 Go、musl-dev静态链接所需、git 与 make将VIRTSOCK_COMMIT固定到具体 commitf1e32d3...保证构建可复现——这是 LinuxKit 一贯的可复现构建实践从 linuxkit/virtsock 仓库克隆源码并检出该 commit执行make bin/sock_stress.linux编译出 Linux 端压力测试二进制复制为/sock_stress。第三阶段scratch最终镜像FROM scratch COPY --frommirror /out/ / COPY --frombuild sock_stress usr/bin/sock_stress CMD [/sbin/tini, /usr/bin/sock_stress, -s, -v, 1]基于scratch仅包含 mirror 阶段的运行时文件与编译产物最终容器启动命令为tini sock_stress -s -v 1其中-s表示使用**短连接short-lived connections**模式-v 1表示输出级别/详细程度为 1最终镜像内默认以服务端角色启动sock_stress 不加-c即作为 server 监听。四、sock_stress 工具能力与参数说明sock_stress是一个灵活的 socket 压力测试程序从仓库内另一处脚本 test/pkg/ns/runc-net.sh 的注释与用法可以确认其能力边界a flexible stress program for UDP/TCP/virtio/Hyper-V/Unix Domain sockets即它支持UDP / TCP / virtio socket / Hyper-V socket / Unix Domain Socket五类协议且支持多并发连接多个连接同时建立可配置数据量客户端向服务端发送数据服务端原样回显echo短连接 vs 长连接通过配置每次连接传输的数据量可以制造大量短生命周期连接压测连接建立/拆除路径默认则是随机且相对较大的数据量角色可互换服务端默认跑在容器/VM 内、客户端在外部也可通过-r反转。在 test/pkg/ns/runc-net.sh 中体现的sock_stress参数如下该脚本主要用于网络命名空间压测但参数语义与 virtsock 场景一致参数含义默认值-p协议tcp/udp/unixtcp-ipIP 版本4或64-c并发连接数1-s使用短连接每个连接最多约 4 KiB 数据关闭长连接默认最多约 8 GiB/连接-i迭代次数20-l单轮测试最长运行秒数超时后杀掉进程10-r反转角色客户端放进容器/VM关闭从该脚本还可以看到短/长连接的数据量界定逻辑[ $ARG_SHORT 1 ] MAX_LEN4096 || MAX_LEN8388608即短连接模式下每个连接最多传输 4 KiB 数据长连接模式最高可达 8 MiB8388608 字节从而可以构造海量短连接或少量大流量两类截然不同的压力形态。这正是 README 中发送随机数据后拆除连接这一行为的底层实现逻辑。五、Windows 端完整操作步骤原文档给出了在 Windows 宿主机Hyper-V上从零开始执行整套压测的完整流程以下步骤逐条继承并补充说明。5.1 构建服务端镜像在 Linux 构建机上执行linuxkit build tests/cases/test-virtsock-server.yml说明该命令会依据 YAML 构建出可引导的镜像产物其中包含test-virtsock容器镜像产物中包括可用于 Hyper-V 引导的ISO 文件test-virtsock-server.iso这是因为 LinuxKit 会为 Hyper-V 平台输出 EFI 引导的 ISO 镜像。注意README 原文的构建入口指向tests/cases/test-virtsock-server.yml当前仓库树中该文件未随本测试目录一并保留若仓库版本与此 README 存在差异请以仓库实际文件为准。test-virtsock镜像本身由 test/pkg/virtsock/build.yml 描述。5.2 复制 ISO 到 Windows将上一步产出的test-virtsock-server.iso拷贝到 Windows 系统上供 Hyper-V 虚拟机挂载。5.3 创建 Type 1 Hyper-V 虚拟机在 Windows 上创建一台Type 1第 1 代Hyper-V 虚拟机命名为virtsock并注意以下要点不需要磁盘No Disk不需要网络No network required将 ISO 挂载到CDROM 设备为COM1串口启用命名管道管道名称为virtsock。命名管道的作用LinuxKit 默认将内核与系统日志输出到串口通过命名管道可将这些调试输出重定向到宿主机便于观察 VM 内服务端的启动状态与运行日志。5.4 启动虚拟机在 Hyper-V 管理器中启动名为virtsock的虚拟机。VM 引导后容器内的sock_stress会以服务端模式-s -v 1自动开始监听 virtio/Hyper-V socket 端口。5.5 连接串口控制台获取调试输出用 PuTTY 连接命名管道观察 VM 内部调试输出putty -serial \\.\pipe\virtsock-serial表示使用串口模式\\.\pipe\virtsock是上一步为 COM1 创建的命名管道路径连接后即可看到 LinuxKit 启动日志以及 sock_stress 服务端的运行输出。5.6 在宿主机运行压力客户端打开 PowerShell先取得 VM 的 IDGUID再运行编译好的 Windows 端客户端virtsock_stress.exe$vmId (get-vm virtsock).Id .\virtsock_stress.exe -c $vmId -v 1 -c 1000000 -p 10参数解读结合原文档描述第一个-c $vmId指定连接目标即 Hyper-V 虚拟机virtsock的 VM GUIDHyper-V socket 以 VM GUID 作为寻址标识-v 1输出详细程度第二个-c 1000000创建 1,000,000一百万个连接-p 10使用 10 个并发线程/并发度。该命令的效果是由 10 个线程向 VM 发起总共 100 万次连接每次连接建立后随机传输一定量的数据随后拆除连接。原文档明确说明 There are more options to change the behaviour即客户端还有更多可调选项连接数、线程数、数据量、输出级别等。六、压测背后的原理与预期行为结合 test/pkg/virtsock/Dockerfile 与 test/pkg/ns/runc-net.sh 的实现可以梳理出整套测试的数据流VM 引导后tini拉起sock_stress -s -v 1进程进入监听状态server 模式短连接语义Windows 宿主机上的virtsock_stress.exe通过 Hyper-V socket 通道向 VM 的 socket 端口发起连接客户端在每条连接上写入随机长度的数据服务端读取并回显echo数据传输完毕后连接被拆除客户端继续创建下一条连接直至完成设定的连接总数。通过短连接 海量连接 随机数据量的组合可以重点暴露以下问题大量连接建立/拆除时vsock 通道的连接管理开销与稳定性随机数据量下缓冲区与流量控制是否正确高频并发下VM 内 sock_stress 服务端的吞吐与资源占用VM 内极简 inittini在大量短生命周期 socket 下的进程/资源回收是否正常。七、与 linuxkit run hyperv 的关联在 LinuxKit 主工具链中src/cmd/linuxkit/run_hyperv.go 提供了linuxkit run hyperv命令可直接在 Windows 上启动 Hyper-V 虚拟机。从该源码可以看到与 README 场景相互印证的设计默认创建Generation 2第 2 代虚拟机New-VM -Generation 2且-NoVHD表示不预置磁盘支持通过参数指定-SwitchName虚拟交换机与内存、CPU 等资源配置该命令期望输入的是EFI ISO 文件路径与 README 中将 ISO 挂载到 CDROM的操作一致。也就是说除了 README 中手动创建 VM的方式外linuxkit run hyperv也提供了一条自动化的替代路径当前仓库中该命令的实现面向 Generation 2 VM而 README 手把手流程使用 Type 1 VM两者引导方式不同读者可按需选择。八、后续扩展方向原文档 TODO原文档列出了该测试套件的四项后续工作目前仍可作为演进参考增加自动创建 Hyper-V 虚拟机的脚本当前 VM 创建依赖手工操作New-VM / Set-VM / Add-VMDvdDrive 等 PowerShell 命令在linuxkit run配合 HyperKit中启用 virtio socket 支持使 macOS 场景也能一键跑通 vsock 压测补充从 VM 连接宿主机的示例客户端 YAML当前方案是宿主机连 VM反向场景VM 内客户端连宿主机服务端的示例尚未提供接入 CI将 virtioHyperKit与 Hyper-V 两套环境的压测接入持续集成回归验证 vsock 通道的稳定性。九、相关仓库资源索引如需进一步研究可在本仓库中继续阅读测试套件本体test/pkg/virtsock/Dockerfile、test/pkg/virtsock/build.yml、test/pkg/virtsock/README.mdsock_stress 在另一类压测场景中的用法test/pkg/ns/runc-net.shHyper-V 虚拟机自动化启动实现src/cmd/linuxkit/run_hyperv.goHyper-V 平台整体使用文档docs/platform-hyperv.md小结LinuxKit 的 virtio/Hyper-V socket 压测方案是一条构建最小镜像 → VM 内跑服务端 → 宿主机跑客户端 → 海量并发连接的完整链路服务端镜像由 test/pkg/virtsock/Dockerfile 以可复现的多阶段构建产出客户端在 Windows 上通过 Hyper-V socket 直连 VM GUID最终以百万级连接、多线程、随机数据量的组合检验 vsock 通道在高压力下的正确性与稳定性。无论是手动创建 Type 1 VM 走命名管道调试还是借助linuxkit run hyperv自动化其核心思路一致用最小化的 LinuxKit 系统聚焦验证一条主机与虚拟机之间的高速通信通道。赞分享操作系统云原生容器运行时【免费下载链接】linuxkitA toolkit for building secure, portable and lean operating systems for containers项目地址https://gitcode.com/gh_mirrors/li/linuxkit点击查看免费下载相关推荐TDengine 压测工具 taosBenchmark 实战指南从源码构建到写入/查询/订阅压力测试TDengine 压测工具 taosBenchmark 实战指南从源码构建到写入/查询/订阅压力测试 taosBenchmark曾用名 taosdemo是数据库时序数据库物联网大数据实时分析云原生LinuxKit Hyper-V 后端实战在 Windows 上运行、配置与排查 linuxkit 虚拟机LinuxKit Hyper V 后端实战在 Windows 上运行、配置与排查 linuxkit 虚拟机 本文围绕 LinuxKit 的 Hyper V 运操作系统云原生容器运行时Consul 负载测试 AMI 构建实战使用 Packer 定制 Consul 与 k6 压测镜像Consul 负载测试 AMI 构建实战使用 Packer 定制 Consul 与 k6 压测镜像 本指南以 Consul 仓库中的 test/load/pa服务网格服务注册发现API网关健康检查微服务上一篇深入理解svmjs的SMO算法实现JavaScript机器学习的底层逻辑下一篇BELLE-开源生态系统相关工具库与扩展项目汇总创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表