广告

sidecar正在改变Kubernetes负载测试

  • 浏览(70)
  • 评论(0)
  • 译者:k8s

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

传统上,负载测试是通过独立客户端完成的,如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/

  • 分享到:
  • icon
  • icon
  • icon
  • icon
箭头