在典型的Kubernetes部署中，所有到Kubernetes服务的流量都流经ingress代理——从Internet到后端服务的流量。这样，ingress就在您提高性能的关键路径上。有多种基准测试和衡量性能的方法。

衡量ingress代理性能的最常见方法可能是原始吞吐量。在这种类型的测试中，通过代理发送越来越多的流量，并且测量代理可以处理的最大流量。典型的测量方法是以每秒请求（RPS）为单位来测量性能。

但是，实际上，大多数组织不太可能推动任何现代代理的吞吐量限制。此外，吞吐量呈线性增长——当代理服务器的吞吐量最大化时，可以部署第二个实例以有效地使吞吐量增加一倍。

本文探讨了另一种类型的性能：延迟。通过代理的每个请求都会在代理解析请求并将请求路由到适当的目的地时引入少量延迟。与吞吐量不同，仅通过扩展代理服务器的数量是无法改善延迟。而且，至关重要的是，延迟会对您的关键业务指标产生重大影响。

Kubernetes的Edge Proxies

可以说，当今最流行的三个L7代理是Envoy Proxy，HAProxy和NGINX。在Kubernetes中，这些代理通常是通过控制平面配置的，而不是直接部署的。在本文中，在Kubernetes上测试了三种流行的开源控制平面/代理组合：

• ingress-nginx是Kubernetes最常见的入口，建立在NGINX之上。我们使用nginx-ingress-controller:0.25.0，它基于OpenResty 1.15.8，而后者又基于NGINX 1.15.8。

• HAProxy ingress controller（https://github.com/jcmoraisjr/haproxy-ingress）版本0.7.3基于1.8.21。我们尝试使用官方的HAProxy入口控制器。但是，在测试时，官方控制器仅公开了8种配置选项，因此无法用于基准测试。最近，它已扩展为25个配置选项。

• 基于Envoy Proxy构建的Ambassador Edge Stack。

Kubernetes上的基准延迟

容器化环境具有弹性和短暂性的特点。随着利用率的变化，将随时创建和销毁容器。部署了新版本的容器化微服务，从而导致新路由被注册。开发人员可能希望根据实际指标数据来调整超时，速率限制和其他配置参数。

在我们的基准测试中，我们通过边缘代理通过TLS向运行在三个Pod上的后端服务（https://github.com/hashicorp/http-echo）发送稳定的HTTP / 1.1请求流。边缘代理配置为执行TLS终止。然后，我们将后端服务扩展到四个Pod，然后每三十秒将其缩减到三个Pod，并在此过程中采样延迟。我们循环浏览此模式三次。然后，我们通过以三十秒的间隔进行三处附加更改来模拟某些路由配置更改：

• CORS标头

• 添加自定义响应头

• 重写请求路径

然后，我们恢复为基本配置。我们测量10％的请求的延迟，并在图表上分别绘制每个延迟。

测试设置

所有测试均在n1-standard-1节点上的Google Kubernetes Engine中运行。使用了三个节点池：一个用于入口，一个用于后端服务，一个用于负载生成器。每个节点池由三个单独的节点组成。每个入口都在入口节点池中分配了自己的节点，并且所有入口都配置为绕过，直接路由到服务端点kube-proxy。Vegeta用于生成负载。使用大使边缘堆栈，我们将端点路由配置为kube-proxy。

通常，所有入口都使用默认配置，但有两个例外：

• 使用NGINX，我们keep-alive-requests从默认的100增加到2147483647，以实现连接重用

• 使用Ambassador Edge Stack, endpoint routing 绕过kube-proxy。（请注意，我们不需要为NGINX和HAProxy更改此设置，因为它们默认情况下使用端点路由。）

由多名工程师进行了多次测试，以确保测试的一致性。

结果：100 RPS

NGINX的性能比HAProxy稍好，延迟峰值约为750ms（首次扩展操作除外）。这些等待时间尖峰的持续时间约为900毫秒。

借助Ambassador Edge Stack 和 Envoy Proxy，我们看到了明显更好的性能。注意此处图中的其他Y轴。除了25ms的启动延迟峰值外，没有其他明显的延迟峰值模式。大多数延迟低于5毫秒。

要在上下文中查看所有这些数字，我们将所有延迟数字覆盖在一个具有通用比例的图形上：

结果：500 RPS

在500 RPS时，我们开始看到HAProxy的较大延迟峰值，持续时间和延迟均增加。延迟峰值可能长达10秒，而这些延迟峰值可能会持续几秒钟。

在这种情况下，NGINX的性能明显优于HAProxy，其延迟峰值大约在1秒左右，并且持续时间与100 RPS情况相似。

对于Ambassador Edge Stack/Envoy，延迟通常保持在10毫秒以下。大约200毫秒的测试结束时，还有一个无法解释的大延迟尖峰。（我们认为这与我们的测试有关，但是正在做进一步的调查。

同样，我们可以在组合图表的上下文中查看所有这些数字：

结果：1000 RPS

最后，我们以1000 RPS测试了代理。HAProxy的延迟峰值变得更糟，某些请求可能需要长达25秒的时间。

NGINX的性能大大优于HAProxy，尽管在扩展和缩小Pod时延迟仍然会增加。有趣的是，当我们之前未观察到任何明显的延迟时，在调整路由配置时会看到大量的延迟峰值。

通Ambassador Edge Stack/Envoy，我们看到了短暂的启动延迟峰值和另一个异常的延迟峰值。整体的延迟仍然很出色，通常在10ms以下。

同样，我们可以在组合图表的上下文中查看所有这些数字：

最后

在负载下的弹性环境中测量响应延迟是ingress性能的关键但经常被忽视的方面。随着在Kubernetes上部署更多工作负载，确保ingress解决方案继续提供低响应延迟是优化最终用户体验的重要考虑因素。

同时，为可重现的工作负载设计现实世界的基准和测试工具需要大量投入。我们计划继续进行性能调整和扩展工作，以更好地量化Kubernetes中边缘代理的性能。

翻译自：https://www.getambassador.io/resources/envoyproxy-performance-on-k8s/

翻译：祝祥