The etcd distributed key/value store is starting to play a key role in the management of fleets of Kubernetes clusters in the enterprise.
Currently an incubation-level project being advanced under the auspices of the Cloud Native Computing Foundation (CNCF), the open source etcd project was originally launched by IBM. Since it became a CNCF, the etcd data store is being more widely employed to provide a single, consistent source of truth about the status of a Kubernetes environment, including all clusters and pods and the application instances within them at any given point in time. The Kubernetes application programming interface (API) server stores each cluster’s state data in etcd, which Kubernetes clusters employ to reconfigure themselves when changes occur.
That data is also used to enable tasks such as configuration, deployment, service discovery, load balancing, job scheduling and health monitoring across the across distributed Kubernetes clusters that can be running in multiple locations.
The etcd store itself is built on the Raft consensus algorithm to ensure data consistency across all nodes in a cluster. Raft designates an elected leader node that manages replication for the other nodes in the cluster, which are known as followers. The leader accepts requests from the clients, which it then forwards to follower nodes. Once the leader has determined a majority of follower nodes have stored each new request as a log entry, it applies the entry to its local state machine and returns the result of that execution to the client. If followers crash or network packets are lost, the leader retries until all followers have stored all log entries consistently.
Sahdev Zala, a senior software engineer for IBM, says etcd will play a crucial role in both enabling Kubernetes environments to scale across thousands of notes in a way that maintains high availability. Following a recent security audit, etcd will play a similar role in Kubernetes to the one it already plays in enabling other distributed computing platforms such as the IBM Cloud and the open source Cloud Foundry platform-as-a-service (PaaS) environment to scale securely, he adds.
In effect, the etcd data store is the brain that manages the Kubernetes environment by providing a control plane through which thousands of clusters can be managed. As more organizations start to scale their Kubernetes clusters, many of them will need to set up separate etcd clusters to manage the overall environment. That may add another level of complexity to deploying cloud-native applications in a Kubernetes environment. Alternatively, IT organizations can rely on a managed etcd service to provide that capability, notes Zala.
Regardless of how IT organizations come to terms with scaling Kubernetes clusters, large numbers of Kubernetes clusters obviously will not simply manage themselves. Each IT team will have to find a way to not only manage Kubernetes clusters at scale but also—and just as importantly—ruthlessly automate that process in keeping with best DevOps practices.