CKA — Understanding etcd
What Is etcd?
etcd is a distributed key-value store that holds the entire state of your Kubernetes cluster. Every object — Pods, Services, Deployments, ConfigMaps, Secrets, RBAC rules, namespaces — exists as a key-value pair in etcd.
| Aspect | Detail |
|---|---|
| Type | Distributed key-value store |
| Ports | 2379 (client), 2380 (peer) |
| Data directory | /var/lib/etcd |
| Static Pod manifest | /etc/kubernetes/manifests/etcd.yaml |
| Client tool | etcdctl |
| Encryption | TLS for all communication |
Why it matters: If etcd data is lost and there is no backup, the entire cluster state is gone. All resources, configurations, and secrets disappear. Regular backups are critical for disaster recovery.
etcd Architecture
etcd uses the Raft consensus algorithm to maintain consistency across a cluster of nodes:
- A cluster of odd-numbered members (1, 3, 5) is recommended
- One member is elected as the leader
- All writes go through the leader and are replicated to followers
- The cluster can tolerate (n-1)/2 member failures
| Cluster Size | Fault Tolerance | Recommended For |
|---|---|---|
| 1 member | 0 failures | Development, CKA exam |
| 3 members | 1 failure | Small production |
| 5 members | 2 failures | Large production |
etcd in a kubeadm Cluster
On a kubeadm cluster, etcd runs as a static Pod managed by the kubelet.
Key Configuration Flags
cat /etc/kubernetes/manifests/etcd.yaml | grep -E "^\s+--" | head -15
| Flag | Purpose | Typical Value |
|---|---|---|
| –data-dir | Where etcd stores its data | /var/lib/etcd |
| –listen-client-urls | Client connection endpoint | https://127.0.0.1:2379 |
| –advertise-client-urls | Advertised client URL | https://192.168.1.10:2379 |
| –cert-file | Server TLS certificate | /etc/kubernetes/pki/etcd/server.crt |
| –key-file | Server TLS private key | /etc/kubernetes/pki/etcd/server.key |
| –trusted-ca-file | CA certificate for client auth | /etc/kubernetes/pki/etcd/ca.crt |
etcd Certificate Locations
/etc/kubernetes/pki/etcd/
+-- ca.crt <-- CA certificate
+-- ca.key <-- CA private key
+-- server.crt <-- Server certificate
+-- server.key <-- Server private key
+-- peer.crt <-- Peer certificate
+-- peer.key <-- Peer private key
+-- healthcheck-client.crt
+-- healthcheck-client.key
Finding Certificate Paths
The easiest way to find the certificates is from the etcd static Pod manifest:
cat /etc/kubernetes/manifests/etcd.yaml | grep -E "cert-file|key-file|trusted-ca"
Setting Up etcdctl
# Always use API version 3
export ETCDCTL_API=3
# Check etcd health
ETCDCTL_API=3 etcdctl \
--endpoints=https://127.0.0.1:2379 \
--cacert=/etc/kubernetes/pki/etcd/ca.crt \
--cert=/etc/kubernetes/pki/etcd/server.crt \
--key=/etc/kubernetes/pki/etcd/server.key \
endpoint health
# List members
ETCDCTL_API=3 etcdctl \
--endpoints=https://127.0.0.1:2379 \
--cacert=/etc/kubernetes/pki/etcd/ca.crt \
--cert=/etc/kubernetes/pki/etcd/server.crt \
--key=/etc/kubernetes/pki/etcd/server.key \
member list --write-out=table
Exam tip: Always set ETCDCTL_API=3 before using etcdctl. Version 2 uses different syntax and is deprecated.
Next: etcd Snapshot Save ->