Demystifying Kubernetes: Core Components and How They Work Together

Summary

Opening this article, readers are likely familiar with Docker, a simple container technology that lets you pull images, run containers, mount data, and map ports. Compared to Kubernetes (K8s), Docker is much easier to start with.

K8s is a distributed cluster management system built on container technology, originating from Google’s extensive experience with large‑scale container deployments. To support massive clusters, K8s incorporates many components and inherits complexity from its distributed nature, and its reliance on Google‑hosted images adds extra setup challenges 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 serves as the central hub for data exchange and security mechanisms.

On each worker node, the kubelet component runs a process that reports node status to the master (registration, health checks, etc.) and receives commands to create Pods.

A Pod is the smallest unit in K8s. Unlike a single Docker container, a Pod can contain one or more containers that share the same network namespace, allowing them to communicate via localhost.

Each Pod starts a special pause container (a Google image) that holds the network namespace; other containers in the Pod inherit this namespace, achieving network sharing.

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

The kube-scheduler performs this task. It runs algorithms (e.g., round‑robin) to calculate the best node for each Pod. Users can also direct a Pod to a particular node by matching node labels with the Pod’s nodeSelector attribute.

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

K8s uses the etcd component as a highly available, strongly consistent key‑value store to keep cluster state, including node resources, health status, and Pod metadata.

All configuration data in etcd is accessed through the kube-apiserver, which provides a RESTful interface for internal components and external users (e.g., via kubectl).

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

Unlike Docker’s simple port‑mapping on a single host, K8s introduces the Service abstraction. A Service groups Pods with the same label selector and presents a stable endpoint. The Service definition is stored in etcd via the apiserver.

Each node runs a kube-proxy process that handles routing from the Service IP to the appropriate Pod IPs and performs load balancing.

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

Scaling is managed by the Replication Controller . Users set a desired replica count for a Pod; the controller continuously reconciles the actual number of Pods with this target, creating or deleting Pods as needed, either manually or via an autoscaler.

Question 6: How do the various components collaborate?

The kube-controller-manager runs several controllers (e.g., Service Controller, Replication Controller, Node Controller, ResourceQuota Controller, Namespace Controller). It watches the cluster state via the apiserver and attempts to drive the actual state toward the desired state for each controller.

Key Components Mentioned

Node

Pod

Label

Selector

Replication Controller

Service Controller

ResourceQuota Controller

Namespace Controller

Node Controller

Core Processes

kube-apiserver

kube-controller-manager

kube-scheduler

kubelet

kube-proxy

pause

This summary reflects a high‑level conceptual overview of Kubernetes architecture, aimed at beginners who may feel overwhelmed by the official documentation.