Before we learn a more flexible way to set up an etcd cluster, we should know etcd comes with two major versions so far, which are v2 and v3. etcd3 is a newer version that aims to be more stable, efficient, and reliable. Here is a simple comparison to introduce the major differences in their implementation:

etcd3 aims to be the next generation of etcd2 . etcd3 supports the gRPC protocol by default. gRPC uses HTTP2, which allows multiple RPC streams over a TCP connection. In etcd2, however, a HTTP request must establish a connection in every request it makes. For dealing with key expiration, in etcd2, a TTL attaches to a key; the client should periodically refresh the keys to see if any keys have expired. This will establish lots of connections.

In etcd3, the lease concept was introduced. A lease can attach multiple keys; when a lease expires, it'll delete all attached keys. For the watcher, the etcd2 client creates long polling over HTTP—this means a TCP connection is opened per watch. However, etcd3 uses bidirectional gRPC stream implementation, which allows multiple steams to share the same connection.

Although etcd3 is preferred. However, some deployments still use etcd2. We'll still introduce how to use those tools to achieve clustering, since data migration in etcd is well-documented and smooth. For more information, please refer to the upgrade migration steps at https://coreos.com/blog/migrating-applications-etcd-v3.html.

Before we start building an etcd cluster, we have to decide how many members we need. How big the etcd cluster should be really depends on the environment you want to create. In the production environment, at least three members are recommended. Then, the cluster can tolerate at least one permanent failure. In this recipe, we will use three members as an example of a development environment:

Secondly, the etcd service requires port 2379 (4001 for legacy uses) for etcd client communication and port 2380 for peer communication. These ports have to be exposed in your environment.