小编jla*_*310的帖子

我们有一个包含多个模块的 NestJS 项目。突然，一些测试停止工作并出现错误，例如

\n

失败 libs/backend/nest/pipes/src/lib/iso-date-validation.pipe.spec.ts

\n

\xe2\x97\x8f 测试套件运行失败

\n

ENOENT: 没有这样的文件或目录，打开\nD:\\git\\my-nest-project\\libs\\backend\\nest\\pipes\\src\\lib\\iso-date-validation.pipe。规格'

\n

它知道要运行什么测试，但随后它声称找不到测试文件。有时我们会遇到几个这样的错误，有时甚至是几十个。

这些错误在我的机器本地、我们的 Jenkins 服务器以及其他开发环境中随机发生（并不总是在相同的测试中）。我可以在 Windows/Mac/Linux 上重现这个。

测试或项目配置文件没有发生任何会触发此更改的更改。事实上，我已经检查了在 Jenkins 中可靠构建的以前版本的代码库，现在它们具有相同的随机测试错误。

我已经在干净的 Nodejs 环境中进行了测试，除了 npm 之外，没有全局安装任何东西。

使用 jest --verbose 标志没有给我更多的细节。

NestJS 项目中的 jest 配置是多层的，因此很难在这里显示整个内容，但我不明白这怎么可能是一个配置问题，因为用于运行良好的测试并且配置文件没有更改。

我尝试过清除 jest 缓存，但结果不一致。在某些情况下，我可以在清除缓存后进行干净的测试运行。

通常，测试失败发生在具有一些 React .tsx 模板的模块中，但并非总是如此。有时纯 Typescript 模块会失败。

我们将现有的开发集群从 1.13.6-gke.13 升级到 1.14.6-gke.13，我们的 pod 无法再通过 Google Cloud VPN 访问我们的内部网络。我们的生产集群（仍在 1.13 上）共享相同的 VPC 网络和 VPN 隧道，并且仍然运行良好。唯一改变的是管理节点和节点池在开发集群上升级到 1.14。

我在开发集群上的一个 pod 中打开了一个 shell，并尝试 ping 一个我们需要访问的内部服务器的 IP 地址。没有收到回复。在我们的生产集群中的 pod 上做同样的事情会按预期工作。

我通过 ssh 连接到集群中的一个节点，并且能够 ping 内部网络。所以它只是有网络问题的豆荚。

对集群中公开暴露的服务的访问仍按预期工作。健康检查没问题。

更新：

我使用最新的 1.13 版本创建了一个新的节点池，从 1.14 池中排空了 pod，所有 pod 再次在 1.13 池上运行。1.14 肯定有问题。这是由某些新配置选项引起的问题还是只是一个错误，还有待观察。

解析度：

IP 伪装在这里讨论https://cloud.google.com/kubernetes-engine/docs/how-to/ip-masquerade-agent。我的解决方案是将我的每个集群的 pod 子网添加到 GCP 上我的 VPN 云路由器中的广告网络列表中。所以现在 pod 网络可以穿越 VPN。