k3s 性能测试框架解析基于 Terraform 与 clusterloader2 的 AWS 集群自动压测方案【免费下载链接】k3sLightweight Kubernetes项目地址: https://gitcode.com/GitHub_Trending/k3/k3s在 tests/perf 目录下k3s 项目维护了一套完整的性能测试基础设施它借助 Terraform 在 AWS 上自动化构建 k3s 集群支持普通模式与 HA 模式、多种存储后端再通过 Docker 化的 clusterloader2 工具对集群施加负载并收集指标。本文以 tests/perf/README.md 为主体结合该目录下的 Terraform 模板、脚本与测试配置源码讲解如何配置、构建、压测与销毁这套测试环境以及每个变量、命令背后的实现细节。整体架构三段式测试流水线整套脚本划分为三个相互独立的 Terraform / 测试模块目录结构如下tests/perf/ ├── Makefile # 统一入口init / config / plan / apply / destroy / clean / test ├── scripts/ │ ├── config # 全部可调变量的单一配置源 │ ├── perf # Terraform 生命周期封装init/apply/destroy/clean │ └── test # clusterloader2 压测执行入口test_load / test_density ├── server/ # 存储后端 N 个 k3s primary Prometheus agent ├── agents/ # N 个 k3s agentASG 自动伸缩组 └── tests/ # 压测用例load / density与报告输出目录三个部分的职责分别为模块职责server部署存储后端RDS MySQL / RDS Postgres / 自建 etcd / 内置 etcd再部署 N 个 k3s primary 节点同时创建 1 个或多个专门用于 Prometheus 部署的 agent 节点由 clusterloader2 负责在其上部署 Prometheus 与 Grafanaagents部署 k3s agent 节点池可独立控制节点数量与实例规格tests使用 clusterloader2 的 fork 版本执行压测保存报告到tests/test_name-random-number值得注意的是tests使用 clusterloader2 的 fork 版本源自 kubernetes/perf-tests 仓库该 fork 只做了两处修改调整日志输出、移除 etcd 指标探针。当前可用测试有两类load test负载测试与density test密度测试。变量体系一份 config 驱动整个集群所有可调参数都集中在 tests/perf/scripts/config 中脚本会通过source scripts/config读取它并在 scripts/perf 的config()函数中将其转换为 server 与 agents 两个模块的variables.tfvars文件。默认配置如下## MAIN VARIABLES ## CLUSTER_NAMEloadtest-k3s CLUSTER_SECRET DOMAIN_NAMEloadtest.eng.rancher.space ZONE_ID K3S_VERSIONv1.0.0 EXTRA_SSH_KEYS # comma separated public keys PRIVATE_KEY_PATH~/.ssh/id_rsa DEBUG1 ## K3S DB VARIABLES ## DB_ENGINEembedded-etcd DB_INSTANCE_TYPEdb.m4.4xlarge DB_NAMEk3s DB_USERNAMEk3suser DB_PASSWORD DB_VERSION5.7 ## K3S SERVER VARIABLES ## SERVER_HA1 SERVER_COUNT3 SERVER_INSTANCE_TYPEm5.2xlarge ## PROMETHEUS SERVER VARIABLES ## PROM_WORKER_NODE_COUNT1 PROM_WORKER_INSTANCE_TYPEm5.large ## K3S AGENTS VARIABLES ## AGENT_NODE_COUNT10 AGENT_INSTANCE_TYPEm5.large主变量Main Vars变量名说明默认值来自 configCLUSTER_NAMEAWS 上的集群名会作为集群内各组件名的前缀loadtest-k3sDOMAIN_NAMEk3s primary 所在负载均衡器的 DNS 名loadtest.eng.rancher.spaceZONE_ID用于修改 DNS 记录的 AWS Route53 zone id空K3S_VERSION集群使用的 k3s 版本v1.0.0EXTRA_SSH_KEYS注入到服务器上的公钥列表逗号分隔空PRIVATE_KEY_PATHclusterloader2 通过 SSH 采集指标使用的私钥路径~/.ssh/id_rsaDEBUGk3s server 是否开启 debug 模式1从 scripts/perf 的config()函数可以看到两个自动化的细节若DB_PASSWORD为空脚本会用/dev/urandom生成 32 位随机密码若CLUSTER_SECRET为空同样生成随机集群注册密钥。此外PRIVATE_KEY_PATH会先经readlink -f展开为绝对路径再写入 tfvars。数据库变量Database Variables变量名说明默认值DB_ENGINE数据库类型mysql、postgres、etcd、embedded-etcdembedded-etcdDB_INSTANCE_TYPEMySQL/Postgres 使用的 RDS 实例类型etcd 也使用 db.* 类并在脚本内部解析db.m4.4xlargeDB_NAME数据库名仅 Postgres 和 MySQL 创建k3sDB_USERNAME数据库用户名仅 Postgres 和 MySQLk3suserDB_PASSWORD数据库用户密码仅 Postgres 和 MySQL为空则自动生成空DB_VERSION数据库版本5.7存储后端的切换逻辑在 server/files/server_userdata.tmpl 中实现根据db_engine组装不同的STORAGE_ENDPOINT——Postgres 使用postgres://user:passhost:5432/dbMySQL 使用mysql://user:pass(host)/db外部 etcd 则把多个 etcd 实例的私网 IP 拼接成逗号分隔的http://ip:2379列表。k3s Server 变量变量名说明默认值SERVER_HA是否启用 HA 模式为 0 时使用 sqlite 作为存储后端1SERVER_COUNTk3s primary 节点数量3SERVER_INSTANCE_TYPEk3s server 的 EC2 实例类型m5.2xlargek3s Agent 变量变量名说明默认值AGENT_NODE_COUNT创建的 k3s agent 数量10AGENT_INSTANCE_TYPEk3s agent 的 EC2 实例类型m5.largePrometheus 专用节点变量变量名说明默认值PROM_WORKER_NODE_COUNT专用于 Prometheus 部署的 k3s agent 数量1PROM_WORKER_INSTANCE_TYPE上述 Prometheus agent 的实例类型m5.largeserver 模块存储后端与 primary 节点的 Terraform 实现server/main.tf 是整套环境的核心它依次创建安全组aws_security_group.k3s开放 22SSH与 6443k3s API Server端口同时允许组内全互通与全量出站。RDS 实例aws_db_instance.k3s_db仅当db_engine为postgres或mysql时创建count条件控制默认 100GB gp2 存储、跳过最终快照。etcd 集群aws_instance.k3s_etcd仅当db_engine etcd且启用 HA 时创建count etcd_count * (db_engine etcd ? server_ha : 0)实例类型由replace(db_instance_type, /db./, )从db.m4.4xlarge推导为m4.4xlarge。网络负载均衡器 NLB通过aws_route53_record将domain_nameCNAMETTL 30s指向 NLB 的 DNS 名。代码注释解释了原因NLB 的真实 DNS 名过长会引发问题因此必须借助自定义域名target group 对 6443 端口做 TCP 健康检查。k3s server 实例池aws_instance.k3s-server数量为server_count通过user_data即 server_userdata.tmpl完成 k3s 安装与调优并使用local-execprovisioner 在 apply 后拉取 kubeconfig 写入tests/kubeconfig.yaml。Prometheus worker 自动伸缩组基于terraform-aws-modules/autoscaling/aws模块节点通过--node-label promtrue打标见 worker_userdata.tmpl 中的k3s_exec参数供 clusterloader2 定向调度 Prometheus/Grafana。server 节点初始化脚本剖析server/files/server_userdata.tmpl 是一段 cloud-config其中run_k3s.sh的核心逻辑展示了不同拓扑的安装差异HA 模式外部 DB通过curl -sfL https://get.k3s.io | sh -安装追加--datastore-endpoint$STORAGE_ENDPOINT多个 primary 共享同一存储后端。嵌入式 etcdembedded-etcd第一个节点使用--cluster-init初始化其余节点通过--server https://${lb_address}:6443加入。单节点 sqliteSERVER_HA0时既不加--datastore-endpoint也不加--cluster-init退回默认 sqlite 后端。该模板还统一注入了--cluster-cidr10.0.0.0/8 --disable traefik --disable servicelb --tls-san ${lb_address}并做了大量高密度压测所需的系统调优sysctlARP 邻居缓存net.ipv4.neigh.default.gc_thresh*、fs.file-max/fs.nr_open、TCP 内存与缓冲区参数、journald 限速关闭RateLimitIntervalSec0等。DEBUG1时还会把 systemd 服务改为k3s --debug后重启。agents 模块工作节点池agents/main.tf 与 server 模块类似通过 autoscaling 模块创建agent_node_count个 agent 节点关键参数wait_for_capacity_timeout 60m等待 ASG 扩容到目标容量超时上限 60 分钟确保 10 节点规模的节点池完全就绪节点通过 pool_worker_userdata.tmpl 注册到 k3s 集群注册地址来自 server 模块输出的public_ip使用同一个k3s_cluster_secret完成认证与 Prometheus 节点池一样配置了 spot 竞价实例与 30GB gp2 根盘。tests 模块clusterloader2 压测测试执行入口scripts/test 脚本以 Docker 方式运行 clusterloader2镜像husseingalal/clusterloader:dev通过-v $PWD/:/opt/k3s/perf-tests将本地tests/目录挂载进容器核心参数--testconfig指定测试配置文件load/config.yaml或density/config.yaml--kubeconfig使用 server 模块生成的tests/kubeconfig.yaml--masterip来自terraform output -stateserver/server.tfstate解析出的 server IP--report-dir报告输出到tests/load_tests_results-$RANDOM或density_tests_results-$RANDOM每次运行目录名带随机数避免覆盖--enable-prometheus-server --tear-down-prometheus-server0启用 Prometheus 采集测试结束后保留监控栈供进一步分析。load 测试负载压测tests/load/config.yaml 是标准的 clusterloader2 负载场景主要可调常量DefaultParam支持通过命令行覆盖常量默认值含义NODES_PER_NAMESPACE10每个 namespace 覆盖的节点数PODS_PER_NODE30每节点 Pod 数直接决定总 Pod 量LOAD_TEST_THROUGHPUT10负载注入吞吐pods/s用于推导饱和时间BIG/MEDIUM/SMALL_GROUP_SIZE300/150/50大/中/小 Deployment 的副本规模ENABLE_CHAOSMONKEYfalse是否注入节点故障1% 失败率、1m 间隔测试流程分阶段执行启动各类测量API 响应性、Pod 启动延迟、集群内网络延迟、DNS 查询延迟、网络编程延迟→ 创建 SVC → 按大/中/小分组创建 Deployment → 等待 Pod 全部 Running → 在RandomizedScalingTimeLimited调控下将副本数随机缩放至[0.5x, 1.5x]→ 等待扩容完成 → 按序删除对象 → 汇总收集全部测量结果。测试假定集群规模 100 节点。density 测试密度压测tests/density/config.yaml 聚焦单节点能承受多少 Pod以及调度延迟关键差异点PODS_PER_NODE默认 30DENSITY_TEST_THROUGHPUT默认 20 pods/sNODES_PER_NAMESPACE默认 100saturation饱和阶段以 5 qps 的均匀速率Uniform5qps持续创建海量轻量 Pod每 Pod 仅请求 1m CPU / 10M 内存测量调度吞吐SchedulingThroughput与 Pod 启动延迟并设置软超时与至少 20 分钟1200s的硬超时以容忍节点故障latency延迟阶段在饱和之上再叠加少量延迟探针Pod每 Pod 100m CPU / 350M 内存专门测最坏情况下的 Pod 启动延迟随后删除并再次收集数据。使用指南build / test / destroy一键构建集群build修改 scripts/config 中的变量后执行cd tests/perf make applyMakefile 中的apply目标实际调用 scripts/perf 的apply()函数其流程为对server与agents两个目录分别执行terraform init执行config()生成两份variables.tfvars先 applyserver模块等待 60 秒脚本注释等待 server 初始化完成再 applyagents模块。构建完成后会生成tests/kubeconfig.yaml供后续测试使用。也可以单独执行make init、make config、make plan、make info分步操作。执行压测test修改 tests/load/config.yaml或密度测试配置后运行cd tests/perf make testmake test默认执行test_load若要跑密度测试可手动调用scripts/test test_density。报告将保存在tests/load_tests_results-随机数或tests/density_tests_results-随机数目录下。销毁与清理destroy / cleanmake destroy make cleandestroy会按agents → server的顺序执行terraform destroy --var-file variables.tfvars --force并删除本地 plan/tfvars/state 文件clean额外清理tests/下的 kubeconfig 与历史压测报告目录scripts/perf中的cleanall()函数。此外 Makefile 还提供make info用于读取两个模块的terraform output。小结这套位于 tests/perf 的性能测试框架把基础设施供给Terraform AWS— 集群初始化cloud-config 与 k3s 安装脚本— 负载注入与指标采集clusterloader2三段自动化地串成一条流水线。无论你想验证 k3s 在 MySQL/Postgres/etcd/sqlite 各存储后端下的 HA 表现还是想复现 10 节点、每节点 30 Pod 的负载与密度压测场景都可以通过修改 scripts/config 与对应config.yaml快速搭建一套可重复、可销毁的压测环境。【免费下载链接】k3sLightweight Kubernetes项目地址: https://gitcode.com/GitHub_Trending/k3/k3s创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考