Google Cloud Load Balancer - 502 - 未管理的实例组运行状况检查失败

时间:2017-12-23 01:51:27

标签: ssl nginx google-cloud-platform google-compute-engine rhel7

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

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

尝试通过负载均衡器IP访问该站点时,收到502-Server错误消息。我查看了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

  

问题#1 - 不确定google-address-manager是否在服务器上运行   (RHEL 7)。我没有在HTTPS中看到HTTPS负载均衡器IP的条目   路线。已安装Google SDK。这是Google提供的图片   如果我在控制台中更新IP地址,它也会更新   主人。如何检查google-address-manager是否正在运行   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
  

问题#2:没有收到200 OK响应。证书有效   和LB和服务器上的相同。当运行卷曲时   应用服务器我收到此回复。

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

思想?

2 个答案:

答案 0 :(得分:1)

您应该为运行状况检查服务添加防火墙规则 -  https://cloud.google.com/compute/docs/load-balancing/health-checks#health_check_source_ips_and_firewall_rules并确保您的后端服务侦听负载均衡器ip(最简单的是绑定到Fetching package metadata ........... Solving package specifications: . Package plan for installation in environment /home/imakaev/miniconda3: The following NEW packages will be INSTALLED: anaconda: custom-py36hbbc8b67_0 The following packages will be UPDATED: conda: 4.3.31-py36_0 --> 4.4.3-py36_0 anaconda-custo 100% |###################################################################| Time: 0:00:00 15.63 MB/s conda-4.4.3-py 100% |###################################################################| Time: 0:00:00 48.26 MB/s ) - 这对于内部负载均衡器来说肯定是正确的,不确定HTTPS是否使用外部IP。< / p>

答案 1 :(得分:0)

一些更新和经验教训:

我发现“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

有一个活动的防火墙规则允许端口443的IP范围为130.211.0.0/22和35.191.0.0/16。目标也已正确设置。

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

一旦更新了nginx配置并且在健康状况检查中将路径更新到新的/健康路线,我们就会收到200个有效的回复。这允许运行状况检查返回健康实例并允许LB通过流量