Google Cloud Load Balancer - 502 - 非托管实例组未通过健康检查

Google Cloud Load Balancer - 502 - Unmanaged instance group failing health checks

我目前有一个 HTTPS 负载平衡器设置,它使用 443 前端、后端和运行状况检查为单个主机 nginx 实例提供服务。

当通过浏览器直接导航到主机时,页面会正确加载有效的 SSL 证书。

尝试通过负载平衡器 IP 访问站点时,我收到 502 - 服务器错误消息。我检查了 Google 日志,发现负载均衡器出现 "failed_to_pick_backend" 错误。我还注意到它未通过健康检查。

一些挖掘让我找到了这两个链接:https://cloudplatform.googleblog.com/2015/07/Debugging-Health-Checks-in-Load-Balancing-on-Google-Compute-Engine.html

https://github.com/coreos/bugs/issues/1195

Issue #1 - Not sure if google-address-manager is running on the server (RHEL 7). I do not see an entry for the HTTPS load balancer IP in the routes. The Google SDK is installed. This is a Google-provided image and if I update the IP address in the console, it also gets updated on the host. How do I check if google-address-manager is running on RHEL7?

[root@server]# ip route ls table local type local scope host
10.212.2.40 dev eth0 proto kernel src 10.212.2.40
127.0.0.0/8 dev lo proto kernel src 127.0.0.1
127.0.0.1 dev lo proto kernel src 127.0.0.1

所有 google 服务的输出

[root@server]# systemctl list-unit-files
google-accounts-daemon.service                enabled
google-clock-skew-daemon.service              enabled
google-instance-setup.service                 enabled
google-ip-forwarding-daemon.service           enabled
google-network-setup.service                  enabled
google-shutdown-scripts.service               enabled
google-startup-scripts.service                enabled

Issue #2: Not receiving a 200 OK response. The certificate is valid and the same on both the LB and server. When running curl against the app server I receive this response.

root@server.com  curl -I https://app-server.com
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.haxx.se/docs/sslcerts.html

想法?

您应该为健康检查服务添加防火墙规则 - https://cloud.google.com/compute/docs/load-balancing/health-checks#health_check_source_ips_and_firewall_rules 并确保您的后端服务侦听负载均衡器 ip(最简单的方法是绑定到 0.0.0.0)——这对于内部负载均衡器来说绝对是正确的,不确定使用外部 ip 的 HTTPS。

一些更新和经验教训:

我发现 "google-address-manager" 现已弃用,取而代之的是 "google-ip-forward-daemon",即 运行。

[root@server ~]# sudo service google-ip-forwarding-daemon status
Redirecting to /bin/systemctl status google-ip-forwarding-daemon.service
 google-ip-forwarding-daemon.service - Google Compute Engine IP Forwarding Daemon
   Loaded: loaded (/usr/lib/systemd/system/google-ip-forwarding-daemon.service; enabled; vendor preset: enabled)
   Active: active (running) since Fri 2017-12-22 20:45:27 UTC; 17h ago
 Main PID: 1150 (google_ip_forwa)
   CGroup: /system.slice/google-ip-forwarding-daemon.service
           └─1150 /usr/bin/python /usr/bin/google_ip_forwarding_daemon

存在允许 IP 范围 130.211.0.0/22 和 35.191.0.0/16 用于端口 443 的活动防火墙规则。目标也已正确设置。

最后,健康检查目前使用默认的“/”路径。开发人员在开发过程中已经在站点前面进行了身份验证。如果我绕过 SSL 证书错误,我会在 运行 curl 时收到未经授权的 401。这是我们遇到的问题的根本原因。为了补救,我们修改了 nginx 基本身份验证配置以禁用对新路由的身份验证(例如 /health)

更新 nginx 配置并且在健康检查时将路径更新为新的 /health 路由后,我们收到了 200 个有效响应。这允许对 return 个健康实例进行健康检查,并允许 LB 通过流量