12 etcd and the control plane

 

This chapter covers

  • Comparing etcd v2 and v3
  • Looking at a watch in Kubernetes
  • Exploring the importance of strict consistency
  • Load balancing against etcd nodes
  • Looking at etcd’s security model in Kubernetes

As discussed in chapter 11, etcd is a key/value store with strong consistency guarantees. It’s similar to ZooKeeper, which is used for popular technologies like HBase and Kafka. A Kubernetes cluster at its core consists of

  • The kubelet
  • The scheduler
  • The controller managers (KCM and CCM)
  • The API server

These components all speak to one another by updating the API server. For example, if the scheduler wants to run a Pod on a specific node, it does so by modifying the Pod’s definition in the API server. If, during the process of starting a Pod, the kubelet needs to broadcast an event, it does so by sending the API server a message. Because the scheduler, kubelet, and controller manager all communicate through the API server, this makes them strongly decoupled. For example, the scheduler doesn’t know how a kubelet runs Pods, and the kubelet doesn’t know how the API server schedules Pods. In other words, Kubernetes is a giant machine that stores the state of your infrastructure at all times in the API server.

12.1 Notes for the impatient

12.1.1 Visualizing etcd performance with Prometheus

12.1.2 Knowing when to tune etcd

12.1.3 Example: A quick health check of etcd

12.1.4 etcd v3 vs. v2

12.2 etcd as a data store

12.2.1 The watch: Can you run Kubernetes on other databases?

12.2.2 Strict consistency

12.2.3 fsync operations make etcd consistent

12.3 Looking at the interface for Kubernetes to etcd

12.4 etcd’s job is to keep the facts straight

12.4.1 The etcd write-ahead log