零星的503s从指定的端口
我一直在使用Rancher来pipe理我们的仪表板应用程序，其中一部分涉及从同一端口暴露多个kibana容器，以及一个暴露在端口80上的kibana 3容器。
我想要因此发送指定的端口上的请求：5602,5603,5604到特定的容器，所以我设置了以下docker-compose.ymlconfiguration：
kibana: image: rancher/load-balancer-service ports: - 5602:5602 - 5603:5603 - 5604:5604 links: - kibana3:kibana3 - kibana4-logging:kibana4-logging - kibana4-metrics:kibana4-metrics labels: io.rancher.loadbalancer.target.kibana3: 5602=80 io.rancher.loadbalancer.target.kibana4-logging: 5603=5601 io.rancher.loadbalancer.target.kibana4-metrics: 5604=5601 一切按预期工作，但我得到零星的503。 当我进入容器，看看haproxy.cfg我看到：
frontend d898fb95-ec51-4c73-bdaa-cc0435d8572a_5603_frontend bind *:5603 mode http default_backend d898fb95-ec51-4c73-bdaa-cc0435d8572a_5603_2_backend backend d898fb95-ec51-4c73-bdaa-cc0435d8572a_5603_2_backend mode http timeout check 2000 option httpchk GET /status HTTP/1.1 server cbc23ed9-a13a-4546-9001-a82220221513 10.42.60.179:5603 check port 5601 inter 2000 rise 2 fall 3 server 851bdb7d-1f6b-4f61-b454-1e910d5d1490 10.42.113.167:5603 server 215403bb-8cbb-4ff0-b868-6586a8941267 10.42.85.7:5601
列出的IP都是三个Kibana容器，第一个容器有一个健康检查，但没有其他的（kibana3 / kibana4.1没有状态端点）。 我对docker-composeconfiguration的理解是它应该每个后端只有一个服务器，但是这三个似乎都列出来了，我认为这部分是零星的503s，手动删除并重新启动haproxy服务解决问题。
我正在configuration负载平衡器不正确，或者这是值得提出作为与牧场人Github问题？
我在Rancher的论坛上发帖，就像Rancher Labs在twitter上所build议的那样： https : //forums.rancher.com/t/load-balancer-sporadic-503s-with-multiple-port-bindings/2358
有人从牧场主张贴了一个链接到一个github的问题，这是类似于我所经历的： https : //github.com/rancher/rancher/issues/2475
总而言之，负载平衡器将通过所有匹配的后端进行轮换，这是一个涉及“虚拟”域的解决scheme，我已经通过configuration确认了这一点，即使它稍微不雅。
labels: # Create a rule that forces all traffic to redis at port 3000 to have a hostname of bogus.com # This eliminates any traffic from port 3000 to be directed to redis io.rancher.loadbalancer.target.conf/redis: bogus.com:3000 # Create a rule that forces all traffic to api at port 6379 to have a hostname of bogus.com # This eliminates any traffic from port 6379 to be directed to api io.rancher.loadbalancer.target.conf/api: bogus.com:6379
（^^从rancher github问题复制，而不是我的解决方法）
我将会看到通过端口路由和提出PR / Github问题是多么容易，因为我认为这是在这种情况下LB的有效用例。
确保您正在使用Docker容器上最初公开的端口。 由于某种原因，如果将其绑定到其他端口，HAProxy将无法工作。 如果您使用的DockerHub中的容器正在使用已经在系统上使用的端口，那么您可能必须重新构build该容器容器，以通过像nginx这样的代理路由它来使用不同的端口。