Bootstrap the etcd cluster

Where you are

You now start the cluster’s runtimes, and you start them in dependency order. The first one is etcd, because it stores all cluster state. Every other control-plane component reads and writes through it, so nothing else can run until it is up.

To bootstrap a component means to bring it online when it has no prior state to start from. etcd has no data and no record of which members belong to the cluster, so you supply that starting configuration from the outside through its unit file. After this first start, etcd keeps its own state and you no longer have to provide it.

Install etcd

Kubernetes components are stateless and store cluster state in etcd. In this lab you bring up a single node etcd cluster.

Copy the files to the server

Copy the etcd binaries and systemd unit file to the server machine:

scp \
  downloads/controller/etcd \
  downloads/client/etcdctl \
  units/etcd.service \
  root@server:~/

Run the rest of this lab on the server machine. Log in to it with ssh:

ssh root@server

Install the etcd binaries

Move the etcd server and the etcdctl command line tool into place:

{
  mv etcd etcdctl /usr/local/bin/
}

Configure the etcd server

Create the configuration and data directories, restrict access to the data directory, and copy the certificates etcd needs:

{
  mkdir -p /etc/etcd /var/lib/etcd
  chmod 700 /var/lib/etcd
  cp ca.crt kube-api-server.key kube-api-server.crt \
    /etc/etcd/
}

Each etcd member must have a unique name within an etcd cluster. The name is set to match the hostname of the current compute instance.

Move the etcd.service systemd unit file into place:

mv etcd.service /etc/systemd/system/

Start the etcd server

Reload systemd so it reads the new unit, enable etcd so it starts on boot, and start it now:

{
  systemctl daemon-reload
  systemctl enable etcd
  systemctl start etcd
}

Verify

List the etcd cluster members:

etcdctl member list

6702b0a34e2cfd39, started, controller, http://127.0.0.1:2380, http://127.0.0.1:2379, false

One member, named controller, with a status of started. etcd is now running and ready to hold cluster state.

Key terms

etcd: the datastore Kubernetes uses to hold all cluster state. The control-plane components read from it and write to it.

Key-value store: a database that stores each piece of data under a unique key and returns it when you ask for that key. etcd is a key-value store.

systemd unit: a file that tells systemd, the Linux service manager, how to run a program as a background service, including how to start it, what arguments to pass, and whether to start it on boot.

Cluster state: the full record of what exists in the cluster and what condition it is in, such as nodes, workloads, and configuration. This is the data etcd holds.

Reflect

You started etcd before any other component because everything else depends on it. When you add a second service that reads from etcd, what has to be true about etcd before that service can start, and how would you check it?

Next: Bootstrap the control plane