在 Kubernetes 上 运行 时更改主机名会破坏 Rabbitmq
Changing hostname breaks Rabbitmq when running on Kubernetes
我正在尝试 运行 在 AWS 上使用 Kubernetes 的 Rabbitmq。我正在使用 official Rabbitmq docker container。每次 pod 重新启动时,rabbitmq 容器都会获得一个新的主机名。我已经为具有可解析 DNS 名称的 Pod 设置了一项服务(LoadBalancer 类型)。
但是当我使用 EBS 使兔子 config/messsage/queues 在重新启动之间持续存在时,它会中断:
exception exit: {{failed_to_cluster_with,
['rabbitmq@rabbitmq-deployment-2901855891-nord3'],
"Mnesia could not connect to any nodes."},
{rabbit,start,[normal,[]]}}
in function application_master:init/4 (application_master.erl, line 134)
rabbitmq-deployment-2901855891-nord3
是之前的主机名rabbitmq容器。这几乎就像 Mnesia 保存了旧的主机名:-/
容器的信息如下所示:
Starting broker...
=INFO REPORT==== 25-Apr-2016::12:42:42 ===
node : rabbitmq@rabbitmq-deployment-2770204827-cboj8
home dir : /var/lib/rabbitmq
config file(s) : /etc/rabbitmq/rabbitmq.config
cookie hash : XXXXXXXXXXXXXXXX
log : tty
sasl log : tty
database dir : /var/lib/rabbitmq/mnesia/rabbitmq
我只能使用 RABBITMQ_NODENAME
环境变量将节点名称的第一部分设置为 rabbitmq
。
将 RABBITMQ_NODENAME
设置为可解析的 DNS 名称会中断:
Can't set short node name!\nPlease check your configuration\n"
将 RABBITMQ_USE_LONGNAME
设置为 true
中断:
Can't set long node name!\nPlease check your configuration\n"
更新:
将 RABBITMQ_NODENAME
设置为 rabbitmq@localhost 可以工作,但这会排除集群实例的任何可能性。
Starting broker...
=INFO REPORT==== 26-Apr-2016::11:53:19 ===
node : rabbitmq@localhost
home dir : /var/lib/rabbitmq
config file(s) : /etc/rabbitmq/rabbitmq.config
cookie hash : 9WtXr5XgK4KXE/soTc6Lag==
log : tty
sasl log : tty
database dir : /var/lib/rabbitmq/mnesia/rabbitmq@localhost
将 RABBITMQ_NODENAME
设置为服务名称,在这种情况下 rabbitmq-service
就像 rabbitmq@rabbitmq-service 也适用于 kubernetes服务名称可通过 DNS 在内部解析。
Starting broker...
=INFO REPORT==== 26-Apr-2016::11:53:19 ===
node : rabbitmq@rabbitmq-service
home dir : /var/lib/rabbitmq
config file(s) : /etc/rabbitmq/rabbitmq.config
cookie hash : 9WtXr5XgK4KXE/soTc6Lag==
log : tty
sasl log : tty
database dir : /var/lib/rabbitmq/mnesia/rabbitmq@rabbitmq-service
这是正确的方法吗?如果节点名称相同,我是否仍然能够集群多个实例?
想法是为每个要创建的节点使用不同的 'service' 和 'deployment'。
如您所说,您必须为每个节点创建一个自定义节点名称,即:
RABBITMQ_NODENAME=rabbit@rabbitmq-1
另外 rabbitmq-1,rabbitmq-2,rabbitmq-3
必须从每个节点解析。为此,您可以使用 kubedns。 /etc/resolv.conf
看起来像:
search rmq.svc.cluster.local
和/etc/hosts
必须包含:
127.0.0.1 rabbitmq-1 # or rabbitmq-2 on node 2...
服务在这里为每个节点创建稳定的网络身份
rabbitmq-1.svc.cluster.local
rabbitmq-2.svc.cluster.local
rabbitmq-3.svc.cluster.local
不同的 deployments
资源将允许您在每个节点上装载不同的卷。
我正在开发一种部署工具来简化这些操作:
我已经演示了如何在 kubernetes 上将 rabbitmq 从 1 个节点扩展和部署到 3 个节点:
https://asciinema.org/a/2ktj7kr2d2m3w25xrpz7mjkbu?speed=1.5
更一般地说,您在部署集群应用程序时面临的复杂性在 'petset proposal' 中得到解决:https://github.com/kubernetes/kubernetes/pull/18016
加上@ant31的第一个回复:
Kubernetes 现在允许设置主机名,例如在 yaml 中:
template:
metadata:
annotations:
"pod.beta.kubernetes.io/hostname": rabbit-rc1
见https://github.com/kubernetes/kubernetes/tree/master/cluster/addons/dns#A Records and hostname Based on Pod Annotations - A Beta Feature in Kubernetes v1.2
似乎整个配置都活着多次重启或重新安排。我还没有设置集群,但是我将按照 mongodb 的教程进行操作,请参阅 https://www.mongodb.com/blog/post/running-mongodb-as-a-microservice-with-docker-and-kubernetes
从 kubernetes 的角度来看,该方法可能几乎相同。
我正在尝试 运行 在 AWS 上使用 Kubernetes 的 Rabbitmq。我正在使用 official Rabbitmq docker container。每次 pod 重新启动时,rabbitmq 容器都会获得一个新的主机名。我已经为具有可解析 DNS 名称的 Pod 设置了一项服务(LoadBalancer 类型)。
但是当我使用 EBS 使兔子 config/messsage/queues 在重新启动之间持续存在时,它会中断:
exception exit: {{failed_to_cluster_with,
['rabbitmq@rabbitmq-deployment-2901855891-nord3'],
"Mnesia could not connect to any nodes."},
{rabbit,start,[normal,[]]}}
in function application_master:init/4 (application_master.erl, line 134)
rabbitmq-deployment-2901855891-nord3
是之前的主机名rabbitmq容器。这几乎就像 Mnesia 保存了旧的主机名:-/
容器的信息如下所示:
Starting broker...
=INFO REPORT==== 25-Apr-2016::12:42:42 ===
node : rabbitmq@rabbitmq-deployment-2770204827-cboj8
home dir : /var/lib/rabbitmq
config file(s) : /etc/rabbitmq/rabbitmq.config
cookie hash : XXXXXXXXXXXXXXXX
log : tty
sasl log : tty
database dir : /var/lib/rabbitmq/mnesia/rabbitmq
我只能使用 RABBITMQ_NODENAME
环境变量将节点名称的第一部分设置为 rabbitmq
。
将 RABBITMQ_NODENAME
设置为可解析的 DNS 名称会中断:
Can't set short node name!\nPlease check your configuration\n"
将 RABBITMQ_USE_LONGNAME
设置为 true
中断:
Can't set long node name!\nPlease check your configuration\n"
更新:
将
RABBITMQ_NODENAME
设置为 rabbitmq@localhost 可以工作,但这会排除集群实例的任何可能性。Starting broker... =INFO REPORT==== 26-Apr-2016::11:53:19 === node : rabbitmq@localhost home dir : /var/lib/rabbitmq config file(s) : /etc/rabbitmq/rabbitmq.config cookie hash : 9WtXr5XgK4KXE/soTc6Lag== log : tty sasl log : tty database dir : /var/lib/rabbitmq/mnesia/rabbitmq@localhost
将
RABBITMQ_NODENAME
设置为服务名称,在这种情况下rabbitmq-service
就像 rabbitmq@rabbitmq-service 也适用于 kubernetes服务名称可通过 DNS 在内部解析。Starting broker... =INFO REPORT==== 26-Apr-2016::11:53:19 === node : rabbitmq@rabbitmq-service home dir : /var/lib/rabbitmq config file(s) : /etc/rabbitmq/rabbitmq.config cookie hash : 9WtXr5XgK4KXE/soTc6Lag== log : tty sasl log : tty database dir : /var/lib/rabbitmq/mnesia/rabbitmq@rabbitmq-service
这是正确的方法吗?如果节点名称相同,我是否仍然能够集群多个实例?
想法是为每个要创建的节点使用不同的 'service' 和 'deployment'。
如您所说,您必须为每个节点创建一个自定义节点名称,即:
RABBITMQ_NODENAME=rabbit@rabbitmq-1
另外 rabbitmq-1,rabbitmq-2,rabbitmq-3
必须从每个节点解析。为此,您可以使用 kubedns。 /etc/resolv.conf
看起来像:
search rmq.svc.cluster.local
和/etc/hosts
必须包含:
127.0.0.1 rabbitmq-1 # or rabbitmq-2 on node 2...
服务在这里为每个节点创建稳定的网络身份
rabbitmq-1.svc.cluster.local
rabbitmq-2.svc.cluster.local
rabbitmq-3.svc.cluster.local
不同的 deployments
资源将允许您在每个节点上装载不同的卷。
我正在开发一种部署工具来简化这些操作: 我已经演示了如何在 kubernetes 上将 rabbitmq 从 1 个节点扩展和部署到 3 个节点: https://asciinema.org/a/2ktj7kr2d2m3w25xrpz7mjkbu?speed=1.5
更一般地说,您在部署集群应用程序时面临的复杂性在 'petset proposal' 中得到解决:https://github.com/kubernetes/kubernetes/pull/18016
加上@ant31的第一个回复:
Kubernetes 现在允许设置主机名,例如在 yaml 中:
template:
metadata:
annotations:
"pod.beta.kubernetes.io/hostname": rabbit-rc1
见https://github.com/kubernetes/kubernetes/tree/master/cluster/addons/dns#A Records and hostname Based on Pod Annotations - A Beta Feature in Kubernetes v1.2
似乎整个配置都活着多次重启或重新安排。我还没有设置集群,但是我将按照 mongodb 的教程进行操作,请参阅 https://www.mongodb.com/blog/post/running-mongodb-as-a-microservice-with-docker-and-kubernetes
从 kubernetes 的角度来看,该方法可能几乎相同。