Testkube：把测试都搬进 Kubernetes 一个平台

先给个落点：Testkube 是一个跑在 Kubernetes 集群里的开源测试编排平台，把散在 CI、本地、各台机器上的那堆测试，收拢成一份能统一定义、统一触发、统一看结果的 Test Workflow。

仓库是 kubeshop/testkube，MIT 加 Testkube Community License 双协议开源，目前 1.7k 星、180 fork，最新版停在 2.14.0。仓库里实际摆着这些：主控核心在 api/ 和 internal/，K8s 相关在 k8s/，pkg/ 是各类组件，test/ 放着示例测试，CLI 跑 install.sh 就能装。它在 README 里给自己的定位是：

The Open Testing Platform for AI-Driven Engineering Teams

下面只谈文档和源码里能核实的东西。

先把测试跑起来这件事横向摆开

“测试跑起来”各家思路不一样，先看一张表。

方案	定位	在哪跑	要不要 K8s	主要管什么	开源
Grafana k6	性能/压测工具	本机、CI	否	只想跑负载脚本	是
Testcontainers	容器化集成测试依赖	本机、CI	否	开发期起依赖环境	是
传统 CI（Jenkins/Actions）	通用流水线	云端/自建 runner	通常否	把测试当一个 job 调度	多数是
Testkube	K8s 原生测试编排	你的集群里	是	统一定义、触发、收结果	是

k6 只解决压测，Testcontainers 只管开发期的依赖，传统 CI 得自己搭测试环境、自己维护镜像。Testkube 走的是另一条路：让测试本身变成 K8s 里的资源，定义、触发、结果收集都归它管。

每条路都有自己的适用场景，没有谁天然更好；区别在”测试环境跟谁走”。

Testkube 实际在做什么

测试被定义成一种叫 Test Workflow 的资源

Testkube 的核心不叫”测试脚本”，叫 Test Workflow。它是一个 K8s 自定义资源（CRD），用一套专用的 workflow 语言声明：

• content：测试代码从哪来。可以是把某个 Git 仓库 checkout 下来，也可以直接把文件内容 inline 写进定义。
• container：测试在什么环境里跑。镜像、CPU/内存、工作目录、环境变量，都能定义，也能按步骤覆盖。
• steps：按顺序执行的一系列步骤，支持嵌套。每一步可以指定自己的镜像、命令和参数。

概括起来：一个 workflow 里既写了”测什么”，也写了”用什么工具版本在什么环境里跑”。工具的依赖不绑死在某个 runner 镜像上，而是跟着 workflow 定义走。

怎么用，三步

1. 用 Helm 或 install.sh 把 standalone agent 部署进目标集群，它跑起来会管好自己这款 CRD。
2. 写一份 TestWorkflow 的 YAML：选一个现有测试仓库，或者直接 inline 一点测试文件，再配好容器和 steps。
3. 用 testkube CLI（testkube run testworkflow <名字> 这类命令）跑一次，结果存进集群绑定的 PostgreSQL，产物进 S3 兼容存储。

跑起来之后，就能在 dashboard 里看到所有结果、日志、产物和资源指标归拢到一起。

触发方式多到挑花眼

一份 workflow 可以被九种机制触发：手动在 dashboard 点、从 CI/CD 流水线调、按固定 schedule 排、响应某个 K8s 事件、创建 Execution CRD、过 CLI、过 REST API、被另一个 workflow 调、响应 Git 事件。还有 MCP server，AI Agent 接上之后能直接帮你跑测试、看结果。

商业版控制平面再往上叠一层：一个平面接管无限个集群，Testkube AI 负责生成 workflow、故障调查、开修复 PR。

一个值得留意的设计

它把”每个测试用哪个工具版本、哪些依赖”做成了 workflow 定义的一部分，而不是固定在容器里。这意味着测试环境能跟着 Git 版本走、能通过 GitOps 变更、能在不同集群间复用，每次跑的都是声明里那个环境。对”测试环境漂移”这种老毛病，算是一种从根上规避的做法。

测试结果也不是丢一堆 stdout 了事，日志、artifact、指标全收进统一存储，出问题能在 dashboard 一个面上查个明白。

放到测试开发 + 业务侧能怎么落

站在测试工程师的角度，它把平时最乱的几件事统一了：接口、E2E、压测、基础设施验证，全部写成同一种 K8s 资源，能版本化、能 GitOps、能对着环境隔离。团队要审计或复盘某次发布，报告、日志、指标都在一个入口，不用去 GitLab、Jenkins、压测平台三个地方翻。

对业务侧，价值在于”测试环境跟谁走”变成了可声明的事：加一个环境，就是加一份带资源的 workflow；哪个集群要跑，target 指向哪。多环境、多团队的测试管理，从”人和脚本”挪到了”配置和资源”。

面向 AI 那侧更直接：MCP server 让 Agent 能创建、触发、分析测试。这意味着”让 AI 跑一遍回归并解释失败”这类事，从写脚本变成调接口。

适用边界

它要求先有一个正经的 K8s 集群，单机、没上容器编排的团队用起来是负担，不是帮助。纯压测、单点功能测试，用 k6 或 Testcontainers 反而更轻。它解决的是”测试多、环境多、要统一收口”的问题，小团队初期可能用不到这份能力。

仓库在 https://github.com/kubeshop/testkube 。

#Testkube #Kubernetes #测试平台 #测试自动化 #开源工具 #AI测试