我一直在深入研究人们在 Kubernetes 上下文中运行集成和端到端测试的方式，并且对缺乏文档和反馈感到非常失望。我知道有一些很棒的工具，例如 kind 或 minikube，可以在本地运行资源。但在 CI 的上下文中，并且有一堆服务，它似乎不是一个很好的选择，出于明显的资源原因。我认为运行测试有很大的机会:
- 验证 list 或 helm 图表
- 验证组件作为更大整体的一部分的良好行为
- 验证产品的全局行为
这里的重点不是关于测试框架，而是更多关于可以在其上运行测试的环境。
你同意我的想法吗？您是否经历过运行此类测试？您对此有任何反馈或见解吗？
非常感谢
最佳答案
有趣的问题和我在过去几个月里为我现在的雇主所做的事情。本质上，我们将产品作为带有 list 的 docker 镜像发布。在编写端到端测试时，我希望在尽可能接近客户环境的情况下运行产品。
从本质上讲，为了解决这个问题，我们构建了与我们的标准云提供商 (GCloud) 交互的脚本，以创建集群、部署产品，然后对其运行测试。
对于主要的云提供商来说，这不是一项艰巨的任务，但可能很耗时。在开发测试时，我们通过艰难的方式学到了一些需要牢记的事情。
- 并发性，这听起来很明显，但请务必考虑您的 CI 可以运行的并发构建数量。
- 来自云的延迟，不要假设您会立即响应您在云中运行的每个命令。还要考虑超时。如果您提出具有大量 pod 和服务的产品，可接受的启动时间是多少？
- 导致构建失败的错误，这是一个有趣的问题。在与我们的测试部署通信时，由于网络错误，我们在构建中看到了错误。这些几乎总是可传递的。最好避免这些导致构建失败。
要注意的一件事是 GitLab 提供了一些 documentation关于如何在他们的 CI 管道中构建和测试图像。
关于testing - 在 Kubernetes 堆栈上运行集成/e2e 测试，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/58536038/