gpt4 book ai didi

docker - Docker集群模式负载均衡无法按说明工作

转载 作者:行者123 更新时间:2023-12-02 18:16:08 25 4
gpt4 key购买 nike

更新资料

我相信罪魁祸首是似乎没有在端口7946上侦听的主服务器。netstat显示7946在节点上侦听,但不是主机。当我检查节点的系统日志时,我看到以下错误

level=error msg="Failed to join memberlist [10.0.0.12] on retry: 1 error(s) occurred:\n\n* Failed to join 10.0.0.12: dial tcp 10.0.0.12:7946: getsockopt: connection refused"

原始帖子

我正在AWS中运行一个三节点的Swarm Mode集群;一位主人和两名 worker 。这是 swarm模式,请勿与1.12之前的 docker swarm 混淆。

我使用docker-machine创建了所有服务。每台机器都运行带有Docker 1.12.3的Ubuntu 15.10。
Linux swarm-master-01 4.2.0-42-generic #49-Ubuntu SMP Tue Jun 28 21:26:26 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

使用主节点,我创建了以下服务
docker service create --replicas 1 --name myapp -p 3000 myapp

当我运行 docker service ps myapp时,我得到以下输出
ID                         NAME     IMAGE         NODE             DESIRED STATE  CURRENT STATE            ERROR
02awst8p9pezgpkfzqgz8z79t myapp.1 myapp:latest swarm-node-01 Running Running 19 minutes ago

正在运行的任务已部署到swarm-node-01。

我检查了已公开发布的自动选择的端口
$ docker service inspect myapp | jq .[].Endpoint.Ports[].PublishedPort
30000

根据 documentation:

External components, such as cloud load balancers, can access the service on the PublishedPort of any node in the cluster whether or not the node is currently running the task for the service. All nodes in the swarm route ingress connections to a running task instance.



但是,当我尝试 curl 没有运行任务的节点时,我得到的是 connection refused
$ curl $(docker-machine ip swarm-node-01):30000/stats
{"uptime":"2016-11-09T14:48:35Z","requestCount":7,"statuses":{"200":7},"pid":1,"open_db_conns":0}

$ curl $(docker-machine ip swarm-node-02):30000/stats
curl: (7) Failed to connect to [the IP] port 30000: Connection refused

注意:我清理了节点02 的IP

我的故障排除:
  • 节点均正确连接到群集
  • 将服务扩展到5(本质上将任务部署到每个节点)可以使curl在每个节点上工作,因为任务已部署到每个节点。

  • 更新1

    我用初始化了群
    docker swarm init --advertise-addr 10.0.0.12:2377 --listen-addr 10.0.0.12:2377

    我从节点检查了系统日志,并看到以下错误
    level=error msg="Failed to join memberlist [10.0.0.12] on retry: 1 error(s) occurred:\n\n* Failed to join 10.0.0.12: dial tcp 10.0.0.12:7946: getsockopt: connection refused"

    我检查了一下入口端口是否正在侦听,似乎不是
    ubuntu@swarm-master-01:~$ sudo lsof -i :7946
    ubuntu@swarm-master-01:~$ cat < /dev/tcp/10.0.0.12/7946
    -bash: connect: Connection refused
    -bash: /dev/tcp/10.0.0.12/7946: Connection refused
    ubuntu@swarm-master-01:~$ cat < /dev/tcp/0.0.0.0/7946
    -bash: connect: Connection refused
    -bash: /dev/tcp/0.0.0.0/7946: Connection refused

    最佳答案

    我现在可以解决该问题,但是我不知道最初是什么原因引起的。覆盖网络(端口7946)未在swarm-master-01上监听。我用netstat -nlt弄清楚了。我搜索了系统日志,发现这些错误与系统日志中的端口有关。

    Nov  8 20:28:20 ubuntu docker[23092]: time="2016-11-08T20:28:20.171385360Z" level=warning msg="2016/11/08 20:28:20 [ERR] memberlist: Failed TCP fallback ping: read tcp 10.0.0.85:54016->10.0.0.13:7946: i/o timeout"
    Nov 9 18:26:17 swarm-node-01 docker[714]: time="2016-11-09T18:26:17.573441271Z" level=warning msg="2016/11/09 18:26:17 [ERR] memberlist: Failed to send indirect ping: write udp [::]:7946->10.0.0.38:7946: use of closed network connection"

    出于某种原因, docker 拒绝打开此端口并继续监听。这是我为避免问题而做的(尽管不希望这样做):
  • 使用docker-machine创建了另一个名为swarm-master-02的节点
  • 作为主
  • 将swarm-master-02加入集群
  • 降级的master-01,将master-02设置为领导者
  • 在每个节点上重新启动docker守护程序(可能没有必要)

  • 现在,除了swarm-master-01以外,所有机器都按预期工作。一个任务正在swarm-node-01上运行,并且curl通过将流量转发到适当节点上的适当容器来对所有节点起作用。但是,swarm-master-01拒绝在覆盖网络上侦听,并且curl无法对此节点起作用。我只能通过将swarm-master-01从集群中完全删除,重新启动docker守护程序并再次将其作为主服务器来修复它。现在7946正在该机器上监听。

    关于docker - Docker集群模式负载均衡无法按说明工作,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/40510437/

    25 4 0
    Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
    广告合作:1813099741@qq.com 6ren.com