为什么大型工程团队要在 Kubernetes 上进行测试？

Kubernetes| 2023-05-16

将来，开发人员应该如何处理生产应用程序呢？是应该将本地的生产环境复制到云，还是应该直接在云环境中编写和运行所有代码，或者采用介于二者之间的某种方式？

原文链接：https://www.signadot.com/blog/large-engineering-teams-testing-on-k8s/

未经允许，禁止转载！

作者 | Nica Mellifera 译者 | 弯月

责编 | 王子彧

出品 | CSDN（ID：CSDNnews）

简介

在过去的几年里，我们看到很多开发团队从纯粹的本地开发转向基于云的开发环境。目标是提高开发速度，并控制无法完美复制环境的问题。

在本文中，我们来看看一些企业团队的解决方案。

在谈论开发人员在哪里编写新代码时，我们经常提及他们“测试”代码。这里的“测试”指的是自动化单元测试或端到端测试之前的一个阶段，开发人员需要在这个阶段研究如何让代码与其他资源交互。在测试驱动开发中，这两个阶段可能没有明显的区分。在本文中，为了简洁起见，我们将统一使用“测试”，尽管这个词本身还包括单独的一个部署后期阶段。

利用微服务提升开发速度

在尝试与四个不同的企业工程团队交流后，我发现他们的故事有很多相似之处，所以在此我将他们合并成一个故事。值得注意的是，不仅他们的最终结论非常相似，而且每个团队在确定基于云的开发环境之前都尝试了类似的解决方案。

我研究的案例有 Lyft、Reddit、Doordash、Eventbrite 和 Prezi。虽然并非所有团队最终都选择使用共享的 Kubernetes 集群，但他们都试图用类似的方法解决类似的问题，而且都面临着共同的困难。

成本与收益

在考虑改变开发人员的环境时，我们要考虑的一个关键问题是：在开发陷入停滞之前，如何确定投入精力对开发工作流程进行重大改革是否值得？

为此，Eventbrite 团队在一篇文章中讨论了这个决策，标题是：“为什么我们的开发环境运行了一个700个节点的K8s集群？”首当其冲必须考虑的不利因素是：通过共享集群来测试代码时，工具和集群的开发时间以及维护成本都会增加。

关于在共享 K8s 集群上进行测试，Eventbrite 提到了如下好处：

你是否曾听开发人员说：“在我本地运行测试时完全没问题”。在云中运行测试可以提高一致性。事实证明，在探究测试失败的原因或解决难以重现的问题时，共享开发人员环境能给予极大的帮助。

这是在共享集群上进行测试的核心优势：更早地发现未知的未知数，并永久消除可怕的一个常见问题：“在我机器上没问题。”

第一阶段：每位开发者都是一座孤岛

为了方便开发人员搭建环境，Prezi 等团队提供了服务安装、测试以及运行等方面的hook脚本。他们的工具还可以管理服务间通信。但是，由于每位开发者机器的独特性，hook脚本经常会因为依赖冲突而运行失败。工程师们花了很多时间来解决这些问题，但在几个月后重新访问服务时还是会遇到新的问题。

这种不一致的问题是大型开发团队没有同步所有依赖项的必然结果。通常这种不一致在经过长时间的调试后才会显现出来。

第二阶段：Docker Compose

当谈论使用容器化工具共享开发环境时，大多数人都会想到Docker。通过容器化所有依赖项并使用 Docker Compose 进行编排，就可以强制开发人员每天同步依赖项。与第一阶段相比，这种方法的巨大优势在于，无需等到失败才意识到你的环境需要更新。

最大的缺点是，很快你就会发现自己的 macbook 烫手。

每天下载新的容器并重新构建，只为了尝试一些开发上的小改动，这会极大地影响开发人员的速度。

Docker Compose 的问题在于，它的成本通常是隐藏的，你的笔记本电脑由于运行复杂的工作负载而停滞，因此而造成的时间浪费都无法明确地记入损失。也许每个小时它都会时窃取 10 分钟。但这不会成为阻止我们在一个月内发布新功能的障碍，结果导致你必须承担所有压力，在截止日期之前完成工作。

为了解决本地机器资源有限的问题，我们可以在云中提供虚拟机，并在其中运行 docker compose。然而，当服务和相关数据库等的数量超过 15~20 时，这类系统将变得难以管理。

对于 Reddit 团队，此问题已被确定为已知限制。他们开发了一个自定义工具来最大程度地减少重建和重新下载，以尽量减少每天的启动时间，并迁移到 kubernetes 集群以共享开发人员进行试验时所需的大部分资源。他们为此开发了一个名为Tilt的工具进行管理。如果你的团队有足够的资源，不仅可以改变开发环境流程，还可以维护内部工具，那就可以考虑采用这种方式大幅缩短每天早上的构建时间。