3

我有两个 nameko 服务，它们通过 RabbitMQ 使用 RPC 进行通信。在本地使用 docker-compose 一切正常。然后我将所有内容部署到 DigitalOcean 上的 Kubernetes/Istio 集群并开始出现以下错误。它在 10/20/60 分钟内连续重复 1 次。服务之间的通信工作正常（我想是在重新连接之前和之后），但是日志会因为那些不应该发生的意外重新连接而变得混乱。

Helm RabbitMQ 配置文件

我尝试增加 RAM 和 CPU 配置（到上面配置文件中的值：512Mb 和 400m）但仍然有相同的行为。

注意：部署后我不接触服务，没有发送消息或发出任何请求，我在大约 60 分钟内第一次遇到此错误。当我提出请求时，它们会成功，但最终我们在日志中仍然会出现此错误。

Nameko服务日志：

"Connection to broker lost, trying to re-establish connection...",
"exc_info": "Traceback (most recent call last):
File \"/usr/local/lib/python3.6/site-packages/kombu/mixins.py\", line 175, in run for _ in self.consume(limit=None, **kwargs):
File \"/usr/local/lib/python3.6/site-packages/kombu/mixins.py\", line 197, in consume   conn.drain_events(timeout=safety_interval)
File \"/usr/local/lib/python3.6/site-packages/kombu/connection.py\", line 323, in drain_events
return self.transport.drain_events(self.connection, **kwargs)
File \"/usr/local/lib/python3.6/site-packages/kombu/transport/pyamqp.py\", line 103, in drain_events
return connection.drain_events(**kwargs)
File \"/usr/local/lib/python3.6/site-packages/amqp/connection.py\", line 505, in drain_events
while not self.blocking_read(timeout):
File \"/usr/local/lib/python3.6/site-packages/amqp/connection.py\", line 510, in blocking_read\n    frame = self.transport.read_frame()
File \"/usr/local/lib/python3.6/site-packages/amqp/transport.py\", line 252, in read_frame
frame_header = read(7, True)
File \"/usr/local/lib/python3.6/site-packages/amqp/transport.py\", line 446, in _read
raise IOError('Server unexpectedly closed connection')
OSError: Server unexpectedly closed connection"}
{"name": "kombu.mixins", "asctime": "29/12/2019 20:22:54", "levelname": "INFO", "message": "Connected to amqp://user:**@rabbit-rabbitmq:5672//"}

RabbitMQ 日志

2019-12-29 20:22:54.563 [warning] <0.718.0> closing AMQP connection <0.718.0> (127.0.0.1:46504 -> 127.0.0.1:5672, vhost: '/', user: 'user'):
client unexpectedly closed TCP connection
2019-12-29 20:22:54.563 [warning] <0.705.0> closing AMQP connection <0.705.0> (127.0.0.1:46502 -> 127.0.0.1:5672, vhost: '/', user: 'user'):
client unexpectedly closed TCP connection
2019-12-29 20:22:54.681 [info] <0.3424.0> accepting AMQP connection <0.3424.0> (127.0.0.1:43466 -> 127.0.0.1:5672)
2019-12-29 20:22:54.689 [info] <0.3424.0> connection <0.3424.0> (127.0.0.1:43466 -> 127.0.0.1:5672): user 'user' authenticated and granted access to vhost '/'
2019-12-29 20:22:54.690 [info] <0.3431.0> accepting AMQP connection <0.3431.0> (127.0.0.1:43468 -> 127.0.0.1:5672)
2019-12-29 20:22:54.696 [info] <0.3431.0> connection <0.3431.0> (127.0.0.1:43468 -> 127.0.0.1:5672): user 'user' authenticated and granted access to vhost '/'

升级版：

兔荚 yaml

4

2 回答 2

3

问题是 istio 代理被注入作为 rabbitmq pod 内的 sidecar 容器。您需要从 rabbitmq 中排除 istio 代理，然后它应该可以工作。

于 2020-01-07T18:06:04.020 回答
0

您是否尝试过增加连接的心跳？由于不活动，您的连接可能会在较低级别终止。

还要确保您有足够的资源在主机上运行所有容器。

我有类似的问题，我不确定以下哪一项为我解决了这个问题：

  1. 适当的资源管理
  2. 在 bash 脚本的 DockerFile 中创建一个入口点，该脚本使用应该在无限循环中执行的代码运行该文件。（我知道一个解决了内存泄漏的问题——bash 脚本用你的代码执行文件，你的代码监听消息，获取消息并执行，退出代码，bash 脚本再次加载它......）。我让我的工人在每条消息后重新启动（整个工人退出并开始新的工人 - 坏主意）。

希望这能让你有所收获。

于 2020-01-08T13:03:07.547 回答