Google Container Engine 中的 HTTPS 负载平衡器答案

【问题标题】：HTTPS load balancer in Google Container EngineGoogle Container Engine 中的 HTTPS 负载平衡器
【发布时间】：2015-08-24 17:36:02
【问题描述】：

我正在尝试使用HTTPS L7 load balancer 为 GKE 设置 HTTPS 负载平衡器，但由于某种原因无法正常工作。甚至是HTTP Load Balancing walkthrough 中的 HTTP 负载均衡器。创建了转发规则的 IP 地址，我可以 ping 和 telnet 到端口 80。但是当通过 curl 请求时，它给了我一个错误。

<title>502 Server Error</title> </head> <body text=#000000 
bgcolor=#ffffff> <h1>Error: Server Error</h1> <h2>The server 
encountered a temporary error and could not complete your request. 
<p>Please try again in 30 seconds.</h2> <h2></h2> </body></html>

所有步骤都很好，我为 ${NODE_PORT} 创建了一个没有任何标签的防火墙，但它不起作用。

有人遇到过这个问题吗？

【问题讨论】：

标签： google-compute-engine google-kubernetes-engine google-cloud-http-load-balancer

【解决方案1】：

我的应用程序也遇到了同样的问题，问题是我们没有返回“成功”的端点并且运行状况检查总是失败。

如果健康检查未通过，HTTP/HTTPS 负载均衡器似乎不会将请求发送到集群节点，所以我的解决方案是创建一个始终返回 200 OK 的端点，并且一旦健康检查路过，LB开始工作了。

【讨论】：

我遇到了同样的问题。这是否意味着我必须在 /healthz 上返回 200 的每个节点中创建一个空容器？
我认为您可以在现有容器中添加一条返回 200 的路由，但如果您不想对现有容器进行这些更改，那么可以
有人能解释一下怎么做吗？
如果我已经拥有此端点并且我的实例在负载平衡页面上显示为健康，是否有任何提示？
你为什么要这样做？健康检查是有原因的，LB 使用它们来确定您的后端是否可以接受流量。通过始终发送“假” 200，您是在欺骗 LB，使其认为您的集群节点始终是健康的，即使它们可能不是。这归结为您的客户在不健康时遇到错误（资源不足，其他一些问题等）。理想情况下，健康检查 URL 是特定于应用程序的，它应该指示节点是否“健康”——这也是您必须在应用程序的上下文中确定的内容。

【解决方案2】：

我刚刚浏览了这个示例，并且（在为 $NODE_PORT 打开防火墙之前）看到了相同的 502 错误。

如果您在云控制台中查看

https://console.developers.google.com/project/<project>/loadbalancing/http/backendServices/details/web-map-backend-service

您应该看到后端显示 ${num_nodes_in_cluster} 中的 0 个是健康的。

对于您的防火墙定义，请确保将源过滤器设置为 130.211.0.0/22 到 allow traffic from the the load balancing service，并将允许的协议和端口设置为 tcp:$NODE_PORT。

【讨论】：

hmm... 显然谷歌在 kubernetes 的 http 代理文档中忘记了这一点：cloud.google.com/container-engine/docs/tutorials/http-balancer
我在花了 1 小时试图弄清楚发生了什么之前读过这篇文章。

【解决方案3】：

我使用 GKE，我刚刚浏览了 example，它工作正常，但是当我路由到我自己的服务时，它不起作用。（我的服务是一个rest api服务）

我发现我的服务和示例最大的区别在于：示例有一个根端点（“/”），但我不支持它。

所以，我用这种方式解决了这个问题：向我的服务添加一个根端点（“/”），然后返回成功（一个不返回任何内容的空端点），然后重新创建入口，并等待几分钟，然后入口就起作用了！！

我认为这个问题应该是健康检查器UNHEALTHY instances do not receive new connections引起的。

这里是健康检查的链接：https://cloud.google.com/compute/docs/load-balancing/health-checks

【讨论】：

做了同样的事情并且工作得很好——谢谢你的提示。我知道安装 nginx 或任何其他网络服务器可以解决问题 - 但这很重要，因为我有意避免使用任何网络服务器以保持轻量级。

【解决方案4】：

在我的情况下，几分钟（如 5-10 分钟）后问题就解决了。

如果使用入口，则与入口相关的事件中可能会有其他信息。要查看这些：

kubectl describe ingress example

【讨论】：

我最近遇到了这个问题，它也自己解决了。尽管如此，这里和那里的停机几分钟是不能接受的。
使用 L7 LB 时会发生很多事情。如果您要重新配置链接到 L7 LB 的 GKE 入口，它会特别慢。有时我不得不等待 3 到 5 分钟，让事情自行解决。如果一切正常，请先等待几分钟。尝试修复实际上并未损坏的东西会令人困惑，我认为这就是这个答案的重点。

【解决方案5】：

在我的情况下，负载均衡器返回此错误，因为我的实例和实例组上没有运行 Web 服务器来处理网络请求。

我在所有机器上都安装了 nginx，然后它就开始工作了。

从现在开始，我会在创建 vm/instance 时将 nginx 添加到我的启动脚本中。

【讨论】：

【解决方案6】：

如果您在负载均衡器后面使用 nginx，那么 default_server 返回 200 或其他一些 2** 很重要。这意味着，例如，如果您有一个返回 301 的重写规则，那么它将失败。

解决方案是在你的主服务器上设置 default_server：

server {
    # Rewrite calls to www
    listen 443;
    server_name example.com;

    return 301 https://www.example.com$request_uri;
}


server {
    listen                  443 default_server;
    server_name             www.example.com;
    ...

【讨论】：

【解决方案7】：

为tcp:$NODEPORTIP 的Source: 130.211.0.0/22（GCP 上的负载平衡器范围）添加防火墙规则为我解决了这个问题。

【讨论】：

谢谢你！看来，如果您在 Google Cloud 中启用了防火墙，则必须将负载平衡器 IP 范围添加到防火墙。

【解决方案8】：

我创建了一个用户代理中包含“GoogleHC”的所有请求的端点。

所以，

server{
    server_name example.com www.example.com

    if ($http_user_agent ~* 'GoogleHC.*') {
        return 200 'isaac newton';
    }
}

【讨论】：