Demystifying Kubernetes: Master-Node Communication, Pod Scheduling & Scaling

Docker is a familiar container technology that is easy to start with a Docker Engine on a host, allowing actions such as pulling images, creating containers, mounting data, and mapping ports. Compared to Kubernetes (K8s), Docker is much simpler.

Kubernetes is a distributed cluster management system built on container technology, originating from Google’s large‑scale container experience. To support massive clusters it includes many components and inherent distributed complexity, and its reliance on Google‑hosted images adds extra setup difficulty for users in China.

Question 1: How do the master and worker nodes communicate?

When the master node starts, it runs the kube-apiserver process, which provides the cluster management API and central security mechanisms. On each worker node, the kubelet process reports node status to the master and receives commands to create Pods.

A Pod is the basic unit in Kubernetes; it may contain one or more containers that share a network namespace, allowing them to communicate via localhost. Each Pod starts a pause container that holds the shared network settings for the other containers.

Question 2: How does the master schedule Pods onto specific Nodes?

The kube-scheduler performs this task, running algorithms (e.g., round‑robin) to select the best Node for each Pod. To force a Pod onto a particular Node, you can match Node labels with the Pod’s nodeSelector attribute.

Question 3: Where is information about Nodes and Pods stored, and who maintains it?

Kubernetes uses the etcd component as a highly available, strongly consistent key‑value store for all cluster configuration and state data. All read/write operations on this data go through the kube-apiserver, which also exposes a REST API for internal components and external users (e.g., via kubectl).

Question 4: How do external users access Pods running inside the cluster?

Instead of exposing each container directly, Kubernetes groups identical Pods into a Service. Pods are labeled, and the Service selects Pods with matching labels. The Service information is stored in etcd via the Apiserver, and a kube-proxy process on each node handles address translation and load balancing.

Question 5: How are Pods dynamically scaled up or down?

Scaling is achieved by the Replication Controller, which maintains a desired replica count for each Pod. When the actual number of Pods differs from the desired count, the controller creates or deletes Pods to match the target.

Question 6: How do the various components cooperate?

The kube-controller-manager runs multiple controllers (Node, ResourceQuota, Namespace, Service, Replication, etc.). It watches the shared cluster state via the Apiserver and attempts to reconcile the actual state with the desired state for each controller.

Summary

The article provides a high‑level overview of core Kubernetes concepts without deep implementation details, covering:

Node

Pod

Label

Selector

Replication Controller

Service Controller

ResourceQuota Controller

Namespace Controller

Node Controller

Key processes include:

kube-apiserver

kube-controller-manager

kube-scheduler

kubelet

kube-proxy

pause