在典型的Kubernetes部署中，所有流向Kubernetes服务的流量都通过一个ingress进行。Ingress将代理从Internet到后端服务的流量，因此，入口处于性能的关键路径上。有多种基准测试方法并衡量效果。
衡量代理性能的最常见方法可能是原始吞吐量，在这种类型的测试中，通过代理发送的流量不断增加，并且代理可以处理的最大流量也得到了衡量。每秒请求数（RPS）中的性能。
但是实际上，大多数组织不太可能对任何现代代理服务器的吞吐量进行限制，而且吞吐量是线性扩展的-当代理服务器的吞吐量达到最大时，可以部署第二个实例来有效地使吞吐量增加一倍。
本文探讨了另一种类型的性能维度：延迟。通过代理的每个请求都会在代理解析请求并将请求路由到适当的目的地时引入少量的延迟。与吞吐量不同，延迟无法通过简单地扩展数量来改善。而且，至关重要的是，延迟对您的关键业务指标有重大影响。
Kubernetes中的边界代理
可以说，当今最流行的三个L7代理是Envoy Proxy，HAProxy和NGINX，在Kubernetes中，这些代理通常是通过控制平面配置的，而不是直接部署的。
- ingress-nginx是Kubernetes上最常见的Ingress，建立在NGINX之上，我们使用了nginx-ingress-controller：0.25.0，它基于OpenResty 1.15.8，而后者又基于NGINX 1.15.8。
- 基于1.8.21的HAProxy入口控制器（https://github.com/jcmoraisjr...）版本0.7.3，我们尝试使用官方的HAProxy入口控制器，但是在测试时，官方控制器仅公开了8个配置选项，因此无法用于基准测试。最近，该控制器已扩展为25个配置选项。
- Ambassador Edge Stack，基于Envoy代理构建的。
基准测试延迟
容器环境造成了弹性和短暂的变化;随着利用率的变化，容器被创建和销毁;部署了新版本的容器化微服务，导致新路由被注册;开发人员可能希望根据实际情况调整超时，速率限制和其他配置参数。
在我们的基准测试中，我们通过边缘代理通过TLS向运行在三个Pod上的后端服务（https://github.com/hashicorp/...）发送稳定的HTTP/1.1请求流。进行TLS终止。然后，我们将后端服务扩展到四个Pod，然后每三十秒将其缩减到三个Pod，在此过程中采样延迟。我们循环浏览此模式三遍，然后通过以下方式模拟一些路由配置更改：每三十秒间隔进行三个附加更改：
- CORS headers
- Adding a custom response header
- Rewriting the request path
然后我们返回到基本配置，我们测量10％请求的延迟，然后在图表上分别绘制每个延迟。
Test Setup
所有测试均在n1-standard-1节点上的Google Kubernetes Engine中运行，使用了三个节点池：一个用于ingress，一个用于后端服务，一个用于负载生成器，每个节点池由三个单独的节点组成，所有入口都被配置为绕过kube-proxy直接路由到服务端点。Vegeta用于生成负载。借助Ambassador Edge Stack，我们将端点路由配置为绕过kube-proxy。
通常，所有ingress都使用默认配置，但有两个例外：
- 使用NGINX，我们将保持连接请求从默认的100增加到2147483647，以实现连接重用
- 使用Ambassador Edge Stack，端点路由被用来绕过kube-proxy（注意，我们不需要为NGINX和HAProxy更改此设置，因为它们默认情况下使用端点路由。）
由多名工程师进行了多次测试，以确保测试的一致性。
Results: 100 RPS
在每秒100个请求的负载下，当后端服务将峰值扩展或缩减峰值到大约1000ms时，向HAProxy发出请求。这些峰值的持续时间约为900ms。
NGINX的性能略高于HAProxy，延迟峰值约为750毫秒（首次扩展操作除外），这些延迟峰值的持续时间约为900毫秒。
使用Ambassador Edge Stack和Envoy代理，我们可以看到明显更好的性能。请注意图中的Y轴。除了25毫秒的启动延迟峰值之外，没有明显的延迟峰值模式发生，大多数延迟低于5毫秒。
要在上下文中查看所有这些数字，我们将所有延迟数字覆盖在一个具有通用比例的图形上：
Results: 500 RPS
在500 RPS时，我们开始看到HAProxy的更大的延迟峰值，持续时间和延迟都增加，延迟峰值长达10秒，这些延迟峰值可以持续几秒钟。
在这种情况下，NGINX的性能明显优于HAProxy，其延迟峰值大约在1秒左右，并且持续时间与100 RPS情况相似。
借助Ambassador Edge Stack/Envoy，延迟通常保持在10ms以下。在测试结束时，大约有200ms的时间，还有一个无法解释的巨大延迟峰值（我们认为这与我们的测试有关，但正在做进一步的调查。）
同样，我们可以在组合图表的上下文中查看所有这些数字：
Results: 1000 RPS
最后，我们以1000 RPS的速度测试了代理服务器，HAProxy的延迟峰值变得更糟，有些请求的时间长达25秒。
NGINX在性能上比HAProxy大幅度提高，尽管当Pod放大和缩小时延迟仍然会增加；有趣的是，当我们调整路由配置时（以前没有观察到任何明显的延迟），我们看到了显着的延迟高峰。
借助Ambassador Edge Stack/Envoy，我们看到了短暂的启动延迟峰值和另一个异常延迟峰值，整个系统的延迟仍然非常好，通常在10ms以下。
同样，我们可以在组合图表的上下文中查看所有这些数字：
总结
在负载下的弹性环境中测量响应延迟是入口性能的关键但经常被忽视的方面。随着组织在Kubernetes上部署更多工作负载，确保入口解决方案继续提供低响应延迟是优化终端的重要考虑因素用户体验。