A control plane centralizes decisions that govern a distributed system, while the data plane performs the system’s operational work. Its responsibilities depend on the architecture: a service mesh control plane governs sidecar proxies and network behavior; a Kafka control plane manages cluster metadata and coordination. section 7.1.1 section 9.1
In a service mesh, the control plane configures, deploys, and manages sidecars that proxy network traffic for services. It centralizes traffic policies, security configuration, load-balancing rules, and observability features instead of embedding complex integration logic in each service. Istio and Linkerd are named implementations; Envoy is an example of the proxy component being configured. section 7.1.1
In Kafka, controllers form the control plane while brokers form the data-plane-facing role. Controllers store and replicate cluster metadata, process changes such as topic creation and partition assignments, coordinate broker operations, and detect broker failures through heartbeats. A controller quorum has one active or leader controller and hot-standby or follower controllers ready to take over. section 1.3.2 section 9.1
Kafka metadata change
When an administrator creates a topic or changes configuration, an admin client sends the request through a broker to the leader controller. The controller updates the replicated __cluster_metadata log, and follower controllers fetch the change. Brokers then operate using the resulting cluster state. section 9.1
Figure 7.4 Configuring sidecar containers through the control plane
Use the architecture figure to trace how a service mesh control plane configures sidecar containers while separating business and integration concerns. section 7.1.1
