A static mechanism is the easiest way to set up a cluster. However, the IP address of every member should be known beforehand. This means that if you bootstrap an etcd cluster in a cloud provider environment, the static mechanism might not be so practical. Therefore, etcd also provides a discovery mechanism to bootstrap itself from the existing cluster.
To make etcd communications secure, etcd supports TLS channels to encrypt the communication between peers, and also clients and servers. Each member needs to have a unique key pair. In this section, we'll show you how to use automatically generated certificates to build a cluster.
In CoreOs GitHub, there is a handy tool we can use to generate self-signed certificates (https://github.com/coreos/etcd/tree/v3.2.15/hack/tls-setup) . After cloning the repo, we have to modify a configuration file under config/req-csr.json. Here is an example:
// sample config, put under $repo/config/req-csr.json
$ cat config/req-csr.json
{
"CN": "etcd",
"hosts": [
"172.31.3.80",
"172.31.14.133",
"172.31.13.239"
],
"key": {
"algo": "ecdsa",
"size": 384
},
"names": [
{
"O": "autogenerated",
"OU": "etcd cluster",
"L": "the internet"
}
]
}
In the next step we'll need to have Go (https://golang.org/) installed and set up $GOPATH:
$ export GOPATH=$HOME/go
$ make
Then the certs will be generated under ./certs/.
First, we'll have to set a bootstrap configuration to declare what members will be inside the cluster:
// set as environment variables, or alternatively, passing by –-initial-cluster and –-initial-cluster-state parameters inside launch command.
# ETCD_INITIAL_CLUSTER="etcd0=http://172.31.3.80:2380,etcd1=http://172.31.14.133:2380,etcd2=http://172.31.13.239:2380"
ETCD_INITIAL_CLUSTER_STATE=new
In all three nodes, we'll have to launch the etcd server separately:
// first node: 172.31.3.80
# etcd --name etcd0 --initial-advertise-peer-urls https://172.31.3.80:2380
--listen-peer-urls https://172.31.3.80:2380
--listen-client-urls https://172.31.3.80:2379,https://127.0.0.1:2379
--advertise-client-urls https://172.31.3.80:2379
--initial-cluster-token etcd-cluster-1
--initial-cluster etcd0=https://172.31.3.80:2380,etcd1=https://172.31.14.133:2380,etcd2=https://172.31.13.239:2380
--initial-cluster-state new
--auto-tls
--peer-auto-tls
Then, you'll see the following output:
2018-02-06 22:15:20.508687 I | etcdmain: etcd Version: 3.3.0
2018-02-06 22:15:20.508726 I | etcdmain: Git SHA: c23606781
2018-02-06 22:15:20.508794 I | etcdmain: Go Version: go1.9.3
2018-02-06 22:15:20.508824 I | etcdmain: Go OS/Arch: linux/amd64
…
2018-02-06 22:15:21.439067 N | etcdserver/membership: set the initial cluster version to 3.0
2018-02-06 22:15:21.439134 I | etcdserver/api: enabled capabilities for version 3.0
Let's wake up the second etcd service:
// second node: 172.31.14.133
$ etcd --name etcd1 --initial-advertise-peer-urls https://172.31.14.133:2380
--listen-peer-urls https://172.31.14.133:2380
--listen-client-urls https://172.31.14.133:2379,https://127.0.0.1:2379
--advertise-client-urls https://172.31.14.133:2379
--initial-cluster-token etcd-cluster-1
--initial-cluster etcd0=https://172.31.3.80:2380,etcd1=https://172.31.14.133:2380,etcd2=https://172.31.13.239:2380
--initial-cluster-state new
--auto-tls
--peer-auto-tls
You'll see similar logs in the console:
2018-02-06 22:15:20.646320 I | etcdserver: starting member ce7c9e3024722f01 in cluster a7e82f7083dba2c1
2018-02-06 22:15:20.646384 I | raft: ce7c9e3024722f01 became follower at term 0
2018-02-06 22:15:20.646397 I | raft: newRaft ce7c9e3024722f01 [peers: [], term: 0, commit: 0, applied: 0, lastindex: 0, lastterm: 0]
2018-02-06 22:15:20.646403 I | raft: ce7c9e3024722f01 became follower at term 1
…
2018-02-06 22:15:20.675928 I | rafthttp: starting peer 25654e0e7ea045f8...
2018-02-06 22:15:20.676024 I | rafthttp: started HTTP pipelining with peer 25654e0e7ea045f8
2018-02-06 22:15:20.678515 I | rafthttp: started streaming with peer 25654e0e7ea045f8 (writer)
2018-02-06 22:15:20.678717 I | rafthttp: started streaming with peer 25654e0e7ea045f8 (writer)
It starts pairing with our previous node (25654e0e7ea045f8). Let's trigger the following command in the third node:
// third node: 172.31.13.239
$ etcd --name etcd2 --initial-advertise-peer-urls https://172.31.13.239:2380
--listen-peer-urls https://172.31.13.239:2380
--listen-client-urls https://172.31.13.239:2379,https://127.0.0.1:2379
--advertise-client-urls https://172.31.13.239:2379
--initial-cluster-token etcd-cluster-1
--initial-cluster etcd0=https://172.31.3.80:2380,etcd1=https://172.31.14.133:2380,etcd2=https://172.31.13.239:2380
--initial-cluster-state new
--auto-tls
--peer-auto-tls
// in node2 console, it listens and receives new member (4834416c2c1e751e) added.
2018-02-06 22:15:20.679548 I | rafthttp: starting peer 4834416c2c1e751e...
2018-02-06 22:15:20.679642 I | rafthttp: started HTTP pipelining with peer 4834416c2c1e751e
2018-02-06 22:15:20.679923 I | rafthttp: started streaming with peer 25654e0e7ea045f8 (stream Message reader)
2018-02-06 22:15:20.680190 I | rafthttp: started streaming with peer 25654e0e7ea045f8 (stream MsgApp v2 reader)
2018-02-06 22:15:20.680364 I | rafthttp: started streaming with peer 4834416c2c1e751e (writer)
2018-02-06 22:15:20.681880 I | rafthttp: started peer 4834416c2c1e751e
2018-02-06 22:15:20.681909 I | rafthttp: added peer 4834416c2c1e751e
After all nodes are in, it'll start to elect the leader inside the cluster, we could find it in the logs:
2018-02-06 22:15:21.334985 I | raft: raft.node: ce7c9e3024722f01 elected leader 4834416c2c1e751e at term 27
...
2018-02-06 22:17:21.510271 N | etcdserver/membership: updated the cluster version from 3.0 to 3.3
2018-02-06 22:17:21.510343 I | etcdserver/api: enabled capabilities for version 3.3
And the cluster is set. We should check to see if it works properly:
$ etcdctl cluster-health
member 25654e0e7ea045f8is healthy: got healthy result from http://172.31.3.80:2379
member ce7c9e3024722f01 is healthy: got healthy result from http://172.31.14.133:2379
member 4834416c2c1e751e is healthy: got healthy result from http://172.31.13.239:2379