Large Datasets: Since the API server only holds metadata about pods and other objects, there is a natural limit to how much data will be stored.

It's also worth noting what's not needed by the API database. Since the API server acts as a centralized coordinator between many different types of clients, streaming changes in real-time would be an excellent feature (and turns out to be central to how Kubernetes work in practice). Unpredictable slowdowns from concurrent use would be a huge problem. The API server for a busy Kubernetes cluster receives a fair amount of read and write traffic. The CAP theorem says that 100% availability is impossible with strong consistency, but minimizing downtime is still a critical goal. AvailabilityĪPI downtime means that the entire Kubernetes control plane comes to a halt, which is undesirable for production clusters. This requirement rules out eventually consistent NoSQL databases and some distributed multi-master SQL configurations. It would be a disaster if, say, two nodes tried to attach the same persistent volume over iSCSI because the API server told them both that it was available. Since the API server is the central coordination point of the entire cluster, strong consistency is essential. Thinking from first principles, what are some desirable traits for the API server's backing database? 1. It certainly could (more on this later), but it's not a great fit for the specific requirements of Kubernetes. Why etcd?Ĭould the API server use a SQL database like MySQL or PostgreSQL to persist its data? The API server, which coordinates between all of the control plane processes and the nodes.Īrchitecturally speaking, the API server is a CRUD application that's not fundamentally different from, say, WordPress - most of what it does is storing and serving data.Īnd like WordPress, it needs a database to store its persisted data, which is where etcd fits into the picture.Node-specific processes, the most important of which is Kubelet, which handle the nitty-gritty of setting up pods and networking based on the desired configuration.Centralized controllers like the scheduler, controller-manager, and third-party controllers, which configure pods and other resources.How etcd fits into KubernetesĪt a high level, a Kubernetes cluster has three categories of control-plane processes: This article will introduce how etcd works so you can get a deeper understanding of the inner workings of Kubernetes, as well as giving you some extra tools in your cluster troubleshooting toolbox. If you've ever interacted with a Kubernetes cluster in any way, chances are it was powered by etcd under the hood.īut even though etcd is at the heart of how Kubernetes works, it's rare to interact with it directly on a day-to-day basis. TL DR: In this article, you will learn why Kubernetes uses etcd as a database by building (and breaking) a 3-node etcd cluster.

Controlplane alternative