Testcontainers

自动化测试使用 Playwright、Testcontainers 和 Docker-in-Docker。测试运行一段时间后，talos2 会从 Kubernetes 中消失，iDRAC 报告 System CPU Resetting，对应的测试分片失败。 这次调查最终拿到了完整的内核 panic 栈。直接原因不是硬件 reset，也不是 pid_max 耗尽，而是 Linux 6.18 中 PAGE_TABLE_CHECK 对 time namespace 的 VVAR 页面错误记账，触发了 BUG_ON()。 最初看到的现象 高并发 testcontainers 场景下，监控 Pod 观察到： loadavg=90+ pids=6890 threads=12513 dstate_count=6 eBPF 还记录到一分钟内大量进程和网络命名空间操作： fork_parent[runc]: 1597 fork_parent[containerd-shim]: 1209 fork_parent[dockerd]: 779 netns operations: 1303 unshare: 38 同时出现两类 D-state 栈。一类在网络命名空间清理路径： rcu_barrier netdev_run_todo default_device_exit_batch ops_undo_list cleanup_net process_scheduled_works worker_thread 另一类在容器文件清理路径： folio_wait_bit_common folio_wait_writeback truncate_inode_partial_folio truncate_inode_pages_range xfs_fs_evict_inode evict do_unlinkat __x64_sys_unlinkat 这些现象很容易让人得出一个合理但不完整的结论：高并发容器创建、删除导致 netns、workqueue、XFS 和 NVMe 同时拥塞，最后触发 hard lockup。 ...

我们的端到端测试是一个由 Playwright、Testcontainers 和容器运行时组成的多层工作流。 测试工作流 每个 Playwright worker 通过 Testcontainers 管理一组相互隔离的容器和 bridge network。启动前会清理残留资源，测试期间按需启动浏览器、应用和数据库，结束后再停止并删除容器和网络。 清理残留资源 -> 创建 network 和容器 -> 执行浏览器测试 -> stop/remove 容器 -> remove network 这些操作都由 Testcontainers 通过连接 podman Docker 兼容 API 完成， worker 的 teardown 会让 stop、remove、network remove 与容器状态查询交错执行，这正是本次调查关注的并发场景。 实验条件 为了避免大型业务镜像的启动成本和业务行为干扰测试，只使用了一个小镜像： 工作负载：busybox:1.36.1 Podman：quay.io/podman/stable:v5.8.2-immutable Docker：docker:dind，Docker Engine 29.7.2 每轮 24 个并发操作，共 5 轮 两个运行时均运行在 privileged 容器内，状态目录使用 4 GiB tmpfs 每个并发操作创建 bridge network，创建并启动一个 busybox 容器，然后执行 stop、remove 和 network remove。teardown 阶段同时发起 24 个 GET /containers/json?all=1 请求，并持续采样 containers-list、/info 和 /_ping。 ...