There are two main methods on how to setup a cluster.
First is old-school IP address-based (or instance-based) clustering.
You can see it almost everywhere from HAProxy, MySQL replication, Caddy proxy, nginx, etc. At least with Consul, an agent only needs to learn about one existing member.
Second is name-based clustering which is being used by Project Iris.
With Iris, you just have to specify the cluster name and its port. It uses Pastry DHT to do its magic.
You can create a cluster in one node (physical or VM) for development purposes.
You may ask what’s the point when you have proven production-grade solutions out there.
My point is not simply about how industrial-strength the solution is, but how usable it is in terms of development and operation. The instance-based clustering is brittle, that’s why you have health checks.
With name-based addressing, cluster membership is automatic so there is no need for manual health check. Of course, you need to have notification for sysadmins so they can replace failed nodes. But that is another matter.
It is important to note that clustering is just one use case of messaging. With Project Iris, you have built-in messaging for publish/subscribe, request/reply and broadcast. The last one (tunneling) is best served by stateful protocols. You can query the state of the cluster or just one node. It is up to you. No need for a separate key-value store. No need for consensus and gossip protocols.
There is one caveat though: Iris clustering is limited to IPv4 networks (for now).
See http://itmarketplace.net/messaging for more details.