为什么我不能在 Kubernetes 上横向扩展一个简单的 HTTP/2 服务?
Why can't I scale horizontally a simple HTTP/2 service on Kubernetes?
我已经部署了一些简单的服务作为概念证明:使用 修补的 nginx 网络服务器以实现高性能。
我还编辑了 /etc/nginx/conf.d/default.conf
,使行 listen 80;
变为 listen 80 http2;
。
我正在使用 Locust 分布式负载测试工具,其中 class 将 requests
模块替换为 hyper
以测试 HTTP/2 工作负载。这在性能方面可能不是最佳的,但我可以产生很多蝗虫工人,所以这不是一个大问题。
为了测试,我在 5 台机器的 GKE 上生成了一个集群,2 vCPU,每台 4GB RAM,安装了 Helm 和这些服务的图表(我可以 post 它们在要点上以后有用的话)。
我用 min_time=0 和 max_time=0 测试了 Locust,以便它产生尽可能多的请求;有 10 个工人针对单个 nginx 实例。
有 10 个工作人员,总共 140 个 "clients",我每秒收到约 2.1k 个请求 (RPS)。
10 workers, 260 clients: I get ~2.0k RPS
10 workers, 400 clients: ~2.0k RPS
现在,我尝试水平扩展:我生成 5 个 nginx 实例并得到:
10 workers, 140 clients: ~2.1k RPS
10 workers, 280 clients: ~2.1k RPS
20 workers, 140 clients: ~1.7k RPS
20 workers, 280 clients: ~1.9k RPS
20 workers, 400 clients: ~1.9k RPS
正如 kubectl top pod
所描绘的那样,资源使用率非常低(这是针对 10 个工作人员,280 个客户端;nginx 不受资源限制,每个 pod 的 Locust 工作人员限制为 1 CPU) :
user@cloudshell:~ (project)$ kubectl top pod
NAME CPU(cores) MEMORY(bytes)
h2test-nginx-cc4d4c69f-4j267 34m 68Mi
h2test-nginx-cc4d4c69f-4t6k7 27m 68Mi
h2test-nginx-cc4d4c69f-l942r 30m 69Mi
h2test-nginx-cc4d4c69f-mfxf8 32m 68Mi
h2test-nginx-cc4d4c69f-p2jgs 45m 68Mi
lt-master-5f495d866c-k9tw2 3m 26Mi
lt-worker-6d8d87d6f6-cjldn 524m 32Mi
lt-worker-6d8d87d6f6-hcchj 518m 33Mi
lt-worker-6d8d87d6f6-hnq7l 500m 33Mi
lt-worker-6d8d87d6f6-kf9lj 403m 33Mi
lt-worker-6d8d87d6f6-kh7wt 438m 33Mi
lt-worker-6d8d87d6f6-lvt6j 559m 33Mi
lt-worker-6d8d87d6f6-sxxxm 503m 34Mi
lt-worker-6d8d87d6f6-xhmbj 500m 33Mi
lt-worker-6d8d87d6f6-zbq9v 431m 32Mi
lt-worker-6d8d87d6f6-zr85c 480m 33Mi
为了更容易复制,我在 GKE 上描绘了这个测试,但我在私有云集群中得到了相同的结果。
为什么我产生多少个服务实例似乎无关紧要?
更新:根据第一个答案,我正在更新有关节点的信息以及单个 Locust worker 发生的情况。
1 worker, 1 clients: 22 RPS
1 worker, 2 clients: 45 RPS
1 worker, 4 clients: 90 RPS
1 worker, 8 clients: 174 RPS
1 worker, 16 clients: 360 RPS
32 clients: 490 RPS
40 clients: 480 RPS (this seems over max. sustainable clients per worker)
但最重要的是,问题的根源似乎是我的能力极限:
user@cloudshell:~ (project)$ kubectl top pod
NAME CPU(cores) CPU% MEMORY(bytes) MEMORY%
gke-sc1-default-pool-cbbb35bb-0mk4 1903m 98% 695Mi 24%
gke-sc1-default-pool-cbbb35bb-9zgl 2017m 104% 727Mi 25%
gke-sc1-default-pool-cbbb35bb-b02k 1991m 103% 854Mi 30%
gke-sc1-default-pool-cbbb35bb-mmcs 2014m 104% 776Mi 27%
gke-sc1-default-pool-cbbb35bb-t6ch 1109m 57% 743Mi 26%
如果我没理解错的话,你在 cluster/nodes 和你的 pods 上做了 运行 负载测试,这肯定会对整体结果产生影响,我会推荐你将客户端与服务器分开在不同的节点上,这样就不会相互影响。
对于您报告的值,可以清楚地看到工作人员消耗的 CPU 多于 nginx 服务器。
您应该勾选:
- 主机CPU利用率,上下文切换可能压力很大,因为线程数量远高于CPU可用数量。
- 网络瓶颈,也许你可以尝试添加更多节点或增加工作人员容量(SKU)并将客户端与服务器分开。
- 客户端没有足够的容量来生成负载,您增加线程但原始限制相同
您还应该测试单个服务器容量以验证每个服务器的限制,因此您有一个参数可以比较结果是否符合预期值。
我已经部署了一些简单的服务作为概念证明:使用 修补的 nginx 网络服务器以实现高性能。
我还编辑了 /etc/nginx/conf.d/default.conf
,使行 listen 80;
变为 listen 80 http2;
。
我正在使用 Locust 分布式负载测试工具,其中 class 将 requests
模块替换为 hyper
以测试 HTTP/2 工作负载。这在性能方面可能不是最佳的,但我可以产生很多蝗虫工人,所以这不是一个大问题。
为了测试,我在 5 台机器的 GKE 上生成了一个集群,2 vCPU,每台 4GB RAM,安装了 Helm 和这些服务的图表(我可以 post 它们在要点上以后有用的话)。
我用 min_time=0 和 max_time=0 测试了 Locust,以便它产生尽可能多的请求;有 10 个工人针对单个 nginx 实例。
有 10 个工作人员,总共 140 个 "clients",我每秒收到约 2.1k 个请求 (RPS)。
10 workers, 260 clients: I get ~2.0k RPS
10 workers, 400 clients: ~2.0k RPS
现在,我尝试水平扩展:我生成 5 个 nginx 实例并得到:
10 workers, 140 clients: ~2.1k RPS
10 workers, 280 clients: ~2.1k RPS
20 workers, 140 clients: ~1.7k RPS
20 workers, 280 clients: ~1.9k RPS
20 workers, 400 clients: ~1.9k RPS
正如 kubectl top pod
所描绘的那样,资源使用率非常低(这是针对 10 个工作人员,280 个客户端;nginx 不受资源限制,每个 pod 的 Locust 工作人员限制为 1 CPU) :
user@cloudshell:~ (project)$ kubectl top pod
NAME CPU(cores) MEMORY(bytes)
h2test-nginx-cc4d4c69f-4j267 34m 68Mi
h2test-nginx-cc4d4c69f-4t6k7 27m 68Mi
h2test-nginx-cc4d4c69f-l942r 30m 69Mi
h2test-nginx-cc4d4c69f-mfxf8 32m 68Mi
h2test-nginx-cc4d4c69f-p2jgs 45m 68Mi
lt-master-5f495d866c-k9tw2 3m 26Mi
lt-worker-6d8d87d6f6-cjldn 524m 32Mi
lt-worker-6d8d87d6f6-hcchj 518m 33Mi
lt-worker-6d8d87d6f6-hnq7l 500m 33Mi
lt-worker-6d8d87d6f6-kf9lj 403m 33Mi
lt-worker-6d8d87d6f6-kh7wt 438m 33Mi
lt-worker-6d8d87d6f6-lvt6j 559m 33Mi
lt-worker-6d8d87d6f6-sxxxm 503m 34Mi
lt-worker-6d8d87d6f6-xhmbj 500m 33Mi
lt-worker-6d8d87d6f6-zbq9v 431m 32Mi
lt-worker-6d8d87d6f6-zr85c 480m 33Mi
为了更容易复制,我在 GKE 上描绘了这个测试,但我在私有云集群中得到了相同的结果。
为什么我产生多少个服务实例似乎无关紧要?
更新:根据第一个答案,我正在更新有关节点的信息以及单个 Locust worker 发生的情况。
1 worker, 1 clients: 22 RPS
1 worker, 2 clients: 45 RPS
1 worker, 4 clients: 90 RPS
1 worker, 8 clients: 174 RPS
1 worker, 16 clients: 360 RPS
32 clients: 490 RPS
40 clients: 480 RPS (this seems over max. sustainable clients per worker)
但最重要的是,问题的根源似乎是我的能力极限:
user@cloudshell:~ (project)$ kubectl top pod
NAME CPU(cores) CPU% MEMORY(bytes) MEMORY%
gke-sc1-default-pool-cbbb35bb-0mk4 1903m 98% 695Mi 24%
gke-sc1-default-pool-cbbb35bb-9zgl 2017m 104% 727Mi 25%
gke-sc1-default-pool-cbbb35bb-b02k 1991m 103% 854Mi 30%
gke-sc1-default-pool-cbbb35bb-mmcs 2014m 104% 776Mi 27%
gke-sc1-default-pool-cbbb35bb-t6ch 1109m 57% 743Mi 26%
如果我没理解错的话,你在 cluster/nodes 和你的 pods 上做了 运行 负载测试,这肯定会对整体结果产生影响,我会推荐你将客户端与服务器分开在不同的节点上,这样就不会相互影响。
对于您报告的值,可以清楚地看到工作人员消耗的 CPU 多于 nginx 服务器。
您应该勾选:
- 主机CPU利用率,上下文切换可能压力很大,因为线程数量远高于CPU可用数量。
- 网络瓶颈,也许你可以尝试添加更多节点或增加工作人员容量(SKU)并将客户端与服务器分开。
- 客户端没有足够的容量来生成负载,您增加线程但原始限制相同
您还应该测试单个服务器容量以验证每个服务器的限制,因此您有一个参数可以比较结果是否符合预期值。