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.