GCP 负载均衡器实例在短时间后变得不健康

GCP load balancer instance becomens unhealthy after short period of time

我已将我的 linux apache 网络服务器 运行 放在 google 负载平衡器后面的 GCP 上。因为我只想要 https 流量,所以我已将端口 80 重定向到 443,如下所示:

<VirtualHost *:80>
  ServerName  spawnparty.com
  ServerAlias www.spawnparty.com
  DocumentRoot /var/www/html/wwwroot
  Redirect permanent / https://www.spawnparty.com
</VirtualHost>

我已经给虚拟机一个外部 IP 地址来测试重定向是否有效。

然后我配置了负载平衡器。我已经做到了,以便前端接受 http 和 https。对于后端,我做了 2 项服务:

一个使用 http,一个使用 https,这样如果 somoeone 通过 http 进入,它将被转发,然后通过上面显示的代码重定向到 https。

对两个后端服务进行基本的健康检查:

for http: port: 80, timeout: 5s, check interval: 5s, unhealthy threshold: 2 attempts

for https: port: 443, timeout: 5s, check interval: 5s, unhealthy threshold: 2 attempts

https 工作正常,1 个实例中有 1 个健康,但 HTTP 健康检查状态为 1 个实例中的 0 个健康

如果将健康检查从 http 更改为 https,然后再次更改为 http 后端服务,它会在短时间内工作,但几分钟后它会再次显示 0 of 1 实例健康。

我必须改变什么才能保持健康?

将除健康检查页面之外的所有内容重定向到 HTTPS。 question explains how you can do that. GCE Network load balancing 提到了这个要求,说 "Even if your service does not use HTTP, you'll need to at least run a basic web server on each instance that the health check system can query."

TL;DR - 对两个后端服务使用相同的 HTTPS 健康检查。

运行状况检查和响应代码

您需要在配置的时间内回复200响应码并正常关闭连接。

HTTP and HTTPS health checks

If traffic from the load balancer to your instances uses the HTTP or HTTPS protocol, then HTTP or HTTPS health checks verify that the instance is healthy and the web server is up and serving traffic.

For an HTTP(S) health check probe to be deemed successful, the instance must return a valid HTTP response with code 200 and close the connection normally within the configured period. If it does this a specified number of times in a row, the health check returns a status of HEALTHY for that instance. If an instance fails a specified number of health check probes in a row, it is marked UNHEALTHY without any notification being sent. UNHEALTHY instances do not receive new connections, but existing connections are allowed to continue. UNHEALTHY instances continue to receive health check probes. If an instance later passes a health check by successfully responding to a specified number of consecutive health check probes, it is marked HEALTHY and starts receiving new connections, again without any notification.

由于您有 2 个独立的后端服务(一个用于 HTTP,另一个用于 HTTPS),您将需要进行 2 次健康检查(尽管后端服务也允许在需要时重复使用相同的健康检查 - 请继续阅读),因为负载均衡器考虑他们独立服务。

正如您已经确认的那样,使用 HTTPS 健康检查将适用于基于 HTTPS 的服务,但使用 HTTP 健康检查则不行。原因是您实际上返回的是用于永久 URL 重定向的 HTTP 301 响应代码,而不是预期的 HTTP 200 响应代码。

可能的解决方案

解决此问题的一种方法是对两个后端服务使用 HTTPS 运行状况检查,因为您的底层服务仍然相同。您失去了对重定向进行健康检查的能力,但遗憾的是 Google 云负载均衡器不支持这种功能。您也可以为两个后端服务共享相同的 HTTPS 健康检查资源。

CharlesB 发布的解决方案也可以,但我觉得您正在添加额外的重定向规则只是为了满足健康检查,并且无论如何都不会在您的服务路径上使用。您还需要一个单独的 HTTP 健康检查资源。仅对后端服务使用 HTTPS 健康检查我觉得要简单得多,并且还可以验证您的服务是否处于活动状态以处理新请求。