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.


# 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=,,

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.