sidecar正在改变Kubernetes负载测试

随着基础设施不断扩展，你开始获得更多的流量，确保一切按预期运行非常重要。这通常通过测试来完成，负载测试是验证服务弹性的最佳方式。

传统上，负载测试是通过独立客户端完成的，如GoReplay和JMeter。然而，随着基础设施变得更加现代化，组织正在使用Kubernetes等工具，拥有现代化的工具集也很重要。

使用传统的负载测试，通常会遇到以下三个主要问题之一：

——编写负载测试脚本需要大量时间。

——负载测试通常在大型、复杂的端到端环境中运行，这些环境很难调配，而且对于生产规模的基础设施来说成本高昂。

——除非有生产数据，否则数据和实际用例不可能一一镜像。

更现代的方法是将负载测试工具直接集成到基础设施中。如果你正在使用Kubernetes，可以通过operator之类的东西来实现。这将带来以下好处：需要管理的基础设施更少，并且能够使用特定于基础设施的功能，如自动缩放pod。

然而，将工具直接集成到Kubernetes中的最大好处是可以使用sidecar。

专注于流量捕获

任何适当的负载测试设置都有两个主要组件：流量捕获和流量回放。几十年来，大多数负载测试工具都是这样工作的，现在仍然如此。有很多方法可以捕获流量。

下一节将深入探讨sidecar如何具体帮助解决这一问题。但首先，重要的是理解为什么传统负载测试会出现问题。

首先，你如何记录流量？最常见的方法是记录自己的流量。打开一个配置为捕获流量的浏览器，然后开始模拟用户如何使用你的服务。

虽然这在许多领域肯定是有帮助的，但这确实意味着你依赖于自己对应用程序使用方式的感知。对于一个简单的应用程序，这可能不是问题，但如果产品是Saas平台，那么应用程序可能有多种使用方式。

其次，你错过了重要的元数据。同样，对于一个简单的应用程序来说，这可能不是一个问题，但随着应用程序的扩展，这一点变得越来越重要。

如果你是创建流量的人，那么你将只获得特定环境生成的头，这意味着负载测试将只测试一个特定场景。更好的方法是捕获生产流量并将其用于回放，因为你将收到一系列不同的请求。

第三，你需要考虑你的依赖关系。如果正在对整个基础设施进行负载测试，这可能不会成为问题。但是，如果想对单个服务进行负载测试，即当测试是CI/CD管道的一部分时，需要确保所有传出请求都指向模拟服务。

使用传统的负载测试工具，你将无法实现这一点。要么必须设置一个新服务来充当模拟，要么必须更改应用程序的代码。

第四，你正在添加更多要管理的基础设施。在现代DevOps世界中，你不希望从开发人员的笔记本电脑上运行负载测试。它应该从基础设施运行的服务执行。因此，大多数工具必须添加需要管理的附加服务。

使用sidecar捕获流量

既然你已经知道了为什么传统的负载测试不适合现代基础设施，那么我们探讨sidecar将如何解决这些问题。

在Kubernetes中，添加sidecar并使其充当代理非常容易。你已经解决了如何捕获流量的问题。这个sidecar将捕获所有入站请求，并将其发送到另一个可以存储记录的请求的系统。

使用这种方法，很容易实现阴影，这是捕获生产流量并在开发环境中重放的做法。

因为是直接记录生产数据，所以你还可以确定从每个请求中获取所有元数据。不过，你可能已经看到了这方面的问题。身份验证、令牌或敏感信息如何？

sidecar不仅仅是捕捉流量，它还将负责回放。而且，因为sidecar本身就是一个应用程序，所以很容易在将任何元数据（如时间戳）发送到应用程序之前对其进行转换。

对于敏感数据，sidecar可以在将其发送到存储之前轻松地将其从元数据中过滤出来。

此时，你已经解决了管理额外基础设施的问题，因为sidecar可以通过简单的几行添加到清单文件中。你还解决了缺少元数据的问题，因为代理将捕获所有内容，除非特别配置为这样做。

然后仍然存在模拟依赖关系的问题。sidecar仍然充当代理，用于传入和传出请求。因此，你可以告诉sidecar正在执行负载测试，它将识别传出的请求。它不会转发请求，而是简单地用最初记录请求时获得的数据进行响应。

sidecar不是捕获流量的唯一方法

在这一点上，应该很清楚如何使用sidecars来改变进行负载测试的方式。然而，sidecar只是改善流量捕获的众多方法之一。

随着行业的变化，流量捕捉很可能会变得商品化，而最好的工具将是回放流量的最佳工具。

许多开发人员都使用Postman来测试API，并使用各种不同的请求定义创建了广泛的集合。虽然这确实有点违背了不手动创建流量的原则，但能够测试特定用例仍然有价值。

服务网格是管理服务（尤其是微服务）之间通信的一种流行方式。大多数服务网格将带来可观察性。通过它，你将获得生产流量的集合，然后可以将其导入到选择的负载测试工具中。

需要注意的是，一些公司正在努力从服务网格的实现中删除sidecar。然而，服务网格的未来是否没有sidecar还无法下定论。

eBPF越来越多地用于现代基础设施。本质上，eBPF允许你在内核级别执行应用程序，因此，它是捕获流量的一种非常有效的方法。

来自监控系统的高保真日志也是捕获流量的一种可能方式。然而，这里需要注意的是，它必须具有高保真度。为了节省成本和存储空间，通常会剥离请求日志中的一些头，这些头对故障排除没有帮助。如果你打算使用日志进行流量回放并获得最大收益，则需要保留所有信息。

API网关/入口控制器可能是捕获流量的好方法，因为网关和控制器记录通过的流量非常常见。如果流量捕获真正变得商品化，那么只需将流量导入负载测试工具即可。

流量回放是负载测试中的强大工具

sidecar将改变负载测试的方式，一些公司已经开始接受它。无论是因为你将使用它们来捕获流量、回放流量，还是模拟传出的请求，毫无疑问，你会看到sidecar的使用量增加。

原文链接：

https://thenewstack.io/sidecars-are-changing-the-kubernetes-load-testing-landscape/