Skip to main content
Welcome to this comprehensive guide on etcd in Kubernetes. In this article, we explore the critical role of etcd in storing cluster state, detail different deployment approaches, and explain high availability considerations. Whether you’re setting up a Kubernetes cluster from scratch or using kubeadm, understanding etcd is essential. etcd is a distributed key-value store that maintains configuration data, state information, and metadata for your Kubernetes cluster. Every object—nodes, pods, configurations, secrets, accounts, roles, and role bindings—is stored within etcd. When you run a command like kubectl get, the data is retrieved from this data store.
The image illustrates a Kubernetes architecture with a master node managing an ETCD cluster, listing components like nodes, pods, configs, and more.
Any changes you make to the cluster—whether adding nodes, deploying pods, or configuring ReplicaSets—are first recorded in etcd. Only after etcd is updated are these changes considered to be complete.
The etcd server typically listens on port 2379 for client requests. Ensuring that the advertised client URL (via the --advertise-client-urls option) is correctly configured is crucial for proper communication between the Kubernetes API Server and etcd.

​
Deployment Methods

Depending on your Kubernetes setup, you can deploy etcd in two primary ways: manually from scratch or automatically with kubeadm. Each method has its use cases, with manual setups providing a deeper understanding of etcd configurations and kubeadm streamlining the deployment process.

​
Deploying etcd from Scratch

When setting up your cluster manually, you’ll need to download the etcd binaries, install them, and configure etcd as a service on your master node. Manual deployment gives you more control over configuration options, particularly for setting up TLS certificates. Below is an example of how you might download the etcd binaries and configure the etcd service:
For detailed information on configuring TLS certificates, refer to the Kubernetes documentation on TLS Configuration. Adjust certificate parameters according to your security requirements.

​
High Availability Considerations

In a production Kubernetes environment, high availability (HA) is paramount. By running multiple master nodes with corresponding etcd instances, you ensure that your cluster remains resilient even if one node fails. To enable HA, each etcd instance must know about its peers. This is achieved by configuring the --initial-cluster parameter with the details of each member in the cluster. For example:
In some deployments, you may use separate certificate files for peer communications (e.g., /etc/etcd/peer.pem and /etc/etcd/peer-key.pem). Always tailor these settings to match your desired security posture.

​
Deploying etcd with kubeadm

For many test environments and streamlined deployments, kubeadm automatically configures etcd. When you use kubeadm, the etcd server runs as a pod within the kube-system namespace, abstracting away the manual setup details. To view all the pods running in the kube-system namespace, including etcd, run:
Example output:
To examine the keys stored in etcd (organized under the registry directory), use the following command:
Sample output:
The etcd root directory, organized as the registry, contains subdirectories for various Kubernetes components such as nodes, pods, ReplicaSets, and Deployments.

​
Conclusion

In this article, we examined etcd’s essential role in Kubernetes by exploring both manual deployment and automated configuration with kubeadm. We also discussed best practices for configuring high availability in multi-master environments. As you advance, further exploration into HA configurations and enhanced security measures will help you operate a robust and resilient Kubernetes cluster. For more in-depth resources, check out:

Watch Video