Kubernetes Control Plane Component Communication

Kubernetes Control Plane Component Communication is the specific set of network connections, ports, and credentials used among kube-apiserver, etcd, kube-scheduler, and kube-controller-manager themselves, distinct from the broader node-to-control-plane and control-plane-to-node traffic patterns, tracing exactly which of these components opens a connection to which other, on what port, and under what authentication.

kube-apiserver to etcd

The Only Direct Control Plane Connection to etcd

kube-apiserver formally opens client connections to etcd's client port, conventionally 2379, authenticated via mutual TLS using a dedicated client certificate issued for this purpose; no other control plane component holds credentials for this connection, making it the single, exclusive communication path into etcd from within the control plane.

kube-apiserver \
  --etcd-servers=https://etcd-1:2379,https://etcd-2:2379,https://etcd-3:2379 \
  --etcd-certfile=/etc/kubernetes/pki/apiserver-etcd-client.crt \
  --etcd-keyfile=/etc/kubernetes/pki/apiserver-etcd-client.key \
  --etcd-cafile=/etc/kubernetes/pki/etcd/ca.crt

etcd Inter-Member Communication

Separately from client traffic, etcd members formally communicate among themselves on a distinct peer port, conventionally 2380, exchanging Raft consensus messages, log replication, and heartbeats, secured by peer-specific TLS certificates distinct from the client-facing certificates used by kube-apiserver.

etcd \
  --listen-peer-urls=https://0.0.0.0:2380 \
  --listen-client-urls=https://0.0.0.0:2379

kube-scheduler to kube-apiserver

Client-Only Relationship

kube-scheduler formally connects to kube-apiserver as an ordinary authenticated API client, using a dedicated client certificate or kubeconfig identifying it as system:kube-scheduler, establishing watches on unscheduled Pods and issuing binding writes back through the same connection, with no separate port or protocol specific to the scheduler.

apiVersion: v1
kind: Config
clusters:
  - name: local
    cluster:
      server: https://127.0.0.1:6443
users:
  - name: system:kube-scheduler
    user:
      client-certificate: /etc/kubernetes/pki/scheduler.crt
      client-key: /etc/kubernetes/pki/scheduler.key

kube-controller-manager to kube-apiserver

Same Pattern, Broader Permission Scope

kube-controller-manager formally follows the identical client-connection pattern as the scheduler, authenticating as system:kube-controller-manager, but its bound RBAC permissions are formally broader, since its many internal control loops collectively require read and write access across a much wider set of resource types than scheduling alone requires.

kubectl describe clusterrole system:kube-controller-manager

Leader Election Traffic

Lease Objects as the Coordination Channel

Where kube-scheduler and kube-controller-manager run with multiple replicas, their leader election coordination is formally carried entirely through ordinary API writes to Lease objects in the kube-system namespace; there is no separate, direct network channel between competing replicas, each replica interacts only with kube-apiserver, never with its peers.

kubectl -n kube-system get lease kube-scheduler -o yaml

cloud-controller-manager to kube-apiserver and the Cloud Provider

Two Distinct Outbound Connections

cloud-controller-manager formally maintains two separate kinds of outbound connections: an authenticated API client connection to kube-apiserver, identical in pattern to the scheduler's, and a separate connection to the underlying cloud provider's own management API, used to provision load balancers, attach volumes, or query node metadata, entirely outside the Kubernetes API surface.

cloud-controller-manager \
  --kubeconfig=/etc/kubernetes/cloud-controller-manager.conf \
  --cloud-provider=codartium-cloud \
  --cloud-config=/etc/kubernetes/cloud.conf

What Formally Never Happens

No Direct Component-to-Component Calls Bypassing the API Server

At no point does kube-scheduler formally call kube-controller-manager, or vice versa, and neither ever calls a kubelet directly for the purpose of control plane coordination; every one of these interactions, if it needs to occur at all, is mediated entirely through reads and writes against kube-apiserver, which in turn is the sole component authorized to reach etcd.

netstat -tlnp | grep -E '6443|2379|2380'

Why Communication Is Restricted to This Specific Set of Paths

Limiting control plane component communication to this small, explicit set of connections, each component to kube-apiserver, kube-apiserver alone to etcd, etcd members to each other, is what makes the control plane's security surface fully enumerable: every trust relationship between components corresponds to exactly one of these named connections, each independently securable with its own dedicated certificate, rather than an unbounded mesh of possible component-to-component paths that would be far harder to reason about or restrict.