Cloud Native 10 min read

Demystifying Kubernetes: Core Components and How They Work Together

This article provides a concise, question‑driven overview of Kubernetes, explaining the roles of master and node components, pod networking, scheduling, storage, service exposure, scaling, and controller interactions, while summarizing the essential objects and processes that power a cloud‑native cluster.

Efficient Ops
Efficient Ops
Efficient Ops
Demystifying Kubernetes: Core Components and How They Work Together

If you opened this article, you are probably already familiar with Docker. Docker is a simple container technology that lets you pull images, start containers, mount data, and map ports on a host machine, making it much easier to get started than Kubernetes (K8s).

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, it incorporates many components and inherits the complexity of distributed systems, and because it relies on many Google‑specific images, setting it up in China can be even more challenging.

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 communication among all components, also offering comprehensive security mechanisms.

On each node, the

kubelet

component runs a process that reports the node’s status to the master (registration, health checks, etc.) and receives commands from the master to create the appropriate Pods.

A Pod is the basic unit of operation in K8s. Unlike a single Docker container, a Pod may contain one or more containers that share network resources, allowing them to communicate via

localhost

.

Network sharing inside a Pod is achieved by launching a special

pause

container (a Google image) that holds the network namespace; other containers join this namespace, enabling shared networking.

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

The

kube-scheduler

performs this task, running algorithms to select the best node for each Pod. Common strategies include round‑robin scheduling. To force a Pod onto a particular node, you can match node labels with the Pod’s

nodeSelector

attribute.

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

K8s uses

etcd

as a highly available, strongly consistent key‑value store to hold cluster state, including node resources, health status, and Pod metadata.

All configuration data in etcd is accessed and modified via the

kube-apiserver

, which provides a RESTful interface for internal components and external users (e.g.,

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 multiple identical Pods and exposes them via a stable virtual IP. Pods are labeled, and the Service selects Pods with matching labels using a selector. The Service Controller stores this information in etcd.

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 does a Pod scale up or down dynamically?

Scaling is managed by the

ReplicationController

(or its modern equivalents). You set a desired replica count for a Pod; if the actual count differs, the controller automatically creates or deletes Pods to match the target.

Question 6: How do the various components cooperate?

The

kube-controller-manager

runs several controllers—including the Service Controller, Replication Controller, Node Controller, ResourceQuota Controller, and Namespace Controller. It watches the cluster state via the apiserver and attempts to reconcile the actual state with the desired state for each controller.

Summary

This Q&A‑style overview introduces the fundamental concepts of Kubernetes without delving into implementation details. The key objects and processes include:

Node

Pod

Label

Selector

Replication Controller

Service Controller

ResourceQuota Controller

Namespace Controller

Node Controller

Relevant runtime components are:

kube-apiserver

kube-controller-manager

kube-scheduler

kubelet

kube-proxy

pause

This summary reflects the author’s personal consolidation of Kubernetes architecture after initial hands‑on experience, inviting readers to point out any misunderstandings.

cloud nativeKubernetesDevOpsContainersCluster Architecture
Efficient Ops
Written by

Efficient Ops

This public account is maintained by Xiaotianguo and friends, regularly publishing widely-read original technical articles. We focus on operations transformation and accompany you throughout your operations career, growing together happily.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.