什么可能导致 GCP Cloud Run 的响应速度比 Kubernetes (GKE) 中运行的相同服务慢 10-30%？

Question

我有一个 Web 服务在 GCP 全局 HTTPS 负载均衡器后面的 GKE 中运行。相同的代码也部署到 Cloud Run。负载均衡器在 GKE 和 Cloud Run 之间按 50-50 的比例分配流量。根据负载均衡器的数据，Cloud Run 的总延迟比 GKE 高出约 10 到 30%。

https/total_latency，顶线是 Cloud Run 平均延迟，底线是 GKE 平均延迟

相同的代码部署到同一区域的两个环境中。该服务不依赖于数据库。它确实通过公共互联网发出 HTTP 请求，这使得来自 GKE 的请求的路由不太可能与 Cloud Run 中的请求不同。无论 HTTP 状态代码类别如何，无论是 2xx、3xx、4xx 还是 5xx，Cloud Run 和 GKE 之间的延迟都存在明显差异。也始终存在差距，表明问题不是由于冷启动造成的。

为了尽量消除 Cloud Run 实例负担过重的可能性，它们被赋予了比 GKE Pod 更多的 vCPU 核心和内存。并发请求的目标数量也设置为远低于 GKE 服务的 HPA 使用的目标请求速率。简而言之，Cloud Run 实例获得的资源比 GKE Pod 多得多。

根据症状，Cloud Run 可能存在系统性延迟来源。显示 Cloud Run 和 GKE 之间差异的唯一其他指标是负载均衡器的

https/backend_request_bytes_count

指标，该指标比 Cloud Run 高 2-3 倍（GKE 约为 1.2 KB，Cloud Run 约为 3.1 KB），这很难解释由于该服务仅接收 GET 请求，因此在负载均衡器在连接到 Cloud Run 时添加 1.9 KB 的标头之前，来自客户端的请求大小不太可能有差异。 https/backend_request_bytes_count，顶行是 Cloud Run，底行是 GKE 如果 Google Cloud 负载均衡器不重用 HTTP 连接，那么设置 TLS 连接是唯一想到的开销。

总而言之，是否存在系统性原因导致 Google Cloud Run 的基础架构比 GKE 慢？为什么 Google Cloud 负载均衡器和 Cloud Run 之间的请求大小比同一负载均衡器和 GKE 之间的请求大 2-3 倍？

Answer 1

解决方案是使用基于 Ubuntu 的映像而不是基于 Alpine 的映像。具体来说，对于相同版本的 Node.js，从 Node.js 的 Alpine 映像切换到默认映像解决了性能差距。相比之下，调整 Cloud Run 提供的设置（例如执行环境和最小实例数）在此场景中并没有产生任何影响。