Skip to main content

Communication Between Master and Worker Nodes

Kubernetes is built on a hub-and-spoke pattern. Which means that there is a central entity or component (the hub) that manages and controls the other entities or components (the spokes).

In the Kubernetes design, the API Server is the hub and the other components are spokes.

info

Info: API Server can alone communicate with the etcd. No other component can read or write to the etcd.

As discussed, the API Server is the gateway to the cluster and exposes API services on the HTTPS port 443 using TLS/mTLS for encryption and authentication.

There are two types of communications:

  • Control plane to nodes and pods
  • Nodes and pods to control plane

Control plane to nodes and pods​

The control plane initiates this communication primarily for management and debugging tasks. We have again 2 types of communications in this:

  1. API Server to Kubelet
  2. API Server to Nodes, Pods, Services

API Server to Kubelet​

For example, when you run kubectl get pods, the API Server communicates with the Kubelet on each worker node to retrieve the status of the pods and returns the information like

  • fetching logs from a container
  • exec or attaching a pod
  • port forwarding to a pod

These connections terminate at the kubelet's HTTPS endpoint

API Server to Nodes, Pods, Service​

The connections from the API server to a node, pod, or service default to plain HTTP connections and are therefore neither authenticated nor encrypted. They can be run over a secure HTTPS connection by prefixing https: to the node, pod, or service name in the API URL, but they will not validate the certificate provided by the HTTPS endpoint nor provide client credentials.

Nodes and Pods to Control Plane​

Worker nodes and the applications within them must constantly report back to the control plane to maintain cluster health.

  • Kubelet to API Server: The kubelet on every node maintains a continuous connection to the API server. It:

    • Watches for changes: Monitors the API server for new pod assignments or configuration updates.
    • Reports Status: Sends regular heartbeat signals and updates on node health and pod lifecycle status (e.g., "Pod X is now Running").

  • Kube-Proxy to API Server: The kube-proxy agent watches the API server for changes to Services and Endpoints. It then updates local networking rules (like iptables) to ensure traffic reaches the correct pods.

  • Pods to API Server: Applications running inside pods can communicate with the API server using a Service Account token. This allows pods to query cluster information or manage other resources if they have the necessary permissions.