etcd is the control plane’s key–value datastore for Kubernetes cluster configuration. It records resource state, such as how many pods and Deployments exist and which ports Services expose. It does not store application data. Losing this configuration would make it difficult to recreate the cluster’s resources. section 2.2 section 2.4
To locate and check etcd on a control plane node:
- Look for its system pod in the kube-system namespace. To list pods on a specific control plane node, run `kubectl get po -o wide -A --field-selector spec.nodeName=kind-control-plane`. section 2.1.2 section 9.3.1
- Inspect `/etc/kubernetes/manifests` for the control plane’s static-pod YAML. The kubelet picks up these manifests rather than relying on the scheduler to create the pods. section 2.4 section 9.3.1
- Check the API server’s `--etcd-servers` address and its etcd CA, client certificate, and client key settings in `kube-apiserver.yaml`. The API server uses these credentials to communicate securely with etcd. section 2.2
Diagnose an API server that cannot reach etcd
After an interrupted control plane upgrade, first check whether the kubelet is running with `systemctl status kubelet`. If the API server container has exited, use `crictl ps -a` and `crictl logs <containerid>`. A connection-refused error for `127.0.0.2:2379` points to an incorrect etcd address in the API server manifest. Correct the address, restart the kubelet, then verify that the API server is running with `crictl ps` and that the API responds with `kubectl get ns`. section 8.2.5
spec:
containers:
- command:
- kube-apiserver
- --etcd-cafile=/etc/kubernetes/pki/etcd/ca.crt
- --etcd-certfile=/etc/kubernetes/pki/apiserver-etcd-client.crt
- --etcd-keyfile=/etc/kubernetes/pki/apiserver-etcd-client.key
- --etcd-servers=https://127.0.0.1:2379
The API server manifest shows the etcd endpoint alongside the CA file, client certificate, and client key used for its connection. section 2.2
