RabbitMQ - How I do configure servers for zero-downtime upgrades?

Assuming your rabbitmq clients can tolerate a dropped connection, you can consider what's described here.

our cluster is behind a VIP. When we want to upgrade a cluster, we spin up an alternate cluster and switch the VIP over to the alternate cluster. Meanwhile, we have tooling that moves messages between clusters. When the 'master' cluster's update is done, we reverse the process.

When upgrading from one major or minor version of RabbitMQ to another (i.e. from 3.0.x to 3.1.x, or from 2.x.x to 3.x.x), or when upgrading Erlang, the whole cluster must be taken down for the upgrade (since clusters cannot run mixed versions like this). This will not be the case when upgrading from one patch version to another (i.e. from 3.0.x to 3.0.y); these versions can be mixed in a cluster (with the exception that 3.0.0 cannot be mixed with later versions from the 3.0.x series).