2.15 Kubernetes Cluster Communication Architecture

Kubernetes Cluster Communication Architecture is the specific arrangement of connection directions and trust relationships between cluster components, describing which components initiate connections to which others, and how mutual authentication is established across those connections, distinguishing the predominant node-to-control-plane direction from the narrower set of cases where the control plane connects outward to a node.

Node-to-Control-Plane as the Predominant Direction

Components Reach Toward the API Server

The architecture is built so that the overwhelming majority of communication is initiated by node-level and client components reaching toward the API server: the kubelet, kube-proxy, and any watching controller all open outbound connections to the API server rather than the API server initiating connections to them.

Why This Direction Is Preferred

This directionality is architected deliberately so that nodes, which may be far more numerous and more exposed than control plane machines, do not need to accept inbound connections from the control plane, reducing the network exposure required of every node in the cluster.

Control-Plane-to-Node as the Narrower Exception

API Server Reaching Out for Specific Operations

A smaller set of operations, such as fetching logs, executing a command inside a container, or forwarding a port, requires the API server to initiate a connection outward to a specific node's kubelet, representing the architecture's one significant reversal of the predominant communication direction.

Secured Through TLS in Both Directions

Regardless of direction, every connection in this architecture is secured using TLS, meaning both the outward-initiated node-to-API-server traffic and the narrower API-server-to-node traffic are authenticated and encrypted rather than any connection being implicitly trusted based on network location alone.

etcd's Isolated Communication Path

Reachable Only from the API Server

etcd's communication architecture restricts it to being reached only by the API server; no node component and no client outside the control plane is architected to communicate with etcd directly, keeping it isolated as the most sensitive component in the cluster.

Trust Establishment Architecture

Certificate-Based Mutual Authentication

Communication between control plane components, and between nodes and the control plane, is architected around mutual TLS in typical deployments, with each side presenting a certificate that the other can verify, rather than relying on network-level trust such as IP address alone.

Service Account Tokens for In-Cluster Workloads

Workloads running inside the cluster are architected to authenticate to the API server using service account tokens rather than the certificate-based mechanisms used between core components, reflecting a different but parallel trust-establishment path layered onto the same underlying connection architecture.

Communication Direction Diagram