11 The core of the control plane

 

This chapter covers

  • Investigating core components of the control plane
  • Reviewing API server details
  • Exploring scheduler interfaces and its inner workings
  • Walking through the controller manager and cloud manager

Previously, we provided a high-level overview of Pods, a web application outlining why we need Pods, and how Kubernetes is built with Pods. Now that we’ve covered all of our requirements for the use case, let’s dive into the details of the control plane. Typically, all of the control plane components are installed in the kube-system namespace, a namespace where you, as an operator, should install very few components.

Note

You should just not use kube-system! One of the main reasons is that noncontroller applications running inside kube-system increase the security blast radius, which refers to the breadth and depth of a security intrusion. Further, if you are on a hosted system like GKE or EKS, you cannot see all of the control plane components. We talk more about blast radius and security best practices in chapter 13.

11.1 Investigating the control plane

One of the easiest ways to start and poke at the control plane is to use kind, which is Kubernetes in a container (see the following link for install instructions: http://mng.bz/lalM). To use kind to view the control plane, run the following commands:

11.2 API server details

11.2.1 API objects and custom API objects

11.2.2 Custom resource definitions (CRDs)

11.2.3 Scheduler details

11.2.4 Recap of scheduling

11.3 The controller manager

11.3.1 Storage

11.3.2 Service accounts and tokens

11.4 Kubernetes cloud controller managers (CCMs)

11.5 Further reading

Summary