Podman

在容器中调用华为云 OBS 时，请求在 DNS 解析成功后长时间没有响应，最终超时。相同 endpoint 从 Pod 的 host network 访问可以正常返回 403，因此问题集中在容器网络路径，而不是 OBS 服务本身。 先看服务端日志 失败容器的 runtime 日志有一条很重要的时间线： Endpoint=https://obs.cn-north-4.myhuaweicloud.com:443/ internet host address: phoenix-autotest.obs.cn-north-4.myhuaweicloud.com/123.60.240.82, phoenix-autotest.obs.cn-north-4.myhuaweicloud.com/123.60.240.83 这说明 DNS 解析已经完成。之后没有 HTTP 状态码，也没有 OBS 的业务异常。因此，失败点位于 DNS 之后、HTTP 响应之前，更接近 TCP/TLS，而不是 bucket、路径或签名参数。 产品的华为云插件确实直接使用 OBS SDK： this.obsClient = new ObsClient( settings.accessKeyId(), settings.secretAccessKey(), settings.endpoint()); 目录操作会调用 listObjects。在本机使用相同的 OBS 配置和 SDK 3.25.10 重放，接口可以正常返回。因此没有证据表明 AK/SK 或配置错误。 对照不同网络路径 运行服务的 Pod 使用 DinD sidecar： DOCKER_HOST: unix:///var/run/docker/docker.sock Phoenix 容器位于 DinD 的 bridge 网络中。在同一个 Pod 中做只读 HTTPS 探测，结果非常明确： ...

我们的端到端测试是一个由 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。 ...