如何用Grafana k6和Flagger进行部署时间测试（附代码）

当谈到构建和部署应用程序时，最近越来越流行的一种方法是在Kubernetes中使用微服务。它提供了一种跨组织边界协作的简单方法，也是一种很好的扩展方式。

然而，它也带来了许多操作上的挑战。一个大问题是，在让生产流量到达微服务之前，很难在现实生活场景中测试它们。

但是有一些方法可以解决这个问题。在这篇文章中，我将看一下我们在Grafana实验室使用的工具，以测试我们的各种服务在部署时的整合情况，为每一个变化集。Grafana k6用于测试我们的服务，Flagger用于处理与Kubernetes的交互。

拼图的各个部分

Grafana k6主要是一个性能测试工具--查看这篇文章以了解我们如何使用它来达到这个目的--而且它的功能很全面。你不仅可以编写以性能为重点的负载测试，而且还可以编写结构化的测试案例、烟雾测试或任何类型的工作流程，这些工作流程都会碰到服务的HTTP API。响应可以针对各种断言进行验证，响应的属性可以用来制作进一步的请求。k6的一个伟大之处在于它是基于Javascript的，这允许更多的灵活性。

这里有一个简单的例子，调用一个API并检查请求持续时间：

import http from 'k6/http';
import { sleep } from 'k6';
 
export const options = {
   duration: '1m',
   vus: 1,
   thresholds: {
       http_req_duration: ['p(95)<500'],
   },
};
 
export default function () {
   const res = http.get('https://test.k6.io');
   sleep(1);
}

来自Weaveworks的Flagger被用来分析Kubernetes部署。它可以实现金丝雀或蓝/绿发布、A/B测试和流量镜像（阴影）。它支持查询各种指标来源，以确定在流量从以前的版本转移之前、期间和之后金丝雀的健康状况。

就其本身而言，Flagger依赖于外部流量和服务所暴露的指标来确定新部署的健康状况。为了模拟外部流量，还提供了一个负载测试器，在将金丝雀完全暴露给用户之前产生流量。

Flagger是通过Canary Kubernetes资源配置的。下面是一个简单的例子，说明配置的Canary资源是什么样子的：

kind: Canary
metadata:
name: my-app
namespace: my-app
spec:
analysis:
   interval: 1m # How long between iterations
   iterations: 1 # How many iterations (increase traffic + analysis)
   threshold: 2 # How many failed analyses before canary fails
   metrics: ... # list of metrics to check at each iteration (not covered in this article)
service: # description of the service to be created by Flagger
   name: my-app
   port: 80
   targetPort: 80
targetRef: # reference to the workload managed by Flagger
   apiVersion: apps/v1
   kind: Deployment
   name: my-app

在这个Canary资源被创建后，my-app 部署的配置被复制到my-app-primary 部署，my-app 部署被缩减。在新的版本中，my-app 被放大，测试，然后推广到-primary 。

结合Grafana k6和Flagger的力量

在Grafana实验室，我们的目标是确保每个部署到生产中的正确性。我们还想跟踪部署的各种属性，比如版本的平均请求时间。

无论是Grafana k6还是Flagger都不能独立完成这些工作。K6不提供对部署的任何控制。它必须被指向一个现有的服务，而这个服务是可以从运行器中到达的。Flagger并没有提供一个适合所有HTTP服务的测试方案。它自己的负载测试器不能根据响应来拒绝一个金丝雀--它是一个fire-and-forget客户端。这意味着所有被测试的服务都必须有合适的指标工具，复杂的测试案例也无法实现。

但是，当这两个伟大的工具结合在一起时，它们提供了完整的解决方案。

完成Flagger和k6的集成所缺少的是一个简单的Flagger webhook处理器，它代表Flagger调用k6。当与Flagger一起部署时，"flagger-k6-webhook "提供了一个预滚出检查（在流量被发送到canary之前），它可以运行任何k6脚本，通过Slack通知用户，并根据k6脚本中定义的阈值进行失败或成功检查。

每个金丝雀可以使用Flagger webhook进行单独配置。配置通过一个完整的k6脚本，这意味着任何用于此目的的脚本也可以在本地运行，用于开发目的或在其他进程中使用。

下面是一个结合前面两个例子（来自k6和Flagger）的例子：

apiVersion: flagger.app/v1beta1
kind: Canary
metadata:
name: my-app
namespace: my-app
spec:
analysis:
   interval: 1m
   iterations: 1
   threshold: 2 
   metrics: ...
   webhooks:
     - name: k6-load-test
       timeout: 5m
       type: pre-rollout
       url: http://k6-loadtester.flagger/launch-test
       metadata:
         slack_channels: flagger-test
         script: |
           import http from 'k6/http';
           import { sleep } from 'k6';
 
           export const options = {
               duration: '1m',
               vus: 1,
               thresholds: {
                   http_req_duration: ['p(95)<500'],
               },
           };
 
           export default function () {
               const res = http.get('https://test.k6.io');
               sleep(1);
           }
service: ...
targetRef: ...

目前，测试运行产生的日志和结果最容易通过Slack访问。Flagger和 "flagger-k6-webhook "都原生支持Slack，所以当我们为两者启用Slack集成时，信息会按照你所期望的顺序出现。

随着所有部件的到位，手动测试过程现在可以被代码化和自动化。这也是记录关键的API端点，它们的预期行为，以及如何测试它们的好方法。这对于学习服务的新开发者和提出修改建议的老开发者来说，都是非常宝贵的信息。

在Grafana k6云中观察结果

这种整合可以通过使用Grafana k6 Cloud来提升水平，在那里你可以发送所有版本的测试结果。需要注意的是，测试仍然会在负载测试器过程中运行，而不是用k6 Cloud的运行器。(关于如何设置的更多信息，请参见webhook的文档)。

下面是我们的一个服务的截图，你可以看到许多部署的结果在一段时间内的概况：

要查看每个不同请求结果的详细视图，你所要做的就是点击每个运行。

下一步是什么

Flagger-k6-webhook "的集成已经处于一个非常有能力的状态，但我们会根据需求继续修复和改进它。然而，大部分繁重的工作是由Grafana k6和Flagger完成的--它们都是非常活跃的项目--而不是集成本身。

在Grafana实验室，我们已经有了非常成功的试点项目来扩大这项服务的内部使用，我们的团队也发现了很多潜在的用例。例如，我们将探索如何在服务部署后测试其与Slack或电子邮件的整合。希望这将导致集成的新功能和可用性改进，社区也能从中受益。