11 Performance tuning the control plane

In the previous chapter on troubleshooting the data plane, we took a deep dive into the debugging tools available for us to diagnose issues with proxy configuration and proxy behavior. Understanding service proxy configuration simplifies troubleshooting when some behaviors do not match our expectations.

In this chapter, we focus on optimizing the control plane performance. We’ll investigate how the control plane configures the service proxies, what are the factors that slow down this process, how to monitor it, and what are the knobs that we can turn to improve its performance.

11.1 The control plane’s primary goal

In previous sections, we’ve said that the control plane is the brains of the service mesh and that it exposes an API for service-mesh operators. This API can be used to manipulate the behavior of the mesh and configure the service proxies deployed alongside each workload instance. What we omitted for brevity is that we, service mesh operators, making requests to this API is not the only way behavior and configuration of the mesh gets affected. More generally, the control plane abstracts away details of the runtime environment such as what services exist (service discovery), which services are healthy, autoscaling events, et. al.

11.1.1 Understanding the steps of data plane synchronization

11.1.2 Factors that determine the performance

11.2 Monitoring the Control Plane

11.2.1 The four golden signals of the control plane

11.3 Tuning the performance

11.3.1 Setting up the workspace

11.3.2 Measuring the performance prior to optimizations

11.3.3 Ignoring events: Reducing the scope of discovery using discovery selectors

11.3.4 Event batching and push throttling properties

11.4 Performance tuning guidelines

11.5 Summary