etcd Cheatsheet

Last Updated: 2024-01-27

• written in Go.
• using the Raft consensus algorithm.
• the client does not need to know what etcd node is the leader (i.e. kube-apiserver only talks to the etcd on the same node):
  • etcd internally forwards all requests that needs consensus (e.g. writes) to the leader.
  • Requests that do not require consensus (e.g., serialized reads) can be processed by any cluster member.

Commands:

# Install etcdctl.
$ apt install etcd-client

# List keys.
$ etcdctl get "" --prefix --keys-only

# List members.
$ etcdctl member list --cacert /etc/kubernetes/pki/etcd/ca.crt --cert /etc/kubernetes/pki/etcd/peer.crt --key /etc/kubernetes/pki/etcd/peer.key

# Check status.
$ etcdctl endpoint status --cacert /etc/kubernetes/pki/etcd/ca.crt --cert /etc/kubernetes/pki/etcd/healthcheck-client.crt --key /etc/kubernetes/pki/etcd/healthcheck-client.key --write-out=table --endpoints=10.200.0.2:2379,10.200.0.3:2379,10.200.0.4:2379

Use cases

• used in K8s behind the api servers.
• used by Cilium as the kvstore; cilium agents will connect to etcd; since Cilium 1.6 it can use a new CRD-based backend for security identities instead of using a kvstore.