8 Control Plane Services and Extensions
This chapter covers
- Reviewing the path to production
- Understanding the difference between Control Plane Services and Extensions
- Adding Standard Kubernetes Services
- Managing Control Plane Extensions
After finishing the exercises so far, our VitalSigns engineering platform now has a sandbox and a production instance, each with its own network and EKS Kubernetes cluster. This way, we can test and debug each new platform capability before deploying them to our production instance. If we finish the two projects, we’ll also have a CLI tool platform team members can use to authenticate and generate individual credentials to access the Kubernetes API in both clusters.
Figure 8.1 We now have the foundational components in six of our eight primary domains.
Our control plane is pretty bare at this point. Apart from the few AWS-managed components, we do not yet have any of the services and extensions that make our Kubernetes instance become the control plane we need for our platform.
Now we get to two large domains; Large in the sense that there are potentially lots of services and extensions deployed to a Control plane, continuing to grow in number over time. Taken together, services and extensions make up all the cluster-wide services that will be deployed to our cluster. So why categorize these into either a service or an extension?